From nobody Fri Dec 1 03:24:11 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2347D1271FD; Fri, 1 Dec 2017 03:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 t-qqUwK8xgyC; Fri, 1 Dec 2017 03:24:08 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2ED4126B6E; Fri, 1 Dec 2017 03:24:07 -0800 (PST) X-AuditID: c1b4fb2d-139999c0000036aa-60-5a213bd57197 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 72.CA.13994.5DB312A5; Fri, 1 Dec 2017 12:24:06 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 12:23:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hw2DPmBzeoxCaajRKvYjSYUG1AmuFOv6p9mzXCB5LXg=; b=inDuQxonaVd9eY9QFdo79cFeGiaz2wQNItnz7MsTG5yyQRnJvJJdH1LVdnlahQpEekoklkEPRJhrle+SZ7xVq8ALQ6KqI6g3mCH+aoGHIR+JKDwQYsQlM8KlyGXdlmvaP2OwQMu1onoAQyGAlxy6fouKQZNG2LX6Mb0axnDRmds= Received: from [159.107.197.209] (91.82.100.59) by HE1PR07MB3433.eurprd07.prod.outlook.com (2603:10a6:7:2c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 11:23:29 +0000 To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> From: Balazs Lengyel Message-ID: <3a458dc4-daef-5515-5b57-b5c88c848018@ericsson.com> Date: Fri, 1 Dec 2017 12:23:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: VI1PR0602CA0020.eurprd06.prod.outlook.com (2603:10a6:800:bc::30) To HE1PR07MB3433.eurprd07.prod.outlook.com (2603:10a6:7:2c::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5cc1c62-6424-48dd-462f-08d538adf2c2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:HE1PR07MB3433; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 3:XNUcqo+770fog0XFm4bk0OMz7mEgQ52RZ984iO/ZptB7WcM9+8GrShhq/0J7DZooH79QlUyDEownpVhsRuMHXBL7qgy4Fl4TplBj7Te9PpLXkP0pfIzdSDLtFdcL2n66oktGaP2P2/Eb4B+re7BtGfjoj8ADda+eYx1kV2wqC2IU1BYF0lc8g70vjalhTwNRVCCL4TCKHSbMTao3UI+bBVnd3XVI24TzOpEuYGO771Cv436NnfnC7tIG18oi/bSt; 25:H+/euStfnveMu5kfU4DhZj9RTaKHTvNyjNAdB1jI0TMrK7PGucMQMYxMlqX5SZ3sOdY4baBSYsu3LVCT0PxUGd5VCjM57ue0HiEv5uYLLyYKDuxpQuDuGxIZ1oK7jh60jof4oLpXMMdc48cBZ4fWA4Tgg9wxPs3vPaR5pWMOoe2p/kSqqJaVyCq1uq3oqSdX7gHbUQayszX13MoDKkzZK+Jie4hBoASThLNWG4sFaeRL9TkH5o+2nrFOT3lR1q4SZqwXNWmGfAPqP+39CgP/BeFmSm8/33xY8bfQXEWpjuUhvQVnR5BbaxgAxH9MOZ7IOHCL0ER6We6E9yBgvMRLiQ==; 31:XxoNHbj9gfAdG+ZOvzxqgDxfD/L8wJrHgkSYjoob5KSD7bne7CeZ43pmwiGPGcs9ZgHrKIJ6JdnAI4UCYfvoKHhhVUO09paVfsIkpKg/8EgDgx5f0Q/Uuz3oBwXyoclAeCr1nPiAQMhKCQmWKu2niZfVfkwWCjLV+KO/Y1aIkXxomwBvTiHe1F6pfqvNavREq08q0jPjYuQbWj2sjNKo6bvHiIwxmq8Zf+7T2qTbGiA= X-MS-TrafficTypeDiagnostic: HE1PR07MB3433: X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 20:eSGWvMHMYvMOweLQQ6q7qr0HbtuCKnRRCEmEfFbRKVxQh4wX4Q4qPhWSINGWVxM0PnPmmjTUvZZ2IGAeSAf3XJO/1rvLKJwFCXAF+Lb8zaOIphCpZkdOKBgwuayRM6kToZgjaEY02aizINeeirRiiuJG+OE72yxPe1XrZaaOnflRusG+WMIesiVw70N4DjxYkQme8ctYIA2K5EVFeEKP1rcmk+zVzerVubrFEFh5C08KzNFc5gIdV9dS49VRmn+QEDs4jNtuauCiLpYngWaVhlrty8Wy68q/4IaZcpzIrNh1sjlY+4g9GLIqgDnpg+mjGuClS/uBb9QTBNIkVLiebmS4eO/KzZf7Pl4JKSRKSrk2Js99rR0HTVqz2Ya0I8fMkxGG9gMleMOGYLjV7DmZkFnND2xorWN/lHLkm7XqLfzdzTggR2OKeieN2HVa1phY235mzx8zp2bAGiaQH97KwbemumDNAevJ6uM6R2LwxVlc0GEuGBTGTYvtFWyPJxRX; 4:OHJ/G2OSbC912IKs4ueJVZ27uphLH9lpaT639OFYNwP2XAL3j2VWsRV8c0bxdgHSS/QWldRNrBcNCP+JUGx2fUjgB+kyC7NC8lGL/A4YsvoquYO/1K0UI3Ig08jrfZ38p9umisgv33I61WmEii6m5v8WDDfGjxopQNQmFnhEIJsGkNCbiM+cnAIg++jFUyi1zWyn1cf7911IPf497eW5w/bjOYRkmYW8Oa6X3qCpwXd+3TVDNcuSBtluwofkRTe2pTqy3ezkwUoew04J3xd7IviReGRsQnaxcqHn+OPXlmv0RuL19mK/trkfpWsrHl6I X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231022)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011); SRVR:HE1PR07MB3433; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB3433; X-Forefront-PRVS: 05087F0C24 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(6009001)(39860400002)(376002)(346002)(366004)(377424004)(252514010)(189002)(24454002)(199003)(65806001)(65956001)(53546010)(6666003)(305945005)(6306002)(16526018)(31686004)(83506002)(7736002)(230783001)(1941001)(229853002)(25786009)(6246003)(8936002)(86362001)(52146003)(23676004)(966005)(2486003)(31696002)(66066001)(53936002)(2950100002)(76176011)(47776003)(54356011)(110136005)(52116002)(2501003)(16576012)(67846002)(101416001)(8676002)(4001150100001)(106356001)(64126003)(49976008)(478600001)(58126008)(65826007)(316002)(6116002)(4326008)(3846002)(50466002)(68736007)(36756003)(105586002)(8666007)(97736004)(189998001)(2870700001)(6486002)(5660300001)(81166006)(33646002)(2906002)(81156014)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3433; H:[159.107.197.209]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDMzOzIzOlRvS1QvYzdoVk9JNDVmcGxWUW1tbk16SHI2?= =?utf-8?B?czNrS1JWL0hDdWYxc09taEIzTEY1NFVhOHQwQXhFWXNQRjNYK1J1QXBCNm0x?= =?utf-8?B?Q2hJZFgxYXQ5N09SRDMrMVZ0UVl4emZoaXJJYm5lNmpIWXozMXBmRzVCT0Q4?= =?utf-8?B?eVJaZmRYRTlqWlEvTmZydzZGS2RHYUwxZHVEZ1dDS0tCSmF5QTlQRGhkdCtM?= =?utf-8?B?Q1MyZGF6Nlo5Nkt5b1VybnBORTYyWUZYZ210YTNzNnQzZFlTZUpCQ21lbmJm?= =?utf-8?B?dWkzQzFteitHU0t4amttWERON3gzbytqcWNTbGpGaGpVZGlnYkxKS3Y4bkU3?= =?utf-8?B?QWhqd0FuTnQrYnd6eE4yY1E0TXBpcVJxRUE4UTd1QjdrYjFFWlkyTlgrUTN5?= =?utf-8?B?eDlPaE1oWWtFNG14UXY4YXJmVno4ZFV3UHA3eUZudUF3UFpmVXVuTW1EbzMv?= =?utf-8?B?OHFZRzVBVzBZSXdRUHQ5STIrZWd5Qk5lZHByakRqTGJLOTNDSytsNXQyRUV4?= =?utf-8?B?WmJBcFhQOXRBeUFyVVNKSTVzRDRPNS94R3YyV3lOSzJRWUl3M0t4MGV0RU9H?= =?utf-8?B?NzNGeWpUTStXbzdqM0lhSUtyNmM0bXJJeFJhK0ZyMTZpcWZSampmSWdYNHpa?= =?utf-8?B?eDdFK2ZucjlCY3BWVktMSU1BWU5RejZRY0VVQ0gzcnRWV09rOVVOa0Y3UUhv?= =?utf-8?B?bU95YjBvazIvL3J3K2Z3YTArUlJGcTYyTHlGc1JHK080Wm56VVVhd2s5MFhS?= =?utf-8?B?UnFvN1JTNVc1NjZNbTM2ckVJRHlZN2lCbjg3MUVha2RxcXZmZnRKdVpkVDNI?= =?utf-8?B?MmNJYUM5RmRoVlFvYkNscG5lSWRpQU9GMDVBdnRua0l0SnRLcUdwVkVXajc0?= =?utf-8?B?c0hMV3llVVBhN0wzSUttYi9xRDdINGI5WURHMnBINXB5SDlvbjhJTXRUYS9V?= =?utf-8?B?NzFncjQ1S2JWVUhTNUNjcTA5NFVhbnY0dW5abHVVVkZHdnJvWGNpaVJHd0xM?= =?utf-8?B?UGxhYUVuSG82Y1dHSHdTTHhrUm1mUGQ4SlNBQWZnVDFsbUZ6L2doOG8wYnVr?= =?utf-8?B?ZkIrUXEvS1ZYRDVtZG40TWNqRlZjemJadDRRcXUybVVaVFR6RDNadTVYdWJU?= =?utf-8?B?Y3I4LzFVUkkrWlVNS1Q2VGU4T2M1Y0JYcHh1dlJnWUJZemlUMFJYaDhGT2lZ?= =?utf-8?B?RG5SamwzZHFvSlEvSkdrWDNCa2ZWYStmdURiL241U2wxR1dDd3EzVkNNb3RC?= =?utf-8?B?ZkJGZ1V6RkJBdTdIcDVRREY4MGg1RkNsakpQdWFTWERBdUNJVkQyZU9HQVZN?= =?utf-8?B?SG5MWVBEVWkvRmQyRFBzUFlEdWZ3UXpCOUhYQ05UUVlSYTRPZnBEVGwvYTNS?= =?utf-8?B?b1pLbFMvYlNYYzQ0WVcrYWQwREh4Z1Zsd2g3bUQ2UTQwbGlUN2VnajVmYVBl?= =?utf-8?B?S05IL09zT2FWdW14NjZZUVJQRGpVZkxwRXVxYXQzM1Z1T1pFenJmaEREc0NX?= =?utf-8?B?RGx1MmQvVWp4TUZjM00ralZMTitFLzRRUlJJTTI3TlZwakNBdHJ2R1V3cDZn?= =?utf-8?B?R0x6Y1o3NDBvcThkRFpoODR4Qm54NmE1VFpGOE13UDlGQ3VIOStpaEwwaG1j?= =?utf-8?B?Zm9PYWd0TmVINDRHdG01WjU5c2VxZTRaM3lhK3FDOVUxejFsb1IvN3ZNVVYr?= =?utf-8?B?ZVJXdUdSWGE3R0poSjVyS0FQMjM3ZG1TQyttT0NCU2twRE82MU12VVRaMjN4?= =?utf-8?B?QllTa2hVNjdLN0xDQ055bXd1RkUza24zQzNIeUlMV0NjQlZvempDVnord05X?= =?utf-8?B?OXJET01GeW0yNE1jRlVmUGFEa1o1ak1MTDl0OFdHT3JBOWRFSWZJbmZNTk42?= =?utf-8?B?NERST09JTlFCYllWczhYZGhMdm9iM2pzOCtLMWtYSjVLajZxM1RSR0ZvWHI4?= =?utf-8?B?TVBSNndjdlFMRmx2czRleDBTelB4dno5K28zdFlDWTg5ZDN4TXFFZ2xFeUw5?= =?utf-8?B?ZUxWQlNMZlRPeFZ0Vy96WXMvU29KZVZQOFhNdGI5SUcyZHBWVy8xTWU4V2No?= =?utf-8?B?UHVYV0JSMkozendpcGpGTGRBb2lOTkxEVGM3QWg0NGFpNW45Z2QzbURyOUVz?= =?utf-8?B?MWl3TGVQMnVCdTZGc2llNEg1SEp0K1Qzbll5M0RYaHpFYlFzVjVaM2NQOXpM?= =?utf-8?Q?oQAxi18ccQ7ImRTjMN1mlhHsQNtrfBbMYsCUKJP/HQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 6:feJaIZ8tfcJ/HVEzu/1fhQJbLbbxVarowxSdcjS0x1+lp61Apo6NnMeAcV4uhaHETtf5Wt6ZYxGRMCp9KUWevRstsUeSoBTzegy3Q4os6hYJa88uTXtBcl7aji2VrlFZJoehNsJntQnFZ+uKt4iN6neRaLaU56lp3iAEoW1YMDE3AGHKMCRTM/M8TeQLXBv8tKTYs61SRfHCFFZxB1a58Yl2yuGIBz1Jk4ZCtxDs9GO1fgWhPp3g9PInEZVzutnY1PooXqI91ciEXsmN/n6DaaOzgC3EKS2gDdwA6vdaxJoBA/jdw0DgN2Ibmh62U3M9LsVgq59OR/uEabmxRGKqkHfFx/RAD/FBEeLMpqNzals=; 5:38YtMDCr9kEgb81RFAVSMFklHNL09LPU+e9BeB2ffuILmnQRSXi5+nmhPZft2aR963womBxiYsTPny4wBm+v92zgZQnq8rYgFm5uv2YRXUE5KvBdb/PZ4kssWin7y0alRyWrSBq85NFskaBs9NELmbXsspehhzHujnvHJVX3CBM=; 24:MP+YrjVGrBi9yJsbCIrrUwri0qlmEGYr00VNwpNx3AcFPZTHS96a/Ga3x41kdms4CYFfViMvqKSsB6xrpKCa+erTLPd2LDg/3HNcV5g3+8I=; 7:aMQqSajhivfHUC84whL5sYw1jx5Bz3XAWeLvtd8dpVsWm6XGzH06pwDrfHxGL2Tvp0WaV7XpoI6Efcuqj1Fyv9sSchJgfrfabDH9XzIxvciMtJftVMBtvOV8pEpb50w++iMkrg4AnwsCnaGe9XRRGQcwQeBioXjw/HFkQgO6n96YZrEaeuaZEZlQmVDP2SDEtPkTyVnOhpe7sRgPBWDpZd/hdklO6ip1Ajf0Wdynxq0/8gVfe/Otby4E+2xx7nCp SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2017 11:23:29.2827 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a5cc1c62-6424-48dd-462f-08d538adf2c2 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3433 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42KZGbFdRfeatWKUwZenLBYH5rBbrO5Vs5h/ sZHVgdljyZKfTB7Xm66yBzBFcdmkpOZklqUW6dslcGU8v3WXseAQV0XbydVsDYybOboYOTkk BEwkzs6/xN7FyMUhJHCYUeLe36usEM5xRonPvVvAHBaBXmaJ4zsfMkNkWpkkljdMYwHpFxZw lli/+yAriC0i4CWxYetnRhCbWcBUYtXm20wgtpCAncT2re/A6tkEjCSm9p8Hsjk4eAXsJdYv 0wcJswioSHROuMUGYosKxEhMfHARbAyvgKDEyZlPwFo5gco3TWpmhRhvITFz/nmoVfISzVtn M0PY4hK3nsxngnhNQeL65ussIDdLCExnlJh94QXUPRoSDy/8ZYUokpU4enYOC4TtKzF7z0s2 iIYljBK7DzVAdTewSzzcfIgdokpLYvLENqiqH2wSq06+hxqVLXHnzHU2CNtK4vWv74wQRQuY JR7sfAZVJCPx5+UuqLHv2CQ+3zzGPIFRZxaSZ2cheXAWkgdnIXlwASPLKkbR4tTi4tx0I2O9 1KLM5OLi/Dy9vNSSTYzAJHJwy2/dHYyrXzseYhTgYFTi4T1vphglxJpYVlyZe4hRgoNZSYTX SBMoxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgdGuzuNN 6ZalE229VDdcvHpTSPF1R+/Ltxfs43ISLyrPU0ky+LvcX9s0Jkbtpfi3hwnT5766UmTNED// 0HHpXm2ntjP833d+erNz8YXI7rvt7pIWmtePrNxQcKY5r+jCUkPJByna36baHPp7aB1vw/VZ 7QJJCR+0nNIsHrSqe+d9UHtvztSjdUCJpTgj0VCLuag4EQBBi1tqHgMAAA== Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2017 11:24:10 -0000 Hello, container interfaces-state  is deprecated. I assume that if a container or list is deprecated, then all its contents are also deprecated.  Is there a need to mark all leafs deprecated too? regards Balazs On 2017-11-28 20:29, Kent Watsen wrote: > All, > > This starts a two-week working group last call on > draft-ietf-netmod-rfc7223bis-00. > > Please recall that this update's intention is to > modify the YANG module to be in line with the NMDA > guidelines [1]. Reviewing the diff between the two > drafts [2] should reveal just this. > > The working group last call ends on December 12. > 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. > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt > > Thank you, > Netmod Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Fri Dec 1 03:32:23 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B43128B37; Fri, 1 Dec 2017 03:32:21 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRc658atTxVJ; Fri, 1 Dec 2017 03:32: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 CEA421289B5; Fri, 1 Dec 2017 03:32:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9DA9AE91; Fri, 1 Dec 2017 12:32:17 +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 brt71M_tagSN; Fri, 1 Dec 2017 12:32:16 +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, 1 Dec 2017 12:32:17 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88AA720128; Fri, 1 Dec 2017 12:32:17 +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 jqgSctf0AK5a; Fri, 1 Dec 2017 12:32:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18E9D20126; Fri, 1 Dec 2017 12:32:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 55176418830F; Fri, 1 Dec 2017 12:30:47 +0100 (CET) Date: Fri, 1 Dec 2017 12:30:46 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Message-ID: <20171201113046.heycq27pygry2q74@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Balazs Lengyel , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <3a458dc4-daef-5515-5b57-b5c88c848018@ericsson.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: <3a458dc4-daef-5515-5b57-b5c88c848018@ericsson.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2017 11:32:21 -0000 Balazs, the behaviour you assume is not defined in RFC 7950 and hence everything is marked explicitely as deprecated. We had a discussion on this, search the archives if you are interested. I personally see an advantage with explicit deprecation marks since if I look at an isolated definition of a leaf, it says 'deprecated' and not 'current', i.e., I know the status of a leaf by looking at the leaf and I do not have to search up the tree whether there is something overwriting the status. Note that no status defined means status current, it does not mean status inherited. /js On Fri, Dec 01, 2017 at 12:23:24PM +0100, Balazs Lengyel wrote: > Hello, > > container interfaces-state is deprecated. I assume that if a container or > list is deprecated, then all its contents are also deprecated. Is there a > need to mark all leafs deprecated too? > > regards Balazs > > > On 2017-11-28 20:29, Kent Watsen wrote: > > All, > > > > This starts a two-week working group last call on > > draft-ietf-netmod-rfc7223bis-00. > > > > Please recall that this update's intention is to > > modify the YANG module to be in line with the NMDA > > guidelines [1]. Reviewing the diff between the two > > drafts [2] should reveal just this. > > > > The working group last call ends on December 12. > > 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. > > > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > > [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt > > > > Thank you, > > Netmod Chairs > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 1 03:37:38 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CF812895E; Fri, 1 Dec 2017 03:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 9uV1LV51MBu7; Fri, 1 Dec 2017 03:37:36 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8CC89127136; Fri, 1 Dec 2017 03:37:35 -0800 (PST) X-AuditID: c1b4fb3a-7b5619c000003538-1e-5a213efd625f Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.B5.13624.DFE312A5; Fri, 1 Dec 2017 12:37:33 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 12:37:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N1GEu4XERxqf6va7jCVGp0j8MtQRCJkkKSNT6t9M/Lg=; b=XX8wg5tiL/vO+9tn8SK7cMEVyBtgcWZY/HHpOpGbC/vV8Gm+iDJ6u9UEq1zLA7/KHYT6hVuh7zLyDf9Zl4HNLMfjewKAq8waKfmgIzLU5FrwgTXXKXJ75pqeWhsChCRzDVTXctswQHafvFJDphTLIRfDlmQ1bxUhgnJr90zmUgk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.209] (91.82.100.59) by VI1PR07MB3439.eurprd07.prod.outlook.com (2603:10a6:802:24::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 11:37:13 +0000 To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> From: Balazs Lengyel Message-ID: <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> Date: Fri, 1 Dec 2017 12:37:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1PR05CA0182.eurprd05.prod.outlook.com (2603:10a6:3:f8::30) To VI1PR07MB3439.eurprd07.prod.outlook.com (2603:10a6:802:24::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4bc00d6f-0c8f-4f35-560c-08d538afddf1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:VI1PR07MB3439; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3439; 3:F9l8NokYyDvoI9YwqgCXwsYxYc12VD+Uy7eSDkGie1rfASRp1u8w0O/Qfib1hPGqS/XdpsQ04aeqz5MzPourUdIeUvPVRSwvT/k0nMC1Az/AFtDEXxJhV095G4baexMySOSXKiX9gYQWx0EG5sTDVfUDj7Av/tNupHQlhP364BOu1ZCT5NlfAEPVEN4cSHHMISRyIyjtrE60mlIabDWcjxuEPOhZv3mmLcHMeWXI98zocWynRvC33gterTvUsScB; 25:CxgD5/dph72Upsukw15txXY3TnCjaFFQOvj+v+ZGxSlqUvkyn+7FmUrtBn9F/+DRBo0YcHB3MTfZly6uw1zXwlkmWtiLN1U4RqZdE2tmXiuCL/0eVv1caeRBxk4J53RfIaKYZEjqaG2vNplWC0NXrN7aX/0BHWMQnEMo9ZkjHf6RWNoIL5T1gwcpeGYpkRAuf3e6MOofYuBoS2N6uSJFpS/VpYESIt5GTq/yIQy2JmcKwTcYOWim46nuouoJIf2tMfF/c90OEm3JnIzxVA7fJ8WsHim5KULqf4uQMpo0Zez/cvm87TecNIfn5t8hpWCu+U8QzPcV74mo/Fr2METEWQ==; 31:SqYKvXR6i5xL80x345CPDcr7hRWZ/WX83A1l12ytirWhbaMa7Xq7Z3KTVN1jMV2WRNMVNm/7TC8iJ3cBGDe7ydtnZzL8XST7KtPdQxNVoYbCIEwJlyTQUNT4vOCKx8qRdH0wX5dhN2NduP4KR1xL43DD4cv63LiDD3SyG1BZZCZHrr9v/KadTaBJImlbW5vnejvQCXx8ntTrMPxRj8iIpjBpkWYpKfJ7itBWmiVM89s= X-MS-TrafficTypeDiagnostic: VI1PR07MB3439: X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3439; 20:pQwqHpfBCBzyItHbOx9fC3z9tdwEI/a0okZ5Om7Ua2X3TFbcZgPDGPC9Q/v8GP0eLbE+VpcN6h07S4fmx/nwMCsJtBbm1pu5WTBdGdW6zXG580CJzCUy7uml5ppsGvwD5B2+B1EgaZ4NFeqzBXGgxv7FMK46yxpEHYrm+O7e/k+6IWkajflAPXkPWrW9QSTxDFxwiTOiklvphPzvtsaWbygsqJ3ci9cAE9IRKpaedb2NmLfXyxFewLzS8n5BQS3OXv30hBJvFbellwdlF5hCPCs4gUYxd87gHNckLeurdctJ4HfuQxLbm/Ck8UGh8YBnrWgwYSUoZACHCs9ofJuha+1j+K0rgsTMaeRRDY1taM/QFb9SqjDeEMkZpI1wMAsweQA948sJxPJGwyA7mYl4r6EHLD/7saObF54yOO1ImkOdH74pk8PZmXXjzfStYwfePcBdVz6RwIn5pdOECiEI+wSLL89JoEtBDdc80G0kcjMpq1P9F7wxLJo85rD3ZNhK; 4:EtOowSuWHkHC7DPjljScsqZStKQnUt/B5ttFALuL01DynDj7vigJOoy+FlvNMYV7jOYTwQjcXjMnPyw363QypB+iadgORTVf5tB0FGuH7Bb4QhJ3sRMChZfoef0LJLqFKM9NPErvE5ylKluuIGFCAVtCfndIlr6lJzRDw8NyicxVohHNyWVQkZYe4Z2J35Eqloh6nbjWY1aAjl708ufyoVQZgr6FNe6vx8e+gecc9/up07mTmA1Vk47ENnVK3xVTC70lwE+4Ajx0DdYCOrAUTXvB5lUXgdGbwoFS0GOuCTfB7XIKRzaS3089q066jNHmbEusDfnIFC0Bd1aG58REzLYTXXXdNsn9cVcSjZgT2M5yNJHcmX2v+hOBqgBIuGoP X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR07MB3439; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3439; X-Forefront-PRVS: 05087F0C24 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(366004)(376002)(39860400002)(189002)(199003)(377424004)(24454002)(252514010)(31686004)(106356001)(16526018)(49976008)(3846002)(81156014)(966005)(81166006)(4001150100001)(110136005)(6116002)(7736002)(105586002)(58126008)(230783001)(31696002)(2501003)(54356011)(36756003)(8936002)(66066001)(86362001)(4326008)(8676002)(101416001)(478600001)(16576012)(316002)(50466002)(54896002)(65826007)(25786009)(6666003)(6486002)(64126003)(68736007)(1941001)(189998001)(2950100002)(65956001)(33646002)(5660300001)(8666007)(6306002)(97736004)(83506002)(2906002)(2870700001)(236005)(52146003)(52116002)(606006)(23846002)(2486003)(53936002)(53546010)(23676004)(76176011)(65806001)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3439; H:[159.107.197.209]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzNDM5OzIzOndoVnJydnRvYk53TkJiNVZ3N0d2UFB6blVx?= =?utf-8?B?L1pacFh5UWh0UjVSbnpKNDIrZGNNMVBSOEJoUW5Mb0ZKcmo2WVdnM0htQXpq?= =?utf-8?B?QVoxUW1OZ1BsQWFrVW51NExXaHdXVjBLbnhyWVJyYUVLaEw5UmZMUXZIQVRm?= =?utf-8?B?UFB1U3pxVGlXdmFMbThudThMLzJveU93cWUxWlJDN0FNS1Y0Q1VDbVpGS3Qy?= =?utf-8?B?cVBQYUNYbXlyNmNwVDJVWUpCZWZtYWlDMzcwc3BSTzIwb1lCcldKMWhjQ08y?= =?utf-8?B?ajcrZ013cXQ0cHRPKzdxRnJ4eFpBbmpYQzU2Tkd0ZzVSS0EzMGY4OEZkL29m?= =?utf-8?B?VWdGalFDRkVuVFNNQnY1T0JZTFJvbWVQTCtIdjR4QmpMY0R0S0tlQkxKeUU2?= =?utf-8?B?TkowV1pPSWJtU0lDWHNwTGZjVjF2M3VZdVgrVmI2RkxiWUZGVElSd3ZhWHhE?= =?utf-8?B?SUFJbVhaWUIwRGQyNzhxM1pJa3NIajhNREZtaU9OZkJwSlBtSU9pd3hWNHdT?= =?utf-8?B?TUdsd3pDd21iT3lXak9BUFVsbjBqUC84bjdPK0Z6cTQrakpuVG95MTI2bFFm?= =?utf-8?B?TnVHYVAvYlR6aVpuODhxaFc3TmlFTU1sRU5lMFlYME1qQm9PUTdsZzlTaE5U?= =?utf-8?B?Q2p3YTdhaHFxby9rWWxSN1lUNHBiRmlWZ0lDRWx5eUNhSzRHWVhpUmlHWm5x?= =?utf-8?B?VG5TeTErcUJ2OTdYSVQvOHhQUkZUVTNlZ01hYnBCdXdOc2czdVVoS2lZbVVM?= =?utf-8?B?aURDWHk0NEVjaW9UK29kakg3UXBITGlJa3ZBT3Z1N3U0aE83anN2aGQ1U28y?= =?utf-8?B?SzR4bWVpWGlOVUFmNENrcGpHNmpKTjJYcWdwdGZXVXFjMkRMaU1FYklZckpP?= =?utf-8?B?aW1leGpTNWdXMENEQnpZdXdLY25YYVhjVGtYU3hRTHU2ZzJyekJuaTE5Zmhh?= =?utf-8?B?WnUvWWMrNnFvSXZLZklmNTlHTTFXdmpoMmtqWEl0ZDUwL3ZLNmNGM0dtSWdQ?= =?utf-8?B?a2RWbVBZV1p6RlBjSlRYSWNteCt6SUNmcGFqWFdlUVhTR3Bma0xqRXVUR0pN?= =?utf-8?B?aFNsV2pJVk50NGJ2WStESXBkNk1STFVlUER3NitOSTBaT0twMTUydndkWEVY?= =?utf-8?B?N2NCb3haRVVITHQrUGJuazNlUFRFY3pmVjl4a1Y4aGIwUStRY0lUOGE5ZmtM?= =?utf-8?B?Nkg3NVJhK1dZcjVsYWNFR2F2NjZiekZYalB6R052YVV1UTFxMnJPeUVuUStX?= =?utf-8?B?aWV3RGM1bGFYWHlEbExEOXFsNjJjdUtJY0NvTG5DQzdzNjdWemdId3pqTWJy?= =?utf-8?B?U0JuRTVJSEkwZitVSFZoc1RwRDNWcitaMW5MVkZZWVZEamNMa1NxWUlPUkh2?= =?utf-8?B?ekptL1JubTRZa1VIRlplZ09KYjE4QmE4NVFqeWkxOE1XMFh1dFJZazRLY25j?= =?utf-8?B?Si9zM1U2YWNVcks4akh1TXU4VWNhdWxiZDJKdnNRSkRnbER0cG5Vbzh0MnVM?= =?utf-8?B?MUNzU2o2RHJzNkUyTjF6Z1M1SnZwTzRGS1dsNzdTOXVWcnpia245YmdDTUND?= =?utf-8?B?U1B1UHBQQ1dLVElFc0dYK1hyRUJrSFIxQjQxQnlFVXFNam1aWUVaTTNPY2JE?= =?utf-8?B?UElWeExXVW5RaE56cUhrZkEybmFDdFJkMm5Oc0VSbmxhTmtLU29jYUcrZ1p1?= =?utf-8?B?Y0hWMWRmZGhDdHN1Z1Q4SVJSZzVrMG5DbEVrWjFxV2VFSTI2WVQreElYanlu?= =?utf-8?B?c244ODQ2N0NiY08vdlkyaUYzWU1LSlAyOFFzYzJoZHNrRWtoMXBQNjByYlhq?= =?utf-8?B?d0d4TFJKclBYYUlRamlOVTNJZWhQVHhDWU0zZ1lJN3hsMDlhdGNkN0RDSXE3?= =?utf-8?B?MEJoclo4Y3Y2anBsK1M2b3pCeWEvMWNGSEtoaXZnVFhXYzQ1QlRvWUJpY3lp?= =?utf-8?B?U2hVUnNrRHA0WG42RnBlbUxheTdGcEo5S3poTURtMTU0M0VOZzhpNUNZNlVr?= =?utf-8?B?OVFqL2NZekhoR2VPNnZaSGFhamZBczZYMGRPc3RubWJWV1BlWEx5d2F0dy9I?= =?utf-8?B?NmZ1OElwT1RUdHpCR21zYlZpbEszVDNKNkZSbU1idmVFTVJGQUMwQ1AvbzBZ?= =?utf-8?Q?F27fACUT39xYnjUYar7ICSNze/pKyxenbYXJ9s8Hch+5?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3439; 6:2Er/sDEfgPKV/c4W8rTedXdWbp2mSdFbwhuoo2ebhq6Bft7Lr5MfcwJNPEQihDTmIaKkMJuOcuoiY03e40FNDJDtmMrpKYlBCKF+rMpstXKBlnNn1lfBYpOXDZilbGU2i1+N2lnF4R+eUV9npsOtd6/3JfeBX8vS8E2yldVz8dgZZDhLsHIsveteAwef0zek8FMNEt7NByMHvX4XWhnBtOvmQKyT5fo3bmJC/QICHy2AN+LHOIYTcqeDqMUlY9I59GdK+Iyww+L29Bc8wYRqcbzkuVUgC5fFFFANfQ4ez4UA89VzCnzdY2ldwx7R+73EoCNSda1PW3Q5rHRLwuc2dRWi9jtnDfC2LZsJ6QMO7p8=; 5:1hFIzsLnoWR5q2U3GXQdSz7VxWy0ugpnRokixdqmhUiMJ751WtXdxKcbZ5fF5bQ5ASEmS7N1Ntsrm5sEcsZXD5wMaAYNzdrlsVVEuTQiFvzB3dH+KK++NPyk4ZR9CSDhCa4eTV1kRl6lXpGnzmpPLfCQTZ/e5+iMJc8xeL7C1mA=; 24:lvah/5fiFBBSSE+7ykdi2ZDkRfmylQq3+2V5gegplNUkxOjoqtGeGyM0oieJGE2tA0kopBu1PrMZdPp6l/697xb440pzVefdivz49Nb4dSc=; 7:el6u0Y1fqDaJLlsBpLG+43/PvzMsHUpB4Urn251Wj/Sww54ut4YemLvmLDfePW929E9e3g6n1CYysf3uhw1ZJ5MAfm768a/QOb/8YRp2mu0kWEXQr6reLd49gkstQCa2lt+v4yJFMjoCjpKvLOp6REnO/7i50CCxFubCxvlQwjE2rESeFY4oWzWQhvlSSkQQtVrlLmySwN+b9Helk3BD+t6IZWsgfARd9ZvvtK3Jc1picbHpfdqw8lzyOl9m9z4m SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2017 11:37:13.1962 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4bc00d6f-0c8f-4f35-560c-08d538afddf1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3439 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sb0hTYRTGeXfvtrvR4G0qHqb5Z/3BRM3GRA3TAhENhKAvsaQaelFxTrvX RP00tTGcLitY5DSmtCRcpmnDFVg5G9PAbIEMFoHCyFQalQWVWm27C/btOe/ze17OA4cipD18 GVWvbaEZrVojF4jJgfMzkL1XnK7KHfMpC14OCQvspiMFVm8n/xRRbrP94pX7ulaEZ3kqcVEN ralvpZljxZfFdbOOXl7zXErblrlNh9bAiEQUYCVcd9n5RiSmpHgewZ3dPQE3eBB4Ju5FHBKb CDA43CgcQfgiPH04Eo0YeKCzdoYGiorDLJjd2WEmHp+BScd2hCdwHoxNv+eFtRQXw4wjSIa1 ACvA3L8c0RJcAvbgToQh8SHwTG5Esgm4Cm6uehHH7IfFgUCEF4X4qVvdfO7/DNAP3RVyOhH8 ASuP06nQ7RgkuJpp4Jv2keGdAZsRjH/4LOAWyoC1t3t8DjoA7qUhktOV0Nu3wOcCNgT9Bmd0 0Alhyfs8SmXC93fTPM5wCsHoDwo5owEct68hTlfBxPYrIQcNE9AZ2IxCybC78Yy8gbIsMf0s MZ0sMZ0sMZ2GETmGEliaZRtrFYocmqmvZtkmbY6WbplCoQOZe7Jzwonm1k+7EKaQfJ8kMT9d JeWrW9n2RhcCipDHSxRHQ0+SGnV7B800XWKuamjWhZIoUp4oWayQqKS4Vt1CN9B0M838d3mU SKZDKbOqg7a01b7sEqX+wv1ae1mHt3QrK1jELvtX8p0j5fllgfHC+DxRlqYai9d/rM88FsXB /ChIu2WPkr8UpeoP/1aa6hZU8KZntov4lmT6efLcJ/Eo0+szxOkbBJt5pbK2jytVg5Wvc/v+ Vvy5UmP1GJtLZQ/chf4XPpf2q5xk69THMwmGVf8Dx8Q5kRwDAAA= Archived-At: Subject: [netmod] Use feature to advertise pre-nmda-support {was: WG Last Call: draft-ietf-netmod-rfc7223bis-00 ] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2017 11:37:37 -0000

Hello,

https://tools.ietf.org/html/rfc7950#section-7.21.2

   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

This means that a node that is deprecated MAY or MAY NOT be implemented.
YANG is considered an interface contract,  however "maybe implemented" is unusable in a contract.
YANG already has a statement defined for indicating such optional support: the feature statement.
Deprecated works as if there would be an if-feature statement on each deprecated schema node
where the server does not advertise whether the feature is supported of not. Why is it not advertised?

I would like to propose to use a feature here. This would allow the client to understand if the container interfaces-state is implemented or not.  

module ietf-interfaces {
   feature pre-nmda-support {
       description "The feature indicates that 
          schema parts representing state information 
          are deprecated but are still implemented."
   }

   container interfaces {...}

   container interfaces-state {
      if-feature pre-nmda-support ;
      status deprecated;
      ...
 }
}

regards Balazs


On 2017-11-28 20:29, Kent Watsen wrote:
All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7223bis-00.

Please recall that this update's intention is to 
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

The working group last call ends on December 12.
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.

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt

Thank you,
Netmod Chairs


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



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Dec 1 04:13:08 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A01271DF for ; Fri, 1 Dec 2017 04:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWqEP69116MY for ; Fri, 1 Dec 2017 04:13:04 -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 4F791126579 for ; Fri, 1 Dec 2017 04:13:04 -0800 (PST) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 9DA4B6451D for ; Fri, 1 Dec 2017 13:13:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512130382; bh=EplGiTTFVbWrHzU29DWtn34K9yTwkojnz8GndBjGbT0=; h=From:To:Date; b=c1tv0DTAjzaxmdFEmDq8tmRH1dYad1BZ7J+bHVGbv5bEY/g6fPxgoCtewjydVdHxW W8r9iJ3WGV8h4ZxPZbteH8PVI24DDIunLiBkJ5D8qUUVRCCrlDbTPyvbPYTfMLME2h DlRk4Tqd4ANXCgO6tk0co2F3IAxqzakjUl0PdiIo= Message-ID: <1512130382.9397.20.camel@nic.cz> From: Ladislav Lhotka To: NETMOD WG Date: Fri, 01 Dec 2017 13:13:02 +0100 Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] YANG module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2017 12:13:06 -0000 Hi, the security considerations template text [1] that has already been used in a number of documents is apparently incorrect - YANG modules aren't accessed by NM protocols. Hence OLD The YANG module defined in this document is designed to be accessed via network management protocols such as ... NEW The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as ... [1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Dec 1 08:21:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BAB127B57 for ; Fri, 1 Dec 2017 08:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 ZcdkUCK9p9WA for ; Fri, 1 Dec 2017 08:20:57 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 27E0D127011 for ; Fri, 1 Dec 2017 08:20:56 -0800 (PST) X-AuditID: c1b4fb3a-3edff70000003538-7b-5a218167e9b0 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BF.0B.13624.761812A5; Fri, 1 Dec 2017 17:20:55 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 17:20:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ra4VrB0DFIZ5nlnF3kPZQtsIzqeZqCreL3WuIt60Kp0=; b=Ddaq1nt7Mlrijads7YMR2639eLEBjfaGfHkM5vsPtJ3WHMkfVYEWRCssKnsm884o+/a/0VNMmDhyG9hivJxKv2lM70eZ8hNGiqyXV7r/0WYk3syoVPhlZ6S1gCNqgwfDdz4zXyssNERopORQ2biLIxMrjTJPx+Ur+lpY89rPuA0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.209] (91.82.100.59) by AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 16:20:53 +0000 To: Alex Campbell , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <1512100040970.60458@Aviatnet.com> From: Balazs Lengyel Message-ID: Date: Fri, 1 Dec 2017 17:20:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1512100040970.60458@Aviatnet.com> Content-Type: text/html; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1PR1001CA0016.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::26) To AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 09d606f6-5e7d-49ef-2243-08d538d77e97 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:AM4PR07MB3425; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 3:KAulHbr4xDIdG/amH0ztecuxZjtZ6jnoJ3vqWak0vxqws1uq84rvq9+qLnEMCxaBmOMi1G6V0HzvUsYBdc8DrCS+rys6+xUvSVMmUVR5hGDrSzUxXHPSDZYWWtFlJ0QhPZXvthMrvkqUzxqFIsgD9cq1uLYn9Kb/+9NQ5oAQV6yEQkO6b4wqiwGmpBsw9AN6fAQLRJtnCWwgwcLOk7zEinJ84ROfOCyFIyujy7LKvznWb26h9WDNcn8FgI8MqQDS; 25:tiUgNawg0S59aWvYwSJNtRWDEfCVUAeX9ghgSGn7hD1WGpGMQiAcUSc4rr/efdcNYLpVgZV+Pqijt559aMifRjvPlcC5r0zOfEfkBahBxt1tRi0bQj4fM3C/3WnR9ZBWC8meHiRMTUS/YkMaBcoCef5hB/nlztD+GL9Z6Ypdm/NnQ+CN6qlVMoJOpHnTnb4Uqo2HTkA7DdTBNLdE8PDKyBfXjQcY85ZiOKrOOVZs3Rgm9+PVoq5OOHq7npa1f1wDB7ANAenG1A0cDWPp6rHp9Ji+aNK8OTLD2eyfsdUkSvM6JldnOSXIJHGLOSJYawxChZTqG8jYvZJytt9clmxH0A==; 31:6UrS4wuW4G2TEyMa2d0tgUonTHzuvlOVv/chAkdX0hTeS873/CUxR7n1j636ibj7BnOt2aX9dkAXSN4Lz40HIts3qqxo+t1hRjZ3FB5msSY+QuDgqA26VKfnc81p5CAk59UWlZ2mzWHZvdALAq7NnDm/Ee6s1TebTn4XMyABVpAJgQX7cwPb3HsWr4Ahfila54tU4HzrWeeHpcXjCEfHE94mmqjM7Dz6UGv8r9QrUnQ= X-MS-TrafficTypeDiagnostic: AM4PR07MB3425: X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 20:a0dR7+x7Fiq4h6H0hCh8TFRc9LZsuDFaqg2IM7y5Fpu1KzIkfXgL7Z+J6mNN+SrI2E+U269AeBA7UOUICrMVEoiuCWiGqQoU8u2CcyC4wOim+U/vxti8n9HbWzcFUFTsy0SE4sVc3dVh7TvFRXIsQIFBf8meUdRQyHOyef+W0FxdULnho2Bu2IsmGNWs5Xl1iskvE8o9hxRVZp+Ai3g4olBxcoUrM2+3eVCiei8vud0cnuf7msQ2ewcsZApMWtFlUm4GPV1YzKDpWb6+5cD4Nsz25ItLyF0GwgMLJesshQ5cq3L8cxlmN8sfe3in7Nh5wryTniUrVmmTCEowN9L/OGfShTqJ1uFZNs+VSg4IKZ+/EytbEKcmLPYKYU5vdeWcz1HXED/xavrQoUsYuAG5DUIObX9f3bbvhI6MKH5HBH2/h2FSDSJRYRHp2sKHbWwzRcAusGGEXh7ubmH+DMBqsMFjPb4W47FpI5ZfcRd3zz4B0R+UZz+w2HTwIWwMIH8o; 4:EloO8bikFnjtJOl9AVPTIjbpBTzPOnUsnmgn/Kah4d4eU9KgQn2q147NQ+u10R2+LO1dOVz/oXdmcJujUF2CF7oXniBwWYJ9sRJamyOgNggdvoQtAIigaPRBMFbdEgjOIPkbVkhUpwUIsrrBxdmSd1ac/vpZ0rrh5s7JnGa4bUMu4ldCIN49krUT9nIRuwP3gPc/9sbvy9WaDYJniNzmjKQC5eHBqBkvEww3KvGYe6tL4+wb5XcG/kECWI9PiLRIdEnLdleOnjtIDkexdrePF1pSnhH8r7YF25rzfa8cHzln2V09/RMywLNLG9iCIYeE0A9F93nKw86D+pdYzCCQQhUa24j8sC73yZIYaKWS3DY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(82608151540597); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:AM4PR07MB3425; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3425; X-Forefront-PRVS: 05087F0C24 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(376002)(366004)(39860400002)(252514010)(199003)(377424004)(189002)(24454002)(83506002)(49976008)(966005)(6306002)(8676002)(58126008)(2950100002)(478600001)(5660300001)(65826007)(229853002)(33646002)(2501003)(8656006)(16526018)(50466002)(19627405001)(16576012)(7736002)(25786009)(53936002)(236005)(54356011)(64126003)(76176011)(81166006)(110136005)(6246003)(101416001)(81156014)(106356001)(54896002)(6666003)(105586002)(53546010)(189998001)(316002)(36756003)(66066001)(2870700001)(6116002)(3846002)(23846002)(68736007)(2906002)(31696002)(65956001)(86362001)(97736004)(65806001)(23746002)(52116002)(606006)(8936002)(6486002)(31686004)(78286006)(19607625011)(19627315001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3425; H:[159.107.197.209]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM4PR07MB3425; 23:s3F90gtpCy0hPJnphGFy/Pw8VlblwXrCcpi6C?= =?Windows-1252?Q?MOlrNYhyox31Cb6z+q0Omaw9g31hE2BnPYgIefD30cwsAfR8x7iOsWsI?= =?Windows-1252?Q?7Nks5cj4hf8FnsrUhtYJs1pA3u7fvCku7iQ/jIONDLvQ7Mmu+QxSZiFL?= =?Windows-1252?Q?uRLLfBsbZ9GtjSAQ1GgCn9fV9kUF/8aFdIjgl9+Gny+7yKskGjPvS5WD?= =?Windows-1252?Q?3ad+K90wVCr4n7H+3pJUtUIuoWExKJUzIEns2OKMf3uftcH7NG4hEQGC?= =?Windows-1252?Q?XdZ9czK12Nu/c3TjLGlJKnOChl+6aRMLgBLiywbibSQpc9hbH7fTLmFd?= =?Windows-1252?Q?+ww9QZIT6YLzoQg1aWJT75hd9a3ijB7nMnM2zc+axa/2jF+P2mKTYfiL?= =?Windows-1252?Q?TsI376FluzUAVxpMinVGEGhX8wqmg2UBEhKpuu5sh0V8JHLsBY3d5z0X?= =?Windows-1252?Q?edT64kO8XAG65HwLS8uQRd7uCXzerBDUEcE5vtwAScE+ACTdaskYdODC?= =?Windows-1252?Q?6mQu5b9tx2aZHq8LPLJk1I8WihqBWgHP1GAEx98nNEKpaN7dzY9iWG0f?= =?Windows-1252?Q?k4z31ZslNuF+b8y7D0zhFGwWBYRmjkKVM9KV/MXCOec5Xrpp+3VhNeh7?= =?Windows-1252?Q?PfIrtarmnFzyxownyyayzAyIi4lV/MIxGKLA1VvOGSpoCaK2UxUGylgz?= =?Windows-1252?Q?LiH0thUFgohw79eO0+MnFgvwuLnnmthZ6LAj2RSXTVawaIlc7cYhPNPD?= =?Windows-1252?Q?KnoRL+XEgV3AveZgbtfphTH69H8djld1zCy1HHXD//ViRvR+po2Q6qnC?= =?Windows-1252?Q?TNRMilx5fH9+3f2xAgi3OFpo7PMXuuKh4kqDUjZ9Enfl43h9fN00RGEe?= =?Windows-1252?Q?ldjOWkRHopsAASOC/rwRJ9IQaJs1bdO3k88jxCkAS6RTfZ26qkUP038k?= =?Windows-1252?Q?vt0k7pTgJQ9XSJj3QXNtow4fgmwJm2s+CCF/ywbDtCTKdQFOiO6hph8J?= =?Windows-1252?Q?66cwQ7sd5LFryGqimq7n/b7Wm3Cwlux6KpbW5f6D9rLyi5bgd3c/so45?= =?Windows-1252?Q?bOyo0uE4kuMj9pHngg6pjvRaXhVQcJ9fEJhfjvHubxywpth3mxGZUZ8T?= =?Windows-1252?Q?mT92ISqWBMS+k7grpkXlykegMyvuw4YDtpSqJ50SKVfaDRJmwExhwGZ8?= =?Windows-1252?Q?y2bh5tjw0nXwddfqbY5D1Dokjz+o/vqDYmZfXMToNKpKriD4aysAPxVh?= =?Windows-1252?Q?3zl+UxUGKQlrH6Qzr/1VzNfap5T/E802InWzdBY4UV4/UXN2c3gQBo9x?= =?Windows-1252?Q?UqZ+C3KxlBjBgpAwMCBtP0owIkEsLdRTk9a+LwBewXsgaX+p+QCBQBzE?= =?Windows-1252?Q?X7z6qDQKIVIX9ybX0NZUhU1/qkjXTtmszv9PuO7sC2rcTDoCQ1K3G4DD?= =?Windows-1252?Q?ppvuK3vgriL625jsjDYde9og8J4HWNd30Y2oIJfq5nTrcRgD6ytwSRWh?= =?Windows-1252?Q?UY2p6l/6i0Z4ejud1lc02HC3qg0Qktjkxiq7LxkKrAaFIccnxD8CjkNU?= =?Windows-1252?Q?QfLDFfUYj65/41HjwTXGcmt4VOHSnce4/owZoKD854WmITYdYC4zYRCD?= =?Windows-1252?Q?xexZ5ofpIoszHysw01zd8/A59MviQYNrSq3wyXBmydOxcU5/v7Ekm1KN?= =?Windows-1252?Q?Izfggrbi+15saLUn1W4opz4p0GBbFg=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 6:ymjohgPGJTaES7HGpDsMhZOXqOum3Ayz9rwmWEkd6MStQ5UrLEvu4PwbZMaz4M8pDWOAYMzFceWf5O7iHNyUyUUkfdc197S1QMcF3TQQPNuZxnKZcnFmSAsL5wrefLGbcNtfrTBEEFFxWVJoPw157mC+isNIB0Zjtr1TWEyHbv96bDFoCUROhvAFKf3yTR6vvA9uFrnSWf7/9NKtjmZdY3wg9EuZo6cHcqLaLqUnlH4vFZVLDG/X7f7/GbvDfkwWtuRZjvfC69sEz8SjPUN5D3XXYKrvDws3FS8aDq4x8q3MskdsqHFPtq14TPcaMfQdMHBNNJSi9wNJISyHSAzqEjdX8y9bMa4z8/bKnk+s0AU=; 5:HhxRhVUdakDsUkfm+VAg1i73/6/sLoUD+MHMIzpPNOuvyPIdAzX8jQvMEem/RIZAzXUjPveAapguLrPkx5PCXzTAgdQdhKH3V/36YKnpa8ZalWQnjwQ7GBYQzzM4sHpA+P4LukEbBztezrhIsZ+Qlmp6FSmexoeb4Z/TsN0WE1g=; 24:cTZ0z6z58Q46p/AdjmTrJYJsBDROw6Abj7Qmdyb5NfbBXXh+dSORpIq2KqeMtX4tGBcwihNgJYeaTzcveXmPw3mEBwZCLiEWRM+Np2XNdR4=; 7:Y7xpmZO6kkkZpyWIbywMs9YJyR6QV5D+CaEpIc9tCNbZ/rpwiDu4pn52o3obLld9EvQ9W/V4nVod21jW+T8rKR/w4mp59Z7iA5HuVM/4yK0nPkLEV6gvVGsL6jYb2kTRfABWp5bA8GZ9ZWLBQf8x+Wi0L1Q/tD/0kquAGdxHTf/HpGS7wbbVNH3ROaqvUF7nCxYpn/XeT3xU3GSBVOC1WE3kdvFMmBw5ei9JBIoL/WA/t0o9hw2w337VKASVUEue SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2017 16:20:53.1688 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 09d606f6-5e7d-49ef-2243-08d538d77e97 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3425 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUyM2K7mW56o2KUwfvT8ha/m7pZLTZ/eMlk Mf9iI6sDs8fhzjWMHkuW/GTyuHvrElMAcxSXTUpqTmZZapG+XQJXxoy7H1gL+tQq9l4qamCc LtvFyMkhIWAicXZJM1sXIxeHkMBhRollj9oYIZzjjBKXD0wAc1gEepkldtyZxgjSwigQJ7Fz zUJWiKo2JokZ/++ygSSEBTwltm9dwQKSEBGYwihx4c0rqKpGRommj3dYQarYBIwkpvafZwGx eQXsJQ4u+w1mswioSFxZsoEZxBYViJGY+OAiI0SNoMTJmU/AajgF9CX+dbWAxZmB7Ot37rNC 2OISt57MZ4Kw5SWat85mhvhOQeL65utgF0kITGOUOLPjMTtIQkhAQ+Lhhb+sEEWyEkfPzmGB sH0lJlx7DtWwhFGiuwcSNhICDewST3bdYIOo0pKYcWQZlL2EXeLZl1wIO1ti7+zdTBC2l8S3 cwuZIJoXMEtsmfKcESIhI/Hn5S6oFZfYJLZvO8I2gVF7FpJfZyH5bxaS/2Yh+W8BI8sqRtHi 1OLi3HQjI73Uoszk4uL8PL281JJNjMCkcnDLb6sdjAefOx5iFOBgVOLh7a5VjBJiTSwrrsw9 xCjBwawkwptVAhTiTUmsrEotyo8vKs1JLT7EKM3BoiTOe9KTN0pIID2xJDU7NbUgtQgmy8TB KdXAGOS8QT5Z31t784mEJ2WrLjrqNccnsN/+WCJs2XWxbeUGuSlb4w2KBTbmBl7/NTuvSrjU OkznyFWZ9AK3Xe+n2lp9Ypf7Lcatdms+473T1ZzMrsvENA6KJxpmpMZbeM9yX/n+oU61bf7d tM5flVeCPxjxJxw79vusk8m0vzt6Dp31fOEsYNaoxFKckWioxVxUnAgAmIUs2SYDAAA= Archived-At: Subject: Re: [netmod] [Suspected Spam] Re: Notications in interface 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, 01 Dec 2017 16:20:59 -0000

By using YangPush and a well defined filter you could get a notification about if-status. (leaf oper-status if I am correct).

IMHO creating notifications that report on the change of a YANG defined value should generally be avoided; use YangPush!

(Just as we avoid dedicated get and edit rpcs)

regards Balazs


On 2017-12-01 04:47, Alex Campbell wrote:

That is a good question.

In retrospect that seems like an obvious omission from the standard YANG.

I'm not aware of any other YANG that adds such a notification.


From: netmod <netmod-bounces@ietf.org> on behalf of Bogaert, Bart (Nokia - BE/Antwerp) <bart.bogaert@nokia.com>
Sent: Wednesday, 29 November 2017 12:29 a.m.
To: netmod@ietf.org
Subject: [netmod] Notications in interface model

Hello,

In the interfaces module we notice support of if-mib feature indicating whether the IF-MIB is supported or not. Part of this feature is a flag to indicate whether an SNMP link-up/down trap has to be generated or not. Looking at the YANG model itself we notice that it does not foresee any similar capability. We were wondering whether it has been discussed as part of the YANG model definition for interfaces to define a general status change notification in case an interface goes down or comes up and whether the generation of such a notification can be enabled or disabled?

Regards, Bart Bogaert



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


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Dec 1 09:49:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA9127876 for ; Fri, 1 Dec 2017 09:49:39 -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=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 SAwwvIWjJRGO for ; Fri, 1 Dec 2017 09:49:36 -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 01D97127369 for ; Fri, 1 Dec 2017 09:49:35 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id j124so12600303lfg.2 for ; Fri, 01 Dec 2017 09:49: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=1Apk/ZTgvU9QYKb4eTEuWsl56QAxIXxYAv2q2KW74tc=; b=t0faKzyPFXJiZ8aSTQl0WgwSzGJ9pZLbH3JVZcm4+BIpMTvLFrBkOmRVMmWeaBXawc COGsbF7a74oGB18HPiAQ6ZfBmtAqCV7a5Vd9nqXRokHVZpJ8lYZy88+CIWrnSZcSnVGk fzAfiHusPsS5AoOrAFJdZwAADOxtzF72OohyVnEz8A9aSVDZNLS8qGiYL5hgEVXRbK6R mcNSqoKeKMzv5mCVfI1mDpvqjz1776q27LkCwAu/rAhzTVwsnm5388USzdgITBV3VNkM wykjEae82RTOY7zKEC4253oycBBKT09FfaOoHri+KY+0qCFEF2ZkPlcWIlSUdwawNLW7 AX7g== 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=1Apk/ZTgvU9QYKb4eTEuWsl56QAxIXxYAv2q2KW74tc=; b=KBouwHVvII1N/Y0clx9g5bexj7a8C3dB/cik2DF7J0OY69TVNWM5g1HBtMQu359Par Jvc9yLM+H69i4J/YGkmPsi5HJNesImlLTJg7eQ9dP2ISW3j6/pMorwz2gvBuqVn7LG5O uz8cpMYRLoZvlGuzAE/nLuHnkbClNBj8vRnckt2WzGsCskuwc1DsWnRcklsUC5b0Mb46 jE5m0zL0mIEtZHETABTghcuAOUFCL/jLpbxjy+flLKwztFv3h+1WRVvOZvnPnjqUGy9+ JVSYNmk2LQvYRrd4rsHdhCUdWtJzgI9O6ewp9AirjO2Qo87XxYgheD93eIYkdkabQeLK DTIQ== X-Gm-Message-State: AJaThX6RFFzOQwpohkHzewvTJnhBLlpxlQZ4Ydc7YGxOXFxTDcisidFo un+zl26MM/Xb4LbzwjkfoAVqvxGmtkNr5OQiay2h7g== X-Google-Smtp-Source: AGs4zMYqp5AePHdOgI/71ZgZv5wmRsue8mTwztJA7QoEajKkrKRvdlzpa8Bqy1FI8fDdCrwmL3kLbnPEKMmYmcsX+eg= X-Received: by 10.46.57.10 with SMTP id g10mr5090910lja.77.1512150574211; Fri, 01 Dec 2017 09:49:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 1 Dec 2017 09:49:33 -0800 (PST) In-Reply-To: <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> From: Andy Bierman Date: Fri, 1 Dec 2017 09:49:33 -0800 Message-ID: To: Balazs Lengyel Cc: Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Type: multipart/alternative; boundary="089e082f5ce4d2b8ed055f4afdcc" Archived-At: Subject: Re: [netmod] Use feature to advertise pre-nmda-support {was: WG Last Call: draft-ietf-netmod-rfc7223bis-00 ] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2017 17:49:40 -0000 --089e082f5ce4d2b8ed055f4afdcc Content-Type: text/plain; charset="UTF-8" On Fri, Dec 1, 2017 at 3:37 AM, Balazs Lengyel wrote: > Hello, > > https://tools.ietf.org/html/rfc7950#section-7.21.2 > > o "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster interoperability > with older/existing implementations. > > This means that a node that is deprecated MAY or MAY NOT be implemented. > YANG is considered an interface contract, however "maybe implemented" is > unusable in a contract. > I agree that the status-stmt is mostly worthless the way it is defined in RFC 7950. The good news is that the text in RFC 2578 (which it is based on) is much worse, so we are getting better over time. The word "permits", rather than "requires" indicates this is a MAY, not even a SHOULD, and certain not a MUST. YANG already has a statement defined for indicating such optional support: > the feature statement. > Deprecated works as if there would be an if-feature statement on each > deprecated schema node > where the server does not advertise whether the feature is supported of > not. Why is it not advertised? > > I would like to propose to use a feature here. This would allow the > client to understand if the container interfaces-state is implemented or > not. > > module ietf-interfaces { > feature pre-nmda-support { > description "The feature indicates that > schema parts representing state information > are deprecated but are still implemented." > } > > container interfaces {...} > > container interfaces-state { > if-feature pre-nmda-support ; > status deprecated; > ... > } > } > > This proposal seems useful. Maybe it could be generalized, because the issue is status=deprecated, not NMDA. > regards Balazs > > Andy > On 2017-11-28 20:29, Kent Watsen wrote: > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-rfc7223bis-00. > > Please recall that this update's intention is to > modify the YANG module to be in line with the NMDA > guidelines [1]. Reviewing the diff between the two > drafts [2] should reveal just this. > > The working group last call ends on December 12. > 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. > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt > > Thank you, > Netmod Chairs > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --089e082f5ce4d2b8ed055f4afdcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 1, 2017 at 3:37 AM, Balazs Lengyel <balazs.lengy= el@ericsson.com> wrote:
=20 =20 =20

Hello,

https://= tools.ietf.org/html/rfc7950#section-7.21.2

   o  "deprecated&quo=
t; indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

This means that a node t= hat is deprecated MAY or MAY NOT be implemented.
YANG is considered an interface contract,=C2=A0 however "maybe implemented" is unusable in a contract.


I agree that the status-stmt is mostly worthless the = way it is defined in RFC 7950.
The good news is that the text in = RFC 2578 (which it is based on) is much worse,
so we are getting = better over time.

The word "permits", ra= ther than "requires" indicates this is a MAY, not even a SHOULD,<= /div>
and certain not a MUST.

YANG already has a statement defined for indicating such optional support: the feature statement.
Deprecated works as if there would be an if-feature statement on each deprecated schema node
where the server does not advertise whether the feature is supported of not. Why is it not advertised?

I would like to propose to use a feature here. T= his would allow the client to understand if the container interfaces-state is implemented or not.=C2=A0 

module ietf-interfaces {
   feature pre-nmda-support {
       description "The feature indicates that=20
          schema parts representing state information=20
          are deprecated but are still implemented."
   }

  =C2=A0container interfac=
es {...}

   container interfaces-state {
      if-feature pre-nmda-support ;
      status deprecated;
      ...
=C2=A0}
}


= This proposal seems useful. Maybe it could be generalized,
becaus= e the issue is status=3Ddeprecated, not NMDA.

=C2= =A0

regards Balazs




Andy

=C2=A0
On 2017-11-28 20:2= 9, Kent Watsen wrote:
All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7223bis-00.

Please recall that this update's intention is to=20
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

The working group last call ends on December 12.
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.

[1] http=
s://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2] https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netm=
od-rfc7223bis-00.txt

Thank you,
Netmod Chairs


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



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

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

--089e082f5ce4d2b8ed055f4afdcc-- From nobody Fri Dec 1 14:41:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB4A12942F for ; Fri, 1 Dec 2017 14:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] 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 c3jYIx4mhaQx for ; Fri, 1 Dec 2017 14:41:13 -0800 (PST) Received: from mail-pl0-f67.google.com (mail-pl0-f67.google.com [209.85.160.67]) (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 A6303129434 for ; Fri, 1 Dec 2017 14:41:11 -0800 (PST) Received: by mail-pl0-f67.google.com with SMTP id d21so7043133pll.1 for ; Fri, 01 Dec 2017 14:41:11 -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=5jXnyIwrrSMgCWjGvXbPNyxv74HSlt1uLZmkUkXhDu4=; b=YqdGqicenWJUr+IzE4YJc56fIX4/CpmpbUMuWuVGgiae+vseQjjr5xI57yHB4tbtam COzJdpbHjQqUvO/mN2m45fH6EtLBzz/uCMak4/mqQiil/qZcQ001SfsEibIP8CcBAbat IFkuNgXoV0VCWoBfOTOTZC2LYB4Sr/BbOD/rg0GQ9nSa8mbOr/SvlqiUPmqtx8sVrh3e ciowWI+ogRkBkBdFfozDoLXwBfEQpMXVnoV2TLE7SJh5YwkO57eAX8+H6DkUe5lvuwAD MJWAY0kQgw0scjKbghyB1L9o6fV83ay5AjKU3IJYM7vzcXC+dZ2188sGLQLaRGFN1Rl9 MVDQ== X-Gm-Message-State: AJaThX7+Qsl+tMI5B2L90TpUXU4RX9s7BCGs8AaBN+z+WWOc4s+RqboP GaAqtTYwaHs0q95Cyo/ur/Qd3UxiB4U= X-Google-Smtp-Source: AGs4zMYFRtytgYDV6niGmKLbHY7f0eb6UzxsgHg9euqWhdRfGNGe5xSUgdVEpTJLMoIcgZCrGdiQDg== X-Received: by 10.84.238.140 with SMTP id v12mr7490254plk.356.1512168070742; Fri, 01 Dec 2017 14:41:10 -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 f9sm11766548pgv.8.2017.12.01.14.41.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 14:41:10 -0800 (PST) To: netmod@ietf.org References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> From: Randy Presuhn Message-ID: <3abeb1c3-68e8-a781-ed66-dace8084fa0a@alumni.stanford.edu> Date: Fri, 1 Dec 2017 14:41:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Use feature to advertise pre-nmda-support {was: WG Last Call: draft-ietf-netmod-rfc7223bis-00 ] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2017 22:41:14 -0000 Hi - On 12/1/2017 3:37 AM, Balazs Lengyel wrote: > Hello, > > https://tools.ietf.org/html/rfc7950#section-7.21.2 > > o "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster interoperability > with older/existing implementations. > > This means that a node that is deprecated MAY or MAY NOT be implemented. > YANG is considered an interface contract,  however "maybe implemented" > is unusable in a contract. From a client perspective, access control can have similar consequences. A contract only outlines some of the kinds of things that might possibly exist. It doesn't tell you what's actually there or whether you're allowed to do anything with them. Randy From nobody Fri Dec 1 16:23:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48D127078 for ; Fri, 1 Dec 2017 16:23:38 -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 TkBjZsZoE_Nb for ; Fri, 1 Dec 2017 16:23:36 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 9F418124E15 for ; Fri, 1 Dec 2017 16:23:35 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id e137so13519239lfg.5 for ; Fri, 01 Dec 2017 16:23: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=Zv7z5TJBkxvbg5HF2Uew/0XiEMXCuySXerCwEto8ytk=; b=kVIbBq1qwXz/3QCQPiyesM0Klx5r/uygFKmwQZVGnlseZtkZT0Q9Yt/CbPiKzryYiu LFPCrlgzkLetlOQDAMPf3pcRcJKEHqwwYzpG6Nbki53TZ8tSIqV66mt2bd+zspNUzUsr Uy5npbuwq7va5wFg0pLBFLfILXojvxSBW5Kbi+GO1JfUj60dQhMaNGlQcUN6vWJswvMf EsJWELTvI2xB63s7c8ZXZ6iz0ZsGK8yo/NPYUBisrOLWmFNbqFP3BhMXcuPPfktf72Ad diTu/8HvMzykMLAJBDBpQWFf3y9iJv9vfBkmfWp9GvJD2bo7lHzNPZ/Cugfbm2og9ijY rrGQ== 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=Zv7z5TJBkxvbg5HF2Uew/0XiEMXCuySXerCwEto8ytk=; b=gnbdKkO4ZOrazizc1grPVXHxZhZCKNEfOtNdJ6ShDZBz89RS2u0LRxut4ty3hLexrd +NxKfXTNmmC/SsUiA3/HpPGFB6HglZNJmg2WYYKfZ4SS+tyxj0M0FBM4sjwq+r4HcZXS TsVRrfBFJuiYpObcraaINlB7H3N0vGfiwvmSmhKYwdHH/cZnvis4WY0WboGn+owsq6lJ eVjBODxrn407F8t+O5bsXMTldWCFzGkeBfu6iZ49FzAt44H8VcMumIux3+qavoXk6Erp WT4n6hVLI0Pf7OfNSejkrcoSnvAZ1SkFRZnOP2/kclce0bzU13P5JO4oqO98lWc3Q+3P GxgQ== X-Gm-Message-State: AJaThX5JWOrJ4ome2Ht4LckRAYJ93v6RBD1f2nes+PjPy+e6ScVFIkdX pVQzmZF664ts8yemroXHmcL6D38ovC+3aQac71Ltsw== X-Google-Smtp-Source: AGs4zMZXYAlz9Dg5xkRF9A4HPY4POA410/I8vAa0AHf5fS8x/hS9dD3CrAhg7GCLv1Z5ErPzHKgujrM3Q/GNwTSRZEY= X-Received: by 10.46.126.1 with SMTP id z1mr6146250ljc.81.1512174213902; Fri, 01 Dec 2017 16:23:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 1 Dec 2017 16:23:33 -0800 (PST) In-Reply-To: <3abeb1c3-68e8-a781-ed66-dace8084fa0a@alumni.stanford.edu> References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> <3abeb1c3-68e8-a781-ed66-dace8084fa0a@alumni.stanford.edu> From: Andy Bierman Date: Fri, 1 Dec 2017 16:23:33 -0800 Message-ID: To: Randy Presuhn Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="089e0827ae18dbc859055f507e99" Archived-At: Subject: Re: [netmod] Use feature to advertise pre-nmda-support {was: WG Last Call: draft-ietf-netmod-rfc7223bis-00 ] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Dec 2017 00:23:38 -0000 --089e0827ae18dbc859055f507e99 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 1, 2017 at 2:41 PM, Randy Presuhn < randy_presuhn@alumni.stanford.edu> wrote: > Hi - > > On 12/1/2017 3:37 AM, Balazs Lengyel wrote: > >> Hello, >> >> https://tools.ietf.org/html/rfc7950#section-7.21.2 >> >> o "deprecated" indicates an obsolete definition, but it permits >> new/continued implementation in order to foster interoperability >> with older/existing implementations. >> >> This means that a node that is deprecated MAY or MAY NOT be implemented. >> YANG is considered an interface contract, however "maybe implemented" is >> unusable in a contract. >> > > From a client perspective, access control can have similar consequences. > A contract only outlines some of the kinds of things that > might possibly exist. It doesn't tell you what's actually there or > whether you're allowed to do anything with them. > > >From a vendor perspective the issue Balazs is raising can affect support contracts. YANG status-stmt does change the contract for the specific object. The status deprecated is essentially the same as obsolete. There is no useful warning that an object can be removed from a server in the future. The warning says "the object can be removed right now". The deprecated status could have been defined to be the same as current, except the object will likely go away in the future. Existing implementations MUST support the object until it is obsolete. New implementations SHOULD NOT include the object. For YANG linkage issues, new revisions SHOULD NOT add new statements that use deprecated objects. Existing linkage would be reliable to use until the referenced definition is obsolete. Randy > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0827ae18dbc859055f507e99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 1, 2017 at 2:41 PM, Randy Presuhn <randy_p= resuhn@alumni.stanford.edu> wrote:
Hi -

On 12/1/2017 3:37 AM, Balazs Lengyel wrote:
Hello,

https://tools.ietf.org/html/rfc7950#section-7= .21.2

=C2=A0 =C2=A0 o=C2=A0 "deprecated" indicates an obsolete definiti= on, but it permits
=C2=A0 =C2=A0 =C2=A0 =C2=A0new/continued implementation in order to foster = interoperability
=C2=A0 =C2=A0 =C2=A0 =C2=A0with older/existing implementations.

This means that a node that is deprecated MAY or MAY NOT be implemented. YANG is considered an interface contract,=C2=A0 however "maybe impleme= nted" is unusable in a contract.

>From a client perspective, access control can have similar consequences. A contract only outlines some of the kinds of things that
might possibly exist.=C2=A0 It doesn't tell you what's actually the= re or
whether you're allowed to do anything with them.


From a vendor perspective the issue Ba= lazs is raising can affect support contracts.
YANG status-stmt do= es change the contract for the specific object.
The status deprec= ated is essentially the same as obsolete. There is
no useful warn= ing that an object can be removed from a server in the future.
Th= e warning says "the object can be removed right now".
<= br>
The deprecated status could have been defined to be the same = as current, except
the object will likely go away in the future.= =C2=A0 Existing implementations MUST
support the object until it = is obsolete.=C2=A0 New implementations SHOULD NOT include the object.
=

For YANG linkage issues, new revisions SHOULD NOT add n= ew statements that use
deprecated objects. Existing linkage w= ould be reliable to use until the referenced definition is obsolete.
<= div>



Randy


Andy

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

--089e0827ae18dbc859055f507e99-- From nobody Sun Dec 3 18:46:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2DD124B18; Sun, 3 Dec 2017 18:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 geTstFRROrAG; Sun, 3 Dec 2017 18:46:22 -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 250661200C1; Sun, 3 Dec 2017 18:46:22 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4997BCADC9689; Mon, 4 Dec 2017 02:46:19 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 02:46:20 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 10:46:14 +0800 From: Qin Wu To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7223bis-00 Thread-Index: AQHTaH8mwis2iZPDB0aqvQnmsEUf+6MyghdA Date: Mon, 4 Dec 2017 02:46:14 +0000 Message-ID: References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> In-Reply-To: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 02:46:23 -0000 SSBoYXZlIHJlYWQgdGhpcyBkcmFmdCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGlj YXRpb24uDQpPbmUgcXVlc3Rpb24gSSBoYXZlIGlzIHdoeSByZmM3MjIzYmlzIG5vdCByZWZlcmVu Y2UgTk1EQSBndWlkZWxpbmVzIHNpbmNlIGl0IGdldCBpbiBsaW5lIHdpdGggTk1EQSBndWlkZWxp bmUsIG9yIE5NREEgZ3VpZGVsaW5lIGhhcyBiZWVuIA0KbWVyZ2VkIGludG8gcmZjNjA4N2Jpcz8N ClNob3VsZCB0aGlzIGRyYWZ0IHJlZmVyZW5jZSByZmM2MDg3YmlzPw0KDQotUWluDQotLS0tLdPK vP7Urbz+LS0tLS0NCreivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmddILT6se0gS2VudCBXYXRzZW4NCreiy83KsbzkOiAyMDE3xOoxMdTCMjnI1SAzOjI5DQrK1bz+ yMs6IG5ldG1vZEBpZXRmLm9yZw0Ks63LzTogbmV0bW9kLWNoYWlyc0BpZXRmLm9yZw0K1vfM4jog W25ldG1vZF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAwDQoN CkFsbCwNCg0KVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv biBkcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAwLg0KDQpQbGVhc2UgcmVjYWxsIHRoYXQg dGhpcyB1cGRhdGUncyBpbnRlbnRpb24gaXMgdG8gbW9kaWZ5IHRoZSBZQU5HIG1vZHVsZSB0byBi ZSBpbiBsaW5lIHdpdGggdGhlIE5NREEgZ3VpZGVsaW5lcyBbMV0uICBSZXZpZXdpbmcgdGhlIGRp ZmYgYmV0d2VlbiB0aGUgdHdvIGRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRoaXMuDQoN ClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIERlY2VtYmVyIDEyLg0KUGxlYXNl IHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCg0KUG9zaXRp dmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIGJlbGll dmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVz ZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCg0KWzFdIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kc2R0LW5tZGEtZ3VpZGVsaW5lcy0wMQ0KWzJdIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNi aXMtMDAudHh0DQoNClRoYW5rIHlvdSwNCk5ldG1vZCBDaGFpcnMNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0K bmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0K From nobody Sun Dec 3 18:47:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CCD124B18; Sun, 3 Dec 2017 18:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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_A6N0s9EvBU; Sun, 3 Dec 2017 18:47:33 -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 9B14B1200C1; Sun, 3 Dec 2017 18:47:33 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 91E3453CBAB90; Mon, 4 Dec 2017 02:47:30 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 02:47:31 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 10:47:24 +0800 From: Qin Wu To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7277bis-00 Thread-Index: AQHTaH8uQPbcvjqNt0+Zr1pndKQN96Mp3X4AgAilvYA= Date: Mon, 4 Dec 2017 02:47:24 +0000 Message-ID: References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> In-Reply-To: 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 02:47:35 -0000 U3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0LCBteSBzYW1lIHF1ZXN0aW9uIGlzIGFw cGxpZWQgdG8gdGhpcyBkcmFmdCBhcyB3ZWxsLg0KU2hvdWxkIHRoaXMgZHJhZnQgcmVmZXJlbmNl IE5NREEgZ3VpZGVsaW5lIG9yIHJmYzYwODdiaXM/DQoNCi1RaW4NCi0tLS0t08q8/tStvP4tLS0t LQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBL ZW50IFdhdHNlbg0Kt6LLzcqxvOQ6IDIwMTfE6jEx1MIyOcjVIDM6NDMNCsrVvP7IyzogbmV0bW9k QGlldGYub3JnDQqzrcvNOiBuZXRtb2QtY2hhaXJzQGlldGYub3JnDQrW98ziOiBbbmV0bW9kXSBX RyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzcyNzdiaXMtMDANCg0KW3Jlc2VuZGlu Z10NCg0KDQpBbGwsDQoNClRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb24gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzI3N2Jpcy0wMC4gIA0KDQpQbGVhc2UgcmVj YWxsIHRoYXQgdGhpcyB1cGRhdGUncyBpbnRlbnRpb24gaXMgdG8gbW9kaWZ5IHRoZSBZQU5HIG1v ZHVsZSB0byBiZSBpbiBsaW5lIHdpdGggdGhlIE5NREEgZ3VpZGVsaW5lcyBbMV0uICBSZXZpZXdp bmcgdGhlIGRpZmYgYmV0d2VlbiB0aGUgdHdvIGRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0 IHRoaXMuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIERlY2VtYmVyIDEy Lg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4N Cg0KUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQg YW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhDQpU aGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCg0KWzFdIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kc2R0LW5tZGEtZ3VpZGVsaW5lcy0wMQ0K WzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9k LXJmYzcyNzdiaXMtMDAudHh0DQoNClRoYW5rIHlvdSwNCk5ldG1vZCBDaGFpcnMNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFp bGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQo= From nobody Mon Dec 4 01:21:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33302126B7E for ; Mon, 4 Dec 2017 01:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 b5NDDA6CHoHh for ; Mon, 4 Dec 2017 01:21:45 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE245124207 for ; Mon, 4 Dec 2017 01:21:44 -0800 (PST) X-AuditID: c1b4fb30-cc1ff700000029e3-e0-5a2513a659a8 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3D.E1.10723.6A3152A5; Mon, 4 Dec 2017 10:21:43 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 4 Dec 2017 10:21:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nQA66N95ldVADve44Dxd49pE/yff1VsWuVgtTbKGYns=; b=dmIYOcJodk0YBzHiqctgNU29bVudiQoXLB15QexPEMnd0V6Y1P5fCSDmC2MEsIZcfUSE2lkeJdBCwy1dMm9Zt02dAME6NvXC9nwLCrMWq31TXi+zI8VjjwxsYOrsSxISmhFxljRiCtlpTiUxi9CA9I/vH2A49JG2OervHC3ULrU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.144] (91.82.100.59) by DB6PR07MB3431.eurprd07.prod.outlook.com (2603:10a6:6:23::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.1; Mon, 4 Dec 2017 09:21:40 +0000 To: Randy Presuhn , References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> <3abeb1c3-68e8-a781-ed66-dace8084fa0a@alumni.stanford.edu> From: Balazs Lengyel Message-ID: <73f6c8e0-6cc2-af24-6789-142d182ed6a6@ericsson.com> Date: Mon, 4 Dec 2017 10:21:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <3abeb1c3-68e8-a781-ed66-dace8084fa0a@alumni.stanford.edu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: AM6PR0502CA0031.eurprd05.prod.outlook.com (2603:10a6:209:1::44) To DB6PR07MB3431.eurprd07.prod.outlook.com (2603:10a6:6:23::22) X-MS-Office365-Filtering-Correlation-Id: 32ec1b5a-5dd2-4a79-d036-08d53af86d61 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:DB6PR07MB3431; X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 3:NVo7YEJ+cdb2rXUTapePxy0dbgdtjlTrn616cLmwKjHDqJhHhoUnLcL9hwJX/c4qIPN+Ipn2NaM8COhOlvOXThOtbowjRJbYBxeLZ30NAe4DcLfvceV0mxLblIrQhynxB8spPX+ftklfcIbTdNlBy3ego52fF9KWYEeKwC4Qn3ldIYL0jI9p5QZvkABQ8VWqqdSJ9SH62SQ7yuiC5zsw3fNNALUng7Tiu//m+0hRgqIudNvmcB8qSe4LjIjFxupv; 25:a3HFEYCeSDF9HJ55uFD+8ejmApcUaggxH1qwJi4tmm6l27Z83qlqcYalDpBap2rgQR9EuTB+su95sSxc9s6NC2ePHsj6h9gnbr373/ErI3wbMfAi1sV7XVa2p8rCj0txOuYitEYgesvnzF7AxtKgltqvVlDdTlaqBDZv7b0IQVpFClmjztNmBcGfz9X383HBQFnSlWkTFgak1kMAieXN/aG7X6fluTTV8B6zN5loFb9P9byfWXSvcJyI91PIL8MDG5mMP+z//QV7NJw6z0DZJ0xJ/xC3NY4ubFORp7rPdDPYA3DkIP+vGOTKXs6KZDDoMUrkSLVvWS5vl2D/qdXy0w==; 31:dUnSTD5hrR2/vPWUNExVRJepiLfg6E2KbODGfvbHH7i+cEES0uKlF0Ps6r7/tQkqDUXKOow9pac+KpGBU2ayiPZI4ZS0IWfdLnX+qIlXQyFHiFQdSXNcIjdy0yAdmYO8BRu3Lo3fkGVEJUPIJf3+Lf/HYyLWVyXEQtI+TC7qRwKrPD/0zl5vUnjBokf3eYtZlVfQZSJB0yCUzNHDIVHwjBGq3H5dp9KGih/MUqu8fSo= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB6PR07MB3431: X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 20:qquySU02QP+7QHsDaQY5/KxvCwsRIO0E9lIkeRkzFaGsxykmtfGRV2zG6cmqsk39R48n23OIbn8EUIB/46GQ2nekAL04scLEQSxHmWs8tgVwsJIxTa8TySCxvWqHB63/AP299dusRLt3Tqxo85wOZLkhhYO374n5UkhOjIbRgtAj8h/6czRLMy/q/K3nlTbwCeu39Y9xrevTUBrZnZ43mKjDFh7/QQu0F1pHNmfpetrNQuYeb0DNLgfLrkacxe8AnZT9GPi0exgsrScGodAMjz30Plx2sgZ8m6ZjNlm3aUiLZ7JwJTpuA46p+ZPO0IlNZ0oS9mP9ktKxmLG/eOOBTnCPzkWqLnLiYYeVhp2i3cXsq5qWOILCBFtx695XQjjGQRGLc7JlgUSxLK3PtITIhvF+njKjcqm/PGLOU4hcx6vqPlmxS7fbnJKbT3HWQTs6GQU1NFnALq5Wa6Dii7pIDTVrCAy/bvPW+1gRuqfe8m2IjIUxG6/4JY6gOAQp7hB/; 4:cqOA43j8v18G9C/TzzaWyPJ80tArCIi91g7Ay9rzL91ShqhtMpBhWFOUh/w073KrS567QPfBQC/CZLBpV61sihovCgb8HZY2qXbzqYIH+B0lGw/bZc1arn+NuU4UgK0RHXEExUvcpIOn9bWmoU1lxkrbNJftDpTKqehEPMlk0UvEWFJbm0EuGZp/sW2qXd0E9BpqIbTfqsj1Tf8teT5nIjXzq+eMkaJWHbFqJJ6+VYf7O7inwN8X/ahDnzCNOurddaDFieKB+G2TVne2zRqSzcS3ACd8ZNrXIe7HvjMoALPOafsk0s682Dw6mGWPPus5 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR07MB3431; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR07MB3431; X-Forefront-PRVS: 051158ECBB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(39860400002)(346002)(376002)(366004)(24454002)(252514010)(377424004)(199003)(189002)(2486003)(81166006)(81156014)(105586002)(106356001)(33646002)(8676002)(189998001)(101416001)(478600001)(65806001)(66066001)(47776003)(31686004)(65956001)(2950100002)(7736002)(2870700001)(230783001)(64126003)(229853002)(6666003)(6486002)(305945005)(76176011)(2906002)(54356011)(5660300001)(25786009)(50466002)(6116002)(3846002)(65826007)(97736004)(53546010)(68736007)(31696002)(36756003)(6306002)(2171002)(23676004)(53936002)(52146003)(16576012)(52116002)(83506002)(58126008)(316002)(67846002)(49976008)(16526018)(8936002)(966005)(86362001)(6246003)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3431; H:[159.107.197.144]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3TUIzNDMxOzIzOnBaMXErNkZheWh5K2xIL2JQUXpVWmZkYlRQ?= =?utf-8?B?Mzk5YnNHeWdWOFh1YzFTSllnRnRFSkc5b1dtRzlac20zQzNzUnpoK1RhQ3Rs?= =?utf-8?B?LzViQTk1ZGVsdjNRMUZIeWZhN293ZjZUeEVwMEdoelRQUWlqVTdEWjRNTEZj?= =?utf-8?B?MlJ3VDBtY0NZdWs3THE1MmZmT2VtQ1JBbkRvYUFYMjBJTXVGSXNBUnc3dnRX?= =?utf-8?B?djlZY0hVRXpTblFLSnJ2SVllU01qUHJIdEZWZWhmb2k0emUvS2loUjF1c0FN?= =?utf-8?B?bFRzQ3Z3cW9BRzFhM283UVl0RnhKRUpmdklXa051YmNUZ3l2cnNvQXl5Q1Nj?= =?utf-8?B?MlgyWXNNMkFabVhJNkZLNHlZYm1CeW5vd3ZGMHBXY2syQXVXazI3K0NUNFpp?= =?utf-8?B?QzJBWDc2NWNhemsycDA1TE1nLy9KaVlYRUpuNnVKT1VIZFpHN2V0SkpnZGFU?= =?utf-8?B?R2pHOW5IRUhQd1JRcEV4M3UxS0hLREFNMkw3T293NHNkT2FvamNMcXplVFNY?= =?utf-8?B?NFEyUC9aeUlxeGIvbWNBL0RnQnBEa1F6T1BoZTFPbzBrU2l4aFIwWm5sYWhL?= =?utf-8?B?Rk5ZcUd1dGZEdmtFSEk5emxDM0QxRlUyQlJyejRRbHRRbi94eXhHRlh0dTJo?= =?utf-8?B?dmZFUEp5QnRsQXR4bW1ON2JvQXpoZ3RaQmF4UWx2NUJTajhYczhUYVNhaWZM?= =?utf-8?B?Z2pXSTh6K3QrMHhiWGVkTXVkVnJITEF2cXJtNU00cTN3ZkNxSlQxRENjWXha?= =?utf-8?B?RTJybEc3R3RiZ29GS3J3aUhseTlGWFpRMXcyN0E5ZHR2SlpTbzVKcUt4Z3cw?= =?utf-8?B?djIydW1kMDZFcjJ5RnVCdFVSTjFyUVU4SGlia25xQlRGazMrQjJKcFViWjRm?= =?utf-8?B?RlJJYmtlMW1CMFFoeTdkb1JuVDBvQW96ZU91cDBPR3Y1OGRGcWVubnlrTG1Y?= =?utf-8?B?bHNzODRJSUJMNFU1bFY1aENGOVRyVHAwdGZ1RkhDSy9wRzZIa2tqanhFd2FD?= =?utf-8?B?TFZlaVJ4TTRtZEI2L2hTMC9HSXZSU2ZiMXBsVFdvVzk4QS9ZbUdDQVZsVklL?= =?utf-8?B?TjN4ajNxeE1rQ09aOGhoVzlvVGpzeHRYcTQ4TUhoYnlFNVVQcEloV2JRMnhZ?= =?utf-8?B?ekVNWjI1bkhmU0N0ZmJwSE8vOUR3d2dPY2FJckhmMkMwdlVIT05mVXFMaW5E?= =?utf-8?B?cUZDUm1zTTlzc2R2Sk51bC9oSW9ZMy9RUXZmRU4wa1hoMU00YUlJRUZkN0pK?= =?utf-8?B?Wm1SUmdaeG1WTFhTR2pkNTJkTytxSUc5UnlKZjEycWVYMFRhYTlyaDBRaStO?= =?utf-8?B?WU9iMFVVOUtyVCt4U2hUbzVmV1hFSDFYTXQvMlJTS3QyNUlXYVhOTlcwMlhw?= =?utf-8?B?eXNQL09NblJzOUR2ZzVYQ0c2YmQ0cG5lMmdENWJidTRKS1NTYlVrUkdocTBo?= =?utf-8?B?czM5bS9seURBL3pYSkdkTElEK0ZMeVZVVW92cGwwTkQwU1NUT01HUFFGay9Z?= =?utf-8?B?TWx1dWFJWmhHbHFxa2JtS0xGR0krelBWZVFjNm4xK2ZRTnRUK0JhaStmTjJu?= =?utf-8?B?cngzdlZreWNXQU1sc3pjSno4NDk2NVM3NmNxOTdkdmRFTm1sV3AybXR6UDdM?= =?utf-8?B?RkM0d3B6OXRBWGRUYXBQdWp5Z05VRWhOVG5pUnNiMDhBZUxBMXphWjFRc0J2?= =?utf-8?B?S3BzUHh6aXFNeVRKcVhWajg2bHNBZ3RQaDk2Y21UWE81OVlBTGtOSjhVbERY?= =?utf-8?B?NGpXWDFuaGM4Vk9oaXBVbjhjSExFQkNOZ011ZUxRWnJUQVZ0R0ZlL0RHdGpV?= =?utf-8?B?SmV5OWQ0ZkNoMFUycDV5K1VFb3dCb2tJQ01jdHo3Ylo1dEY5dmw4eEpyenZG?= =?utf-8?B?aEZMODBjQ2c2eFNZa1h2RWxlUFc3eGFyRjVObjVORWhJVkErMkJINXBXRDVz?= =?utf-8?B?NWlZWHd4R1cxZFRuQ3VVOEZERDFQUnRtVUtQclBOYlBSMHcvbGJjWWZQVkhl?= =?utf-8?B?Lzk3VE43ZTFmUnVIYVNUd1QreG5SaUJ0bGprM0Q3M3VDYjNWS2ljUkZ0Qmhs?= =?utf-8?Q?UKmk6PJk0hxQDskiDfI6lqEjF?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 6:8msJ7b6gkC/rtg5Dkfhvs1kcE4sQoj7fbT+yeeBzce76bLojHsE1xGOcJCP2n7KOzH1zCt6gUCEpJHULgUv9JWyznxKp/11nE/aRXw/X4WJtBTt/NPUN5JLnkdUQ2GIdMZCIBwNL/3DOZ35xiCcIHjrcnaFV936Nif0E/V9gQGpCkxUcdbm9Dzod8ZqKDOLgafaK0LQObtpojyIJ0GrjN+JgOjZAxBX3B29OwSGd3r+d140M37Gu1lA71AQS0AuIH/qzS6vlj8yosPovam7DKrmsdPN530lyThv4QHYLgs27SjWjooDciRYcOaGZ/oNNUHSNvYcwkBxDwuaNTPjnNXo5NPCnwCvcES7QGaqHuKw=; 5:Vd0BNCmsgaAMHMVEPp624loGbKZv217MM6mME5Vq8ZvBpETe1iZkwonBra7qQ3mWnHjVxavTIaOqrjyjGZcKdEq+q36A7ar+YDSPflhp8nBKOux6IUfvTD3EGdYtU8wug6MV+A5wO8vHJBpxj3UDyzl8lmwtJGXgygj/qzlsNKE=; 24:7CtfGFjRyMXSNccLRpM4tqh4MG6tpsqyJdffMPj4Gwke7qszaXd/GfEhZZeJ+1wBXYu0OrhmrrorTg2Um+WdHkwBLy+2T3HcvrTg8fKjtMI=; 7:gk4ILqvE0qg7oHzXOktMmfpadXftVPYm4N8Yb6UYgNI8TmQcnrHP2W+FrMnJEaAm4xz9gHhYkuFwjoO9zkUCHW8kjVY5AkVFP09Uuu9ktciiaX3+uBK1XCRiU+AP6mQNuHVHnJ8MCKLuQujCwypHQakcaAFaXuKn4A9r1Cxpg0bZw4lwX4gAPZ/6Tq+oK/ErhR7NmuTbszz7Bqjc7dJWtqAWXxOclqqaUhyr+QWrT52Cqejlo3iITBGgHjYKdQ4k SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2017 09:21:40.2032 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 32ec1b5a-5dd2-4a79-d036-08d53af86d61 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3431 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGbHdRne5sGqUQcNNRov5FxtZLfrOr2N3 YPL4ePgSi8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK+zjjIUnCLq+L8o53MDYwHOboYOTkkBEwk Hn6/zNrFyMUhJHCYUaLn+RpmCOc4o8S5PY2MIA6LQC+zxKPHp1hBWhgF4iR2rlkIZgsJtDJJ 7PhVBmILC5RLNH08xQZiiwh4SCxp/go1diOjxJ9rs8ASbAJGElP7z7OA2LwC9hJ3/9xjBLFZ BFQklv94BWaLCsRIHO6ZzgpRIyhxcuYTsHpOAXeJI3MXMoHYzAIWEjPnn2eEsOUlmrfOZoaw xSVuPZnPBPGbgsT1zddZIOxpjBKPThlBHK0h8fDCX1aIuK/EzpavbCCHSggsYZS4tqybHcJp YJfY+HQF1CRZiaNn50BN0pLY+OUDVNEPNol1y9cyQiSyJa4dXgNVZCXx+td3qPgCZonNS9wh bBmJuedWQNXsZJO4P01vAqP2LCSfzkLy3Swk381C8t0CRpZVjKLFqcVJuelGRnqpRZnJxcX5 eXp5qSWbGIGp4+CW3wY7GF8+dzzEKMDBqMTDu5FFNUqINbGsuDL3EKMEB7OSCK8DA1CINyWx siq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QDo9F9dsfnhnKfH2k8 FVxuxe7LuZhhEm9DzIk9ydVfP3n+yl1krB+ouiavJF39jdABp6MK6y+8/9jUPquCof7GpBBX +Xj2LVY1O7zPe9ecvcCyi110tv+HtCmvAha0RW4/sjDfkavwZHPpbgXj2fqvi/s4dqtalfWU FD76M0Hr2t7Wa8v+puYsUGIpzkg01GIuKk4EAMO6oyoZAwAA Archived-At: Subject: Re: [netmod] Use feature to advertise pre-nmda-support {was: WG Last Call: draft-ietf-netmod-rfc7223bis-00 ] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 09:21:47 -0000 On 2017-12-01 23:41, Randy Presuhn wrote: > Hi - > > On 12/1/2017 3:37 AM, Balazs Lengyel wrote: >> Hello, >> >> https://tools.ietf.org/html/rfc7950#section-7.21.2 >> >>     o  "deprecated" indicates an obsolete definition, but it permits >>        new/continued implementation in order to foster interoperability >>        with older/existing implementations. >> >> This means that a node that is deprecated MAY or MAY NOT be implemented. >> YANG is considered an interface contract,  however "maybe >> implemented" is unusable in a contract. > > From a client perspective, access control can have similar consequences. > A contract only outlines some of the kinds of things that > might possibly exist.  It doesn't tell you what's actually there or > whether you're allowed to do anything with them. > > Randy BALAZS : Disagree. From a client point of view it may look like the same, but from an operator (company) point of view it is different. If I am an operator like Vodafone or ATnT, if the restriction is based on access control, I can change my procedures to permit the usage. However if something is removed based on deprecated, I have no solution. -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Dec 4 01:23:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47280126C25; Mon, 4 Dec 2017 01:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 Izw4Out345qh; Mon, 4 Dec 2017 01:22:59 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA47124207; Mon, 4 Dec 2017 01:22:58 -0800 (PST) X-AuditID: c1b4fb2d-d57ff700000036aa-f7-5a2513f0ea6f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.F6.13994.0F3152A5; Mon, 4 Dec 2017 10:22:56 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 4 Dec 2017 10:22:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D4jT9Ps2TmpvYirithc3j0fh65W/t4ud9clD/JxO/D8=; b=UTOCX02MJQVdRWJd+iDLArHpoLrRDNVuQsrhidQJAlLMwIZ0lqzt7jTro//Ho7XzyK3HPahYEXhGMK1TGov1tIGSDKOulx5ZgVdEIPDKXT05qnwenuFXnXDZenJN7GOzIqoLtY7HMAEfNwWb8v2bjSZ1KJAQjvwi32KODf/qhn0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.144] (91.82.100.59) by DB6PR07MB3432.eurprd07.prod.outlook.com (2603:10a6:6:23::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.1; Mon, 4 Dec 2017 09:22:54 +0000 To: Andy Bierman CC: Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <926aa462-7e5a-350f-bc56-46b9ea2ac6b3@ericsson.com> From: Balazs Lengyel Message-ID: Date: Mon, 4 Dec 2017 10:22:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: VI1PR0602CA0020.eurprd06.prod.outlook.com (2603:10a6:800:bc::30) To DB6PR07MB3432.eurprd07.prod.outlook.com (2603:10a6:6:23::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9f763fb7-992f-4320-83c1-08d53af8999a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:DB6PR07MB3432; X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3432; 3:+15mFAddvDw2Pt1uUPh1NwX4AGGJsAYZKPUyzDCNTb+tIJIYmgh/XIkyZq3LIH3n4PYSqM0zKWYeTIjnJ3fYBn+Z/kunTtEOgU8MyOSX5SZJBFoWnV1B1RzkrWn/1yTr6IEMQDf8DmDZMF1V6VRr9hY4yzBSG0GShr3apejT2vaHc0cM8wvyrZP/R3JOwja3ui4QaAA07sjzBaJoZ1DPTooJO1do/0jRgkFXp+YjvZdWXetHcXt3OCloSYpJFQA9; 25:8gm51ENEsgSx/DJmm3jxfR+fBiafwpB+L8xM0KF/VcEIC19ZecVbNtYNvpYHEBwZPirhDl/jNN5bnFqlBfHY3OFgSEBImN8nMYUA6CV9Mz6Tl8c3Pdpq6OlWA+XpxOOp1yQAKSzK4jxjP6600o1JceVBlDsCJayfxZ9Isad1mJhZgWDxl8n81+zIzFXvrngErknN7Vcn0l/55LkWZNdDQ01JqNlk6PXfE6WHPt8b691qIIdG1tBgDVG72nNHOBkt5/TBaGuezMuGWAwSVNtAPqhqaqHYqCSvIlb2CjjrvamA8ai75tw0oYjHvipgxbiStzfJ47OzGGSM4nOtjKniyQ==; 31:WynIAmbgKBwjKrFdYNzbekUWLZkRDDSgzLGNd33qnwuagGJbtOBkuaNbmTFuJ1vPFgDooVTfVLxjEAnfEYO5jt+NLFHVi67tFN8T1/rfa5Qa4nTEX38UrRPdrHEnd0KLK8Pl8t8ugIApqdqvwWA8bKX2hfMk3eIJSMmNb2DZvwJoW3aCSm98dZ8QY1CVq9sM/s1Esc2ZuoNg8XJ5MU+LfQa4Rw+2PNzGKOJtc1fMQFk= X-MS-TrafficTypeDiagnostic: DB6PR07MB3432: X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3432; 20:F3ePkXWOgZjNP9XwwsIzgfstIB8COEjpVclj+840wubnqnzQUYElAQ4Texb6vEyVZ/pdS4uCKbhq7QJcprWTPKAQqjOGPnMQ7lAoOp9lp3t6rBdo7Y6Z5Jd6oAtgzUYEOHkn7WuGqckM8l+dCT3zGZvVvKtX1rzB0Nb3qvFCBM34+API7Hw+51g8g4YwauBeApnyrsoiC/aczNbdn9XB/YV+W018oBnqaMKP8e0jVqh9N9o8hSyyQVWL/0HKs7JZEfSCUhZWXwb7sETuLIoPZNpUh6auHogme2w2DqjIZ5RTf+JLpKPnZHuK2jbcbVjBrVYnqNfDfwnG2vi66FjGyPoLkOrUrWNfauutfhwAhFsbOaJRJhAV23GD/QQu8W/ZafqLaOu+IY+leDZn+huR6seW0LuAk/fk+BvRN6c0wscQamQMH5K7J0isdBfe++dPHkNwjC8UDnvcZmWRACSsxC5tIVAFraXuCOMlGf+1eomIeI4EXsIfYO+ktyEYFHPI; 4:aiUw93lXZPWKQEAfloOEvqyfQvUFgQx2Z0WG+bvqCaH/CsH3bmgqMPxSZhc7Jy+hfgeU0+G+jIaWQKw/SXRJ/cUgJoBLLn94HTymtahkm9S8tcrKsbHPjto3DTzJ1d1eJJXA3K+kdW9A7dJ7tebKgffb2drdltpavNDRBktn83tvpJ07ct6nWs3ZFOrhqwUNcEzvQLzxOukOZ7oSEP88ibl6h0wpi9XdR283XAFnvMKFAmsrv+Sbj2+Ky/mZksQaodMR9Jha4Xm8CCrW0m9Ki1kW92UAbSi7BXKWE5rknOuwkv+oJvy6Zb2hkofLBgjb+0LAlcbiyDkxA8DxCPZKGh6NI5vreWWcYowmkOW65Kc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR07MB3432; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR07MB3432; X-Forefront-PRVS: 051158ECBB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(346002)(376002)(39860400002)(199003)(252514010)(189002)(377424004)(24454002)(105586002)(25786009)(65826007)(16526018)(189998001)(36756003)(52116002)(606006)(8666007)(5660300001)(97736004)(33646002)(2906002)(86362001)(68736007)(4326008)(106356001)(101416001)(2486003)(561944003)(52146003)(31686004)(8936002)(83506002)(31696002)(23676004)(53546010)(53936002)(2950100002)(966005)(6246003)(230783001)(6916009)(16576012)(8676002)(316002)(50466002)(81156014)(81166006)(49976008)(2870700001)(478600001)(65956001)(65806001)(23846002)(229853002)(64126003)(6486002)(54896002)(6306002)(54906003)(236005)(58126008)(6666003)(6116002)(7736002)(3846002)(66066001)(54356011)(76176011)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3432; H:[159.107.197.144]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3TUIzNDMyOzIzOk1mQXVld0JBakZuS0J2ZzRwNUFVMDRETGJi?= =?utf-8?B?V3ZOSDdQQkRFTy82RFoyRzRLUGFocW5jQUJGUHkrSCtRZUV0VFhyaENma0N6?= =?utf-8?B?K1NFNkRwZUh5N1RheXp1TzdmVEExeVhNV1c3UUdya0FBam4yZ2diU2pkNzUy?= =?utf-8?B?ZTU1WUt6NHRjMHhvWlBPcEV5QUtyTWhyT29ZRXJkaVJpTWFFcTFLeVZ2T3RD?= =?utf-8?B?YTM2dUtNMVQ2THpTZjVLVHpscUhkK2lSQnF4SysxeHRMR0RWTnRKbHNQcXpq?= =?utf-8?B?c2NScXpLVEo3OVBJZXc0WHFRU3h1NXkxbm10TVFTdHpha3RJb0huZm1nM2Nl?= =?utf-8?B?WlBkaVdXK1VlYTRGRmRReVR6Sk81cVlsQWhDQjRJTTRyQ0Z2VTB4UnlVRVFp?= =?utf-8?B?d2tqakZpcUN4cGVRVFRBRWNlMkEyQVdTYmZSem8yQmtKeEhNbHRUODdjZXJZ?= =?utf-8?B?d0MyWVovMGxBSCtoWjFIblhTV25qUXJGTVlsNFQrZE9xcFIvY3dnZ05jQXhT?= =?utf-8?B?WEJqamZmaUFYbDR3SmdiRHVJblBod3VnejRyOWdhamtncDNKb0JIaFk3WFpj?= =?utf-8?B?ampXVVRHak8vVjdvUWdZUCtBZkhjTTVpVDZqSnNYanpZcVNYSWpEckkxN1Vm?= =?utf-8?B?YjQ1ejRGbzBDNkxDSXcvVGYxaGYzbkUwZUdaTVVZZW1uKy9GK3NuYXpGNVJw?= =?utf-8?B?aHFGTGpYQlRyQlNETGsxc09CRXppYkx1b0VEUkR1QlBGQytLSXdUSnVvek1X?= =?utf-8?B?Z0pFQ09aMzc1bFc4VnZYV05VY054KzNKUzhMdVRtanBTTlU4QUFWYmZ5WDZH?= =?utf-8?B?NW54Qkt3Nm00Uy80VzBJTHYvY0NRaHVZeTU1R2lNMGFqczRNdE0ydXgwb2xB?= =?utf-8?B?WUV6ZjRCTndpMWNmNzlxTytTdVdwVVZKSTlVOW1JOXRxWGdKN3pkTHo1Z0s5?= =?utf-8?B?TXRQa2RKazRMTWdscDNST2FCeW4yaitNaHVqd3ZsY1JBbVlZNDUyZWIxajNp?= =?utf-8?B?RXRPd2QzM05uemxHU3ZLNVlNTUg5T2ZTeHBONmtpclhTN3NkK3pOU2Fwbm1O?= =?utf-8?B?MDBHelUxejZWTlE5d1dJbVZLbzY4eHA5dnhoQTV0S05uVy9BN2M5NXhJRTFr?= =?utf-8?B?UnFQZUcwK0g2WTVDTDU2ZHlwVm1ZUzVmT3VwS09VUzlOektJb2ZUOUdCU2VH?= =?utf-8?B?QWVlalRiYWYvSnRjS0s0RkIybWtFSlpVQU5EcTV3ai85U0NoREFMbUkzTjVV?= =?utf-8?B?OE9VZ25qc0FycXhEN201WFVNcitFTGk5QmZDOXBuLzdyZ0V5UjdmZCt3U3Zt?= =?utf-8?B?cXNpUlFXMGx0T2RiUWNzYnJ6RU5zYzFTenAzdzI2bTRObERvUmJ5S1NoK2VS?= =?utf-8?B?cURRbWNvQmxaZ3J1WENWK1ZqanNyT040djNyWnkyV2FFWmRjRitGdnJBRWw2?= =?utf-8?B?UkM1Ti9tSWQxZ0VtVUNvcmJ4ZGJkdWRnY2l1ODhtTkdreXZ6WGkwaUNYN3Vq?= =?utf-8?B?L00rdmh4SWx6K2ZMaTd2N3FSVWtTWE5FbHJHZjNvVE51MFp0UFY2M21zclg1?= =?utf-8?B?ZCs2TWZ0Um53cGd1dmFOK2lUSjBrZXVhSHVSdlYyN0RaTHRFSXpmb1Q0OEtm?= =?utf-8?B?ZXVmdHk0K0w5ZXQ5aHJObVJXdGJJMFFkc1QzajVrTG42ZDJ0UVcrdFlyYlJC?= =?utf-8?B?VmcrMzVpNW9uaXdnZkdvMFl4VXdXb2hNSjBMZGhRZ2pvWnhWaTNIZmR4aFZp?= =?utf-8?B?MzFSVzZ2THBOS013YUp1Q2VCQjFDbEtmWmJTS3pTK0hMdjhCclo2Q1RDVjFr?= =?utf-8?B?UkZsSDN2Q2NPd2xMeTQwc2J3RjQxQ3VSUmVNcUxnUEJLa1YvMlRlWS9jaTM0?= =?utf-8?B?bi9aTkNYUGhXVk5zdHIrUDJmMkdYK2ZSd2lGRnF1TUd0czVrNmdCSEN1VTY3?= =?utf-8?B?WHJjTHVNTWNhS2x5em5ySWluSjA4T0s0UW5sRURPYzIvdHpOa3FSVEtCNGFO?= =?utf-8?B?NHVrTlprK1RpMkpOZ3Q3YlZIek5sVUdWanZEMmVMSUFOSnU5YWlNcVJCR3Jl?= =?utf-8?B?RkhtbTg1cGp4Z0dVcUd1djVFSmJzNHgyVllhNDR1aU1TdjFQbUFIdHFBMnVq?= =?utf-8?Q?PnK6wp9gekLtq2OshLHkNa6BgBuExx7IENnwfVOsqdM2?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3432; 6:ny53q+863KYKKnV3MdLDm5Fpuxu5vd7VVhbhpnakdmaCE3j0sf3rlP3oIzFLyzYROnK7lSLe4MFKvbacu0Tu0TQeiCE0MClSdX6KdI4UrA0iH/DcL8/bl19F3QdKw8rwlt4RrMOcOskYJxJhwGf0e/fKy7PKZtbrydzkcg3+A8ROrie6fj8Bh4C0Xq/R46pCbpUppnEH/5nL6J5Shj0x0YbqrBC8cUZhvvhiKIs4vt9kJtEUFkjsEOGd3SUbNKXfz9aROQKgr+lSvrICs0lds+Cf4R5MRnUQPb6Mxc1/QnJX5MdJTubzP1fsu0WNyil2zANyhV87pMG8GvHfwQ+H5HgKJGNEWbUczaWbuN/vkJQ=; 5:BIACHQnrepSnUZtCSbXS7ceVYsiODyOEktOmbbbf94lT1/gijcCkB88RZGrW7iq3wDxK3gMDAdxUvuEaJZmVOcJUOBbSIz4eAV9nkQ7XvWLmGO1gab1vbPJP4NuDAPKnbm0s7DrbA9tSIxCzwDAtUPqpUUcCzqNFqpOZ2eX6Gns=; 24:0MChwXThMpyM02wg8//mR046KMUwDJHPRX/oQNSPwtN4UYYBo3IR32eLw7sEPDc3vcy8cSJ1hRT4vPOTEaop5OLwXTkkoBIkNhjASCzZ2yQ=; 7:AIoLy/eh1vn6ga2Slj2jhwkJ7zQ2WJenvf346UiY5yMlnyVFxKvVEIzJ7yHvc9waaMwst3+ybgu7FqsZ1fmZRg2uZNJdXXSGNAUiL6GkNX232lM4OP5vkCif5HOxFd3cZOtITld19mRh6vYfK4/Q7dfNmnZsDI0wYRH1VM8fHfskbMj7XBYoD7WqoUhlQzIJg5948pH2Pb0Elw73UfX6+TcVZmlqPJ0ztB/JwGviV9IB4J8Yz6cqA9I2utp13Izq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2017 09:22:54.0821 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9f763fb7-992f-4320-83c1-08d53af8999a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3432 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUyM2K7je4HYdUog6XLtSweHJnFbnFgDrvF 6l41i/kXG1kdWDyWLPnJ5HG96Sq7R0v/RZYA5igum5TUnMyy1CJ9uwSujPl9C1gKjmtUfOi/ xdjAOEG6i5GTQ0LAROLRxm7mLkYuDiGBw4wS8xtns0M4xxkltqz+CZZhEehllnj0fgcLSAuj QJzEzjULWSGqWpkkOtb3sIMkhAXKJZo+nmIDsUUEVCUuzJ3IDGIzC9RLvL58CGrsbkaJvV+7 wSaxCRhJTO0/D2bzCthLrJvQxdjFyAG0TkWid682SFhUIEbicM90VogSQYmTM5+wgJRwCgRK TD9tADFeQ6J1zlx2CFtc4taT+UwQtrxE89bZzBBvKkhc33ydBeQECYHpjBIvXm4BmykE1Pzw wl9WiCJZiaNn57BA2L4SyzpfMUM0LGGUON1wlQ3CaWCX+HrtBtRYLYk9HUugxi5hl/g58Qw7 RCJbonfTdyYI21ui/dlldoiiBcwSn2d3M0IkZCTmnlvBMoFRZxaS92Yh+WkWkp9mIflpASPL KkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAtHJwy2/dHYyrXzseYhTgYFTi4bVgVY0SYk0s K67MPcQowcGsJMLrwAAU4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvSkzdKSCA9sSQ1OzW1ILUI JsvEwSnVwCgo+VJr5S2v0HQ10fdBOtdf5TO4Kir9vBzdmOWzvHHF2jsZswM/TGC/dZmv/aB+ /dskj3O/8zqFhEy0j2fLtfhd+rUi3jLZMsW1at1T7uiHoW2eD57YWeWIp8SJce35obnC2/Re cH9vyqY5F96E7VxvddU/3ZSrSLfRe+W/UKVOuXU8k8tnK7EUZyQaajEXFScCAK1s0GUnAwAA Archived-At: Subject: Re: [netmod] Use feature to advertise pre-nmda-support {was: WG Last Call: draft-ietf-netmod-rfc7223bis-00 ] X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 09:23:01 -0000



On 2017-12-01 18:49, Andy Bierman wrote:


On Fri, Dec 1, 2017 at 3:37 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello,

https://tools.ietf.org/html/rfc7950#section-7.21.2

   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

This means that a node that is deprecated MAY or MAY NOT be implemented.
YANG is considered an interface contract,  however "maybe implemented" is unusable in a contract.


I agree that the status-stmt is mostly worthless the way it is defined in RFC 7950.
The good news is that the text in RFC 2578 (which it is based on) is much worse,
so we are getting better over time.

The word "permits", rather than "requires" indicates this is a MAY, not even a SHOULD,
and certain not a MUST.

YANG already has a statement defined for indicating such optional support: the feature statement.
Deprecated works as if there would be an if-feature statement on each deprecated schema node
where the server does not advertise whether the feature is supported of not. Why is it not advertised?

I would like to propose to use a feature here. This would allow the client to understand if the container interfaces-state is implemented or not.  

module ietf-interfaces {
   feature pre-nmda-support {
       description "The feature indicates that 
          schema parts representing state information 
          are deprecated but are still implemented."
   }

   container interfaces {...}

   container interfaces-state {
      if-feature pre-nmda-support ;
      status deprecated;
      ...
 }
}


This proposal seems useful. Maybe it could be generalized,
because the issue is status=deprecated, not NMDA.


Andy

BALAZS: Yes, IMHO it should be generalized.
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Mon Dec 4 06:13:43 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95B81273B1; Mon, 4 Dec 2017 06:13:41 -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 nH0HXrlwqbL9; Mon, 4 Dec 2017 06:13:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD44B127369; Mon, 4 Dec 2017 06:13:39 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B65201AE0399; Mon, 4 Dec 2017 15:13:38 +0100 (CET) Date: Mon, 04 Dec 2017 15:12:18 +0100 (CET) Message-Id: <20171204.151218.126374036517223734.mbj@tail-f.com> To: Alex.Campbell@Aviatnet.com Cc: kwatsen@juniper.net, netmod@ietf.org, netmod-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <1512100854315.71747@Aviatnet.com> References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> <1512100854315.71747@Aviatnet.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] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 14:13:42 -0000 Alex Campbell wrote: > Hi, > > I noticed the table in section 3 has been mangled - it has extra > blank lines, entries in the wrong side of the table, and a missing > pipe in the bottom right corner. Thanks, now fixed. The table now looks like this: +----------------------------------+--------------------------------+ | YANG data node in | IP-MIB object | | /if:interfaces/if:interface | | +----------------------------------+--------------------------------+ | ipv4 | ipv4InterfaceEnableStatus | | ipv4/enabled | ipv4InterfaceEnableStatus | | ipv4/address | ipAddressEntry | | ipv4/address/ip | ipAddressAddrType | | | ipAddressAddr | | ipv4/neighbor | ipNetToPhysicalEntry | | ipv4/neighbor/ip | ipNetToPhysicalNetAddressType | | | ipNetToPhysicalNetAddress | | ipv4/neighbor/link-layer-address | ipNetToPhysicalPhysAddress | | ipv4/neighbor/origin | ipNetToPhysicalType | | ipv6 | ipv6InterfaceEnableStatus | | ipv6/enabled | ipv6InterfaceEnableStatus | | ipv6/forwarding | ipv6InterfaceForwarding | | ipv6/address | ipAddressEntry | | ipv6/address/ip | ipAddressAddrType | | | ipAddressAddr | | ipv4/address/origin | ipAddressOrigin | | ipv6/address/status | ipAddressStatus | | ipv6/neighbor | ipNetToPhysicalEntry | | ipv6/neighbor/ip | ipNetToPhysicalNetAddressType | | | ipNetToPhysicalNetAddress | | ipv6/neighbor/link-layer-address | ipNetToPhysicalPhysAddress | | ipv6/neighbor/origin | ipNetToPhysicalType | | ipv6/neighbor/state | ipNetToPhysicalState | +----------------------------------+--------------------------------+ YANG Interface Data Nodes and Related IP-MIB Objects /martin > > Apart from that this draft looks good to me. > ________________________________________ > From: netmod on behalf of Kent Watsen > Sent: Wednesday, 29 November 2017 8:29 a.m. > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-rfc7277bis-00. > > Please recall that this update's intention is to > modify the YANG module to be in line with the NMDA > guidelines [1]. Reviewing the diff between the two > drafts [2] should reveal just this. > > The working group last call ends on December 12. > 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. > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt > > Thank you, > Netmod 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 Dec 4 06:15:11 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5900B1273E2; Mon, 4 Dec 2017 06:15:10 -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 j6z14rHTh10s; Mon, 4 Dec 2017 06:15:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B46071275FD; Mon, 4 Dec 2017 06:15:07 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id BC5CC1AE0399; Mon, 4 Dec 2017 15:15:06 +0100 (CET) Date: Mon, 04 Dec 2017 15:13:46 +0100 (CET) Message-Id: <20171204.151346.1064508286573649657.mbj@tail-f.com> To: Alex.Campbell@Aviatnet.com Cc: kwatsen@juniper.net, netmod@ietf.org, netmod-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <1512101561233.63872@Aviatnet.com> References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <1512101561233.63872@Aviatnet.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] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 14:15:10 -0000 Alex Campbell wrote: > On page 37, "duplex" is mistyped as "duplexx". Thanks, now fixed. /martin > > Other than this minor error, I believe this draft is ready for publication. > > ________________________________________ > From: netmod on behalf of Kent Watsen > Sent: Wednesday, 29 November 2017 8:29 a.m. > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-rfc7223bis-00. > > Please recall that this update's intention is to > modify the YANG module to be in line with the NMDA > guidelines [1]. Reviewing the diff between the two > drafts [2] should reveal just this. > > The working group last call ends on December 12. > 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. > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.txt > > Thank you, > Netmod 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 Dec 4 06:35:27 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9E51274D2 for ; Mon, 4 Dec 2017 06:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, 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 QxTDOhV6c9jh for ; Mon, 4 Dec 2017 06:35:24 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 DF1E51273B1 for ; Mon, 4 Dec 2017 06:35:24 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id E9250140839 for ; Mon, 4 Dec 2017 07:35:18 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id hqbF1w00X2SSUrH01qbJoj; Mon, 04 Dec 2017 07:35:18 -0700 X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=kyB02z02BtSl7Dr3pmEA: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: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=LGWSqqYlILcqt3Gdlhr4rIySnb4OCN+RG9OoDHjlFNo=; b=Rq6HAXK729L+dDBZ7r+JuscXos rBAOk7jbaBN/Uq6Nr4vHi6VjnyU0AstxgMAomqlECu7oXmgwdwGErExc55WAdMc0qRlUhfC1+nvaV ucZHeY7AiAqaGsWOuYzLqqkPx; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:35402 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eLrpz-0041f1-0h; Mon, 04 Dec 2017 07:35:15 -0700 To: NetMod WG , NetMod WG Chairs From: Lou Berger Message-ID: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> Date: Mon, 4 Dec 2017 09:35:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: 1eLrpz-0041f1-0h 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]:35402 X-Source-Auth: lberger@labn.net X-Email-Count: 10 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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, 04 Dec 2017 14:35:26 -0000 All, This starts a second working group last call on draft-ietf-netmod-revised-datastores. As this is a 2nd LC that is focused on changes since the last LC, it closes in *one* week. The working group last call ends on December 11. Please send your comments to the netmod mailing list. At this point, we're most interested in verifying that previous comments are addressed since the last call on the -04 rev of the draft was held. A summary of changes can be found at https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4 A diff can be found at https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt Comments along the of: I have reviewed this version of the document and it addresses my previous comments would be particularly helpful. Thank you, Netmod Chairs From nobody Mon Dec 4 06:46:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8FA1274D2; Mon, 4 Dec 2017 06:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=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 aJNVKKzen14c; Mon, 4 Dec 2017 06:46:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47EBA12741D; Mon, 4 Dec 2017 06:46:09 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 514DB1AE0399; Mon, 4 Dec 2017 15:46:08 +0100 (CET) Date: Mon, 04 Dec 2017 15:44:48 +0100 (CET) Message-Id: <20171204.154448.2155397561484121188.mbj@tail-f.com> To: bill.wu@huawei.com Cc: kwatsen@juniper.net, netmod@ietf.org, netmod-chairs@ietf.org From: Martin Bjorklund In-Reply-To: References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> 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] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 14:46:11 -0000 SGksDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCBvdXIgZG9jdW1lbnRzIHJlZmVyZW5jZSB0aGUgZ3Vp ZGVsaW5lcyBkb2N1bWVudCwNCmFuZCBJIGRvbid0IHRoaW5rIHRoZXkgbmVlZCB0by4gIFJGQyA3 MjIzIGRvZXMgbm90IHJlZmVyZW5jZSBSRkMNCjYwODcsIGZvciBleGFtcGxlLg0KDQoNCi9tYXJ0 aW4NCg0KDQoNClFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPiB3cm90ZToNCj4gSSBoYXZlIHJl YWQgdGhpcyBkcmFmdCBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQo+ IE9uZSBxdWVzdGlvbiBJIGhhdmUgaXMgd2h5IHJmYzcyMjNiaXMgbm90IHJlZmVyZW5jZSBOTURB IGd1aWRlbGluZXMgc2luY2UgaXQgZ2V0IGluIGxpbmUgd2l0aCBOTURBIGd1aWRlbGluZSwgb3Ig Tk1EQSBndWlkZWxpbmUgaGFzIGJlZW4gDQo+IG1lcmdlZCBpbnRvIHJmYzYwODdiaXM/DQo+IFNo b3VsZCB0aGlzIGRyYWZ0IHJlZmVyZW5jZSByZmM2MDg3YmlzPw0KPiANCj4gLVFpbg0KPiAtLS0t LemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBLZW50IFdhdHNlbg0KPiDlj5HpgIHml7bpl7Q6IDIwMTfl ubQxMeaciDI55pelIDM6MjkNCj4g5pS25Lu25Lq6OiBuZXRtb2RAaWV0Zi5vcmcNCj4g5oqE6YCB OiBuZXRtb2QtY2hhaXJzQGlldGYub3JnDQo+IOS4u+mimDogW25ldG1vZF0gV0cgTGFzdCBDYWxs OiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAwDQo+IA0KPiBBbGwsDQo+IA0KPiBUaGlz IHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYt bmV0bW9kLXJmYzcyMjNiaXMtMDAuDQo+IA0KPiBQbGVhc2UgcmVjYWxsIHRoYXQgdGhpcyB1cGRh dGUncyBpbnRlbnRpb24gaXMgdG8gbW9kaWZ5IHRoZSBZQU5HIG1vZHVsZSB0byBiZSBpbiBsaW5l IHdpdGggdGhlIE5NREEgZ3VpZGVsaW5lcyBbMV0uICBSZXZpZXdpbmcgdGhlIGRpZmYgYmV0d2Vl biB0aGUgdHdvIGRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRoaXMuDQo+IA0KPiBUaGUg d29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBEZWNlbWJlciAxMi4NCj4gUGxlYXNlIHNl bmQgeW91ciBjb21tZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCj4gDQo+IFBvc2l0 aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxp ZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KPiBUaGlzIGlz IHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCj4gDQo+IFsxXSBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDENCj4g WzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9k LXJmYzcyMjNiaXMtMDAudHh0DQo+IA0KPiBUaGFuayB5b3UsDQo+IE5ldG1vZCBDaGFpcnMNCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1v ZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0K From nobody Mon Dec 4 08:26:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EBE127978 for ; Mon, 4 Dec 2017 08:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vngMJCgrvN-I for ; Mon, 4 Dec 2017 08:26:52 -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 C2782126B6D for ; Mon, 4 Dec 2017 08:26:52 -0800 (PST) Received: from birdie16 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 2CD9F63C0A for ; Mon, 4 Dec 2017 17:26:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512404811; bh=D+77gHPNdlgLldgxZgdv4v5GfQcadgdpZ5HPQsn+yWk=; h=From:To:Date; b=cpcIpUNTNugRVovBdIT9LWYc8ENx0L4nZx81vI36ZBOG+uhbf4afWKOXmdLH9VwEg w5NtH8BlcRQJ5eT8Q2FBOvCxH8hifi4WohHGb0q9YFBxA3wc5U121i8wTJr2qhux1T s4mmXBb9JMY/q1xPf+tRG735cs7YMrvrflPETJoI= Message-ID: <1512404811.1422.63.camel@nic.cz> From: Ladislav Lhotka To: NETMOD WG Date: Mon, 04 Dec 2017 17:26:51 +0100 Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 16:26:55 -0000 Hi, if we have augment "/target/node" { when "..."; ... } is the "when" expression supposed to be evaluated separately in each datastore, and the augment applied only in those datastores where the result is true? RFC 7950 says in sec. 7.21.5 that the context node for XPath evaluation is "the augment's target node in the data tree", but with NMDA we have multiple data trees, hence multiple target nodes. Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Dec 4 08:34:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D03127A91 for ; Mon, 4 Dec 2017 08:34:39 -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 yRNSiShHHy2C for ; Mon, 4 Dec 2017 08:34: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 90DDD1279EB for ; Mon, 4 Dec 2017 08:34:37 -0800 (PST) Received: from localhost (h-12-197.A165.priv.bahnhof.se [155.4.12.197]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C94F1AE0399; Mon, 4 Dec 2017 17:34:35 +0100 (CET) Date: Mon, 04 Dec 2017 17:34:31 +0100 (CET) Message-Id: <20171204.173431.1294203680272812703.mbj@tail-f.com> To: lhotka@nic.cz Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1512404811.1422.63.camel@nic.cz> References: <1512404811.1422.63.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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 16:34:39 -0000 Ladislav Lhotka wrote: > Hi, > > if we have > > augment "/target/node" { > when "..."; > ... > } > > is the "when" expression supposed to be evaluated separately in each datastore, > and the augment applied only in those datastores where the result is true? Yes. > RFC 7950 says in sec. 7.21.5 that the context node for XPath evaluation is "the > augment's target node in the data tree", but with NMDA we have multiple data > trees, hence multiple target nodes. We had multiple datastores even before NMDA. The when expression could be true in candidate but false in running. /martin From nobody Mon Dec 4 09:06:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82233124239 for ; Mon, 4 Dec 2017 09:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzLSX3NXWsPD for ; Mon, 4 Dec 2017 09:06:00 -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 8239C1200F3 for ; Mon, 4 Dec 2017 09:06:00 -0800 (PST) Received: from birdie16 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id B4834636D2 for ; Mon, 4 Dec 2017 18:05:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512407158; bh=Qqahm3ovhMLJlP/iZ6S/dFl7O33KUnlLA9gpRUScyT4=; h=From:To:Date; b=m8OaazOxuFWgcNlRWkJh2bYagg3taPe0TyN+m1f+KQOADhIBpEFR1ZdNxl+O8yqaQ XdJ2Q6ASthI80dMYH6NCcM5eBThyKMLzZqqTQXCH69xwqac/fAVF8FocuMnaLyZZQv 9QE36j3FUV+V+5AOV0Xg06NERQ2MRdRwp+9wHjR0= Message-ID: <1512407158.6635.8.camel@nic.cz> From: Ladislav Lhotka To: NETMOD WG Date: Mon, 04 Dec 2017 18:05:58 +0100 In-Reply-To: <20171204.173431.1294203680272812703.mbj@tail-f.com> References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 17:06:03 -0000 On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Hi, > > > > if we have > > > > augment "/target/node" { > > when "..."; > > ... > > } > > > > is the "when" expression supposed to be evaluated separately in each > > datastore, > > and the augment applied only in those datastores where the result is true? > > Yes. But then it cannot be guaranteed that the schema for is a superset of the schema of configuration datastores - the when expression can evaluate to false in but true in . Lada > > > RFC 7950 says in sec. 7.21.5 that the context node for XPath evaluation is > > "the > > augment's target node in the data tree", but with NMDA we have multiple data > > trees, hence multiple target nodes. > > We had multiple datastores even before NMDA. The when expression > could be true in candidate but false in running. > > /martin -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Dec 4 09:24:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1411F126B6D for ; Mon, 4 Dec 2017 09:24:20 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W1OLB8WDz7P for ; Mon, 4 Dec 2017 09:24:18 -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 39102126CC4 for ; Mon, 4 Dec 2017 09:24:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8E748677; Mon, 4 Dec 2017 18:24:16 +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 0VyXEY0jogQM; Mon, 4 Dec 2017 18:24:16 +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, 4 Dec 2017 18:24:16 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77D7F20128; Mon, 4 Dec 2017 18:24:16 +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 e5CsCNrNsjp4; Mon, 4 Dec 2017 18:24:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28A3120126; Mon, 4 Dec 2017 18:24:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 43AE9418B8A1; Mon, 4 Dec 2017 18:22:47 +0100 (CET) Date: Mon, 4 Dec 2017 18:22:47 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: NETMOD WG Message-ID: <20171204172247.rj3ilazharvzbyn6@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512407158.6635.8.camel@nic.cz> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 17:24:20 -0000 On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote: > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > > > Hi, > > > > > > if we have > > > > > > augment "/target/node" { > > > when "..."; > > > ... > > > } > > > > > > is the "when" expression supposed to be evaluated separately in each > > > > datastore, > > > and the augment applied only in those datastores where the result is true? > > > > Yes. > > But then it cannot be guaranteed that the schema for is a superset > of the schema of configuration datastores - the when expression can evaluate to > false in but true in . > For me, its still the same schema - a when expression does not change my notion of 'schema'. /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 Dec 4 09:29:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A3126CF9 for ; Mon, 4 Dec 2017 09:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 FeIku44gKqwG for ; Mon, 4 Dec 2017 09:29:39 -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 968DD126CC7 for ; Mon, 4 Dec 2017 09:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1696; q=dns/txt; s=iport; t=1512408578; x=1513618178; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=qfdDCilWU4nDM+uI6tScFHaqXjJa6nTLDh2kqpvGDQA=; b=iN/IwK8MNBBP880y+fvwlsD4by3yyugVgw2TnKxxUS4maXu/5LdeaMaN Rmf6Iv/NBipHjW9xpqu+R+3bMi53Jg7pcgrMBDvCgFjYAvVd3qnP0X5fX igo3YMit7Wi6R0+s5pSIKFhhNyleSLz8VqpaCbbweQyZHgYnaOd5LEQWt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDqhCVa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUQJ4N/ixSQA36YGAqFOwKFdhUBAQEBAQEBAQFrKIUiAQEBAQI?= =?us-ascii?q?BIw8BBVELGAICJgICVwYBDAYCAQGKFginX4IniloBAQEBAQEBAwEBAQEBASKBD?= =?us-ascii?q?4YYgWkpC4JBNog2gmMFomyVEYwLh0uOUYd8gTo1I4FNMhoIGxWCY4RVQTeKFgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.45,359,1508803200"; d="scan'208";a="628992" 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; 04 Dec 2017 17:29:36 +0000 Received: from [10.63.23.85] (dhcp-ensft1-uk-vla370-10-63-23-85.cisco.com [10.63.23.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB4HTZPS004274; Mon, 4 Dec 2017 17:29:36 GMT To: Ladislav Lhotka , NETMOD WG References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> From: Robert Wilton Message-ID: Date: Mon, 4 Dec 2017 17:29:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1512407158.6635.8.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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 17:29:41 -0000 Hi Lada, On 04/12/2017 17:05, Ladislav Lhotka wrote: > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Hi, >>> >>> if we have >>> >>> augment "/target/node" { >>> when "..."; >>> ... >>> } >>> >>> is the "when" expression supposed to be evaluated separately in each >> datastore, >>> and the augment applied only in those datastores where the result is true? >> Yes. > But then it cannot be guaranteed that the schema for is a superset > of the schema of configuration datastores - the when expression can evaluate to > false in but true in . I think that comes down to terminology, RFC 7950 section 7.21.5 on when statements just talks about making data definition statements conditional.  I don't really think that when statements (or choice statements) change the schema associated with a datastore, they just make parts of it inactive based on the current data.  I.e. you wouldn't expect different information to be returned via YANG library depending on how particular when statements in the implemented modules get evaluated. Is seems to me that the when processing falls out quite naturally. Is there a scenario where you think that this could cause a problem? Thanks, Rob > > Lada > >>> RFC 7950 says in sec. 7.21.5 that the context node for XPath evaluation is >> "the >>> augment's target node in the data tree", but with NMDA we have multiple data >>> trees, hence multiple target nodes. >> We had multiple datastores even before NMDA. The when expression >> could be true in candidate but false in running. >> >> /martin From nobody Mon Dec 4 09:36:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3E2124239 for ; Mon, 4 Dec 2017 09:36:48 -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 Myra5o_ehF9m for ; Mon, 4 Dec 2017 09:36:46 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 4A7D612009C for ; Mon, 4 Dec 2017 09:36:46 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id f20so20105678lfe.3 for ; Mon, 04 Dec 2017 09:36: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; bh=xGGLhYlf5eq2J43hRwu4zCezNzcnzsIN0Z+kV/729gA=; b=aPL8BZ7M0ozkt4+mIASIIFyC9rs1dyAjqXC9S40pt0D7yyXVHuimux0dw0twiU+kvd o3j90QPOo35qPjUlFf0k6+sizeeML0yfWCGXKAMEbXmCLTBP3kA0HI74mHdQjXmem9kn /QqpIAbQmd6zd3MLQQlEj0kpRB4lO3GW5n+YTjKoj4YWNSAfioVrdHRrLWSUjdijKSaa vJmCaLeqWUxo9335i1s1bBD+yEKOnBQub1a0t3VA2nCHRbfkHmChD2j0q28LjpMdoU1C spEr4xtct3gJyOLc52BFQRdCvD/mCkdRAb6NmFu5VzBhPH2FkvZnivJMeDHpv30EjvTP g17g== 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=xGGLhYlf5eq2J43hRwu4zCezNzcnzsIN0Z+kV/729gA=; b=pmbkUirI8XjUUvJbBcg8c98VOlklWrrSBQ5sWbnLygwYeO6PIXg40rkgV4xNtE0b8e S196WDS50O91FgovQc0zo+tt+f/O4rzVLTa7olasQNGd+exTUPs7CdsvdSDIrMlgkl/e zgjZm0IyQo/fepAcU0jZKe3j7ztURCZhyck2LqRZ33C9ZyycMC3dloyj/PHqsxEVI1jh 4ifodSKoMQpu8tANh587ew6hbRNdRDjdr2sfd6jnPJos6kDz5dRRqkjVoxUapZepirgt /mYntIvtAGYIv5BqEK4Yh1lFoOygkW1ouqGFvs21nMlQ008R5hTbzGM7DcHN7ZuD7bu5 1Pjg== X-Gm-Message-State: AKGB3mK6dkdWGWrWeucc/ADJTfvdE+ny7knqymPnlepzUxdcglPwzWxv jVLrHECFQ+IzFGS8Sqof3nCccMcAhIkK0h02v+P+QQ== X-Google-Smtp-Source: AGs4zMak42ZnVXPb9Ug5KBAF9waInWd6nUe9VTapWoyCd/fWmp1nwDGePlDpbKOP2hgAJ9lq9zuiMfHHBATm+riLf2Q= X-Received: by 10.46.57.10 with SMTP id g10mr222192lja.77.1512409004592; Mon, 04 Dec 2017 09:36:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Mon, 4 Dec 2017 09:36:43 -0800 (PST) In-Reply-To: <20171204172247.rj3ilazharvzbyn6@elstar.local> References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> From: Andy Bierman Date: Mon, 4 Dec 2017 09:36:43 -0800 Message-ID: To: Juergen Schoenwaelder , Ladislav Lhotka , NETMOD WG Content-Type: multipart/alternative; boundary="089e082f5ce479687e055f8729a9" Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 17:36:48 -0000 --089e082f5ce479687e055f8729a9 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 9:22 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote: > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > Hi, > > > > > > > > if we have > > > > > > > > augment "/target/node" { > > > > when "..."; > > > > ... > > > > } > > > > > > > > is the "when" expression supposed to be evaluated separately in each > > > > > > datastore, > > > > and the augment applied only in those datastores where the result is > true? > > > > > > Yes. > > > > But then it cannot be guaranteed that the schema for is a > superset > > of the schema of configuration datastores - the when expression can > evaluate to > > false in but true in . > > > > For me, its still the same schema - a when expression does not change > my notion of 'schema'. > Agreed, but it changes the validation results against the schema. As Martin pointed out, we already have this separate validation issue in . This is not a problem though because only is required to pass validation tests. I think NMDA works out fine because the YANG validation of config=true nodes is done in , not in . Only the config=false nodes would be validated in , done by the client, not the server. (Server implementations do not validate their own output). > /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 > --089e082f5ce479687e055f8729a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2017 at 9:22 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lh= otka wrote:
> On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > > Hi,
> > >
> > > if we have
> > >
> > > augment "/target/node" {
> > >=C2=A0 =C2=A0when "...";
> > >=C2=A0 =C2=A0...
> > > }
> > >
> > > is the "when" expression supposed to be evaluated = separately in each
> >
> > datastore,
> > > and the augment applied only in those datastores where the r= esult is true?
> >
> > Yes.
>
> But then it cannot be guaranteed that the schema for <operational&g= t; is a superset
> of the schema of configuration datastores - the when expression can ev= aluate to
> false in <operational> but true in <intended>.
>

For me, its still the same schema - a when expression does not change
my notion of 'schema'.


Agreed, but it changes the validation results against the schema.
As Martin pointed out, we already have this separate validation iss= ue in <candidate>.
This is not a problem though because onl= y <running> is required to pass validation tests.

I think NMDA works out fine because the YANG validation of config=3Dt= rue nodes
is done in <intended>, not in <operational>= .=C2=A0 Only the config=3Dfalse nodes
would be validated in <o= perational>, done by the client, not the server.
(Server imple= mentations do not validate their own output).


=

/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<http://www.jacobs-university.de/>

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

--089e082f5ce479687e055f8729a9-- From nobody Mon Dec 4 09:47:43 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94432126C2F for ; Mon, 4 Dec 2017 09:47:41 -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 ID_z8EPCOFPI for ; Mon, 4 Dec 2017 09:47:40 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 A3D0612025C for ; Mon, 4 Dec 2017 09:47:39 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id f18so20119137lfg.8 for ; Mon, 04 Dec 2017 09:47:39 -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=HhF1ySaA0pHVlhHHskDYVP6wq2PN8KVJaIGnYaWiXfU=; b=pDPjoIQZwyYIBwg+cN8aDs1fsYCu7rHbjAQCPeVeSJ9PDxvd4ULxkUyfIW3GoI2ysy NP+TzojNe4BBI0mNxKqdTEispzXCmaaomWv8/Adws9tZYoOZz1dcvTvvlnYUk+LwiiJC i+FCPo2DJuHsy7hpTJS6gr4U4iXdXtkkKPJmAfVVnh/qkTwMr8LmAhvgJCwXLKCP/Fpv DpENDc3ISu3BBFwuzn6HxIqw3oPkCQcZs/F55wLGnURjBFMnMH5QhBtL9xMCsZu6AfsA T48RrdAEZN8d7OYxsHohQ9YW8Bh+zS3oL7xbuRV4+l24XRdAgM/erMYn6BD4Vq/LWD68 ZKng== 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=HhF1ySaA0pHVlhHHskDYVP6wq2PN8KVJaIGnYaWiXfU=; b=C8XG6DdKDApN6YLenWNaSaPB4V+1xP2lc7nIubpc9f7vPLuaBmzko5xgTutKja0Hjz 8FYa9QWZ9LV7jSrIN9DbMmBv2aUjq73OwZIROmIP1iwE0IE+bYfR8eMzjnBIq6XXq9Ym z/svZ4rLK/xJmiOdDT2bKmM71t2nAJ/qjexJDGafnZPQyIUm5jskCNooNpS+x6qMhVrv bOsHG5xKtIQlXRoX7GcwbZP6UCtvCFW400dVBhpqbH4n9X4uhKT54lwazOvmBQQWQ/yL Zd6XivzumIdxj9UoPmJMBHZid4AXhgxEXO/Nf3xjciBRVfY/nTPnJzXHMvD7int9jm5D SJGQ== X-Gm-Message-State: AJaThX5KRecEw78wMQlCMpjSdbzVSJcTHq2nVGqTme9JDYuUTt7U/W1S Ax4TSTAOzviqajVt99SrHf7zggWFMVCOESckVlmE6A== X-Google-Smtp-Source: AGs4zMY/tDOShJwRTlBx/uxFmbzNHH1SR0ymRdkew6lpGkKcSyHcQikhLGcc/s5Ezl/yxeQ1SSvaZpCRViZs13rmYws= X-Received: by 10.25.147.67 with SMTP id v64mr6382479lfd.99.1512409657851; Mon, 04 Dec 2017 09:47:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Mon, 4 Dec 2017 09:47:37 -0800 (PST) In-Reply-To: <1512407158.6635.8.camel@nic.cz> References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> From: Andy Bierman Date: Mon, 4 Dec 2017 09:47:37 -0800 Message-ID: To: Ladislav Lhotka Cc: NETMOD WG Content-Type: multipart/alternative; boundary="f403045c31c269564b055f8750e2" Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 17:47:41 -0000 --f403045c31c269564b055f8750e2 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 9:05 AM, Ladislav Lhotka wrote: > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: > > > Hi, > > > > > > if we have > > > > > > augment "/target/node" { > > > when "..."; > > > ... > > > } > > > > > > is the "when" expression supposed to be evaluated separately in each > > > > datastore, > > > and the augment applied only in those datastores where the result is > true? > > > > Yes. > > But then it cannot be guaranteed that the schema for is a > superset > of the schema of configuration datastores - the when expression can > evaluate to > false in but true in . > > I see your point now. The server has to evaluate the when-stmts in operational. Even though the schema trees are the same, the client has a complex task comparing to . However it is no different than the existing complexity comparing to . > Lada > > Andy > > > > > RFC 7950 says in sec. 7.21.5 that the context node for XPath > evaluation is > > > > "the > > > augment's target node in the data tree", but with NMDA we have > multiple data > > > trees, hence multiple target nodes. > > > > We had multiple datastores even before NMDA. The when expression > > could be true in candidate but false in running. > > > > /martin > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f403045c31c269564b055f8750e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2017 at 9:05 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:
On Mon, 2017-12-04 at 17:34 +0= 100, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
> > Hi,
> >
> > if we have
> >
> > augment "/target/node" {
> >=C2=A0 =C2=A0when "...";
> >=C2=A0 =C2=A0...
> > }
> >
> > is the "when" expression supposed to be evaluated separ= ately in each
>
> datastore,
> > and the augment applied only in those datastores where the result= is true?
>
> Yes.

But then it cannot be guaranteed that the schema for <operational> is= a superset
of the schema of configuration datastores - the when expression can evaluat= e to
false in <operational> but true in <intended>.



I see your point now.
The server has to evaluate the when-stmts in operational.
Even though the schema trees are the same, the client has a complex task = comparing
<intended> to <operational>.=C2=A0 However = it is no different than the existing
complexity comparing <can= didate> to <running>.

=C2=A0
Lada


Andy
=C2=A0
>
> > RFC 7950 says in sec. 7.21.5 that the context node for XPath eval= uation is
>
> "the
> > augment's target node in the data tree", but with NMDA w= e have multiple data
> > trees, hence multiple target nodes.
>
> We had multiple datastores even before NMDA.=C2=A0 The when expression=
> could be true in candidate but false in running.
>
> /martin
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

--f403045c31c269564b055f8750e2-- From nobody Mon Dec 4 10:10:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99283127F0E for ; Mon, 4 Dec 2017 10:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGxkP1WAXIvN for ; Mon, 4 Dec 2017 10:09:54 -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 A6061127B52 for ; Mon, 4 Dec 2017 10:09:53 -0800 (PST) Received: from birdie16 (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id D30A263B45; Mon, 4 Dec 2017 19:09:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512410991; bh=BRbjhjRHSf9WmhBp7CzIkzJqAav5ymEVoYAQlYgiRkM=; h=From:To:Date; b=cmEtsrGt4f9mmZPgMdrTP2rWKsNorPtN49fBQGhBRPQzVYRvzufUMoQX57en+BGC3 A4AgATphDisaI4J9WiOxpPxcPmu+D9ffq/PsTnSVLXferEWPtIUJpnya72ml3BHXlA 0vpLDucYt1lUy6lZGYp/Hhl55HPDOuA55yoOcio4= Message-ID: <1512410991.8751.4.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder Cc: NETMOD WG Date: Mon, 04 Dec 2017 19:09:51 +0100 In-Reply-To: <20171204172247.rj3ilazharvzbyn6@elstar.local> References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 18:09:58 -0000 On Mon, 2017-12-04 at 18:22 +0100, Juergen Schoenwaelder wrote: > On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote: > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > Hi, > > > > > > > > if we have > > > > > > > > augment "/target/node" { > > > > when "..."; > > > > ... > > > > } > > > > > > > > is the "when" expression supposed to be evaluated separately in each > > > > > > datastore, > > > > and the augment applied only in those datastores where the result is > > > > true? > > > > > > Yes. > > > > But then it cannot be guaranteed that the schema for is a > > superset > > of the schema of configuration datastores - the when expression can evaluate > > to > > false in but true in . > > > > For me, its still the same schema - a when expression does not change > my notion of 'schema'. Well, according to draft-ietf-netmod-revised-datastores-07: o 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. And "when" determines whether a given schema node is valid or not. So if a schema node is invalid in the schema of but valid in the schema of , then the former can hardly be a superset of the latter. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Dec 4 10:20:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0412869B for ; Mon, 4 Dec 2017 10:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7mEqQ7ccCQ8 for ; Mon, 4 Dec 2017 10:20:17 -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 41DD1128656 for ; Mon, 4 Dec 2017 10:20:17 -0800 (PST) Received: from birdie16 (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 7603563597; Mon, 4 Dec 2017 19:20:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512411615; bh=9pmQgrzD+c+ZGNlEfRkzX3jOq4bgGrfKOiEa0Bparb0=; h=From:To:Date; b=KFETxIJecXfBy0kDVl0UdXIezkYiRiap0tffFmhYXWhb5NhlyomytPnFRdIgYtzUW r97Kd9jN2XDDE/Vu7rgZI2TFxoqNZngQvsPgqlGTsQAED3IiFZ4QXOp4IgSgsxFI/J nM+isipuT06A/fZ7jZmVQT6YETBrAQj879OzvMg4= Message-ID: <1512411615.8751.11.camel@nic.cz> From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , NETMOD WG Date: Mon, 04 Dec 2017 19:20:15 +0100 In-Reply-To: References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 18:20:19 -0000 On Mon, 2017-12-04 at 09:36 -0800, Andy Bierman wrote: > > > On Mon, Dec 4, 2017 at 9:22 AM, Juergen Schoenwaelder university.de> wrote: > > On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote: > > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > > > > > Hi, > > > > > > > > > > if we have > > > > > > > > > > augment "/target/node" { > > > > > when "..."; > > > > > ... > > > > > } > > > > > > > > > > is the "when" expression supposed to be evaluated separately in each > > > > > > > > datastore, > > > > > and the augment applied only in those datastores where the result is > > true? > > > > > > > > Yes. > > > > > > But then it cannot be guaranteed that the schema for is a > > superset > > > of the schema of configuration datastores - the when expression can > > evaluate to > > > false in but true in . > > > > > > > For me, its still the same schema - a when expression does not change > > my notion of 'schema'. > > > Agreed, but it changes the validation results against the schema. > As Martin pointed out, we already have this separate validation issue in > . > This is not a problem though because only is required to pass > validation tests. This is not true because "when" constraints are among those that have to be satisfied in *all* data trees (sec. 8.1 in RFC 7950). I have argued many many times that it is conceptually wrong to make the schema dependent on an instance data tree that the schema defines. If "when" was just a special "must", everything would be fine. Lada > > I think NMDA works out fine because the YANG validation of config=true nodes > is done in , not in . Only the config=false nodes > would be validated in , done by the client, not the server. > (Server implementations do not validate their own output). > > > > /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 > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Dec 4 12:01:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BC212894A for ; Mon, 4 Dec 2017 12:01:53 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NpXCczT3QEe for ; Mon, 4 Dec 2017 12:01: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 AB83812711E for ; Mon, 4 Dec 2017 12:01: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 7B148699; Mon, 4 Dec 2017 21:01:50 +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 9ijlk4Z3KaKg; Mon, 4 Dec 2017 21:01:49 +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, 4 Dec 2017 21:01:50 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47E2320128; Mon, 4 Dec 2017 21:01:50 +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 nfPJBtdYxoKN; Mon, 4 Dec 2017 21:01:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDA7920126; Mon, 4 Dec 2017 21:01:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C6CE418BADC; Mon, 4 Dec 2017 21:00:20 +0100 (CET) Date: Mon, 4 Dec 2017 21:00:19 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: NETMOD WG Message-ID: <20171204200019.2xvocmusfwfatqav@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> <1512410991.8751.4.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512410991.8751.4.camel@nic.cz> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 20:01:53 -0000 On Mon, Dec 04, 2017 at 07:09:51PM +0100, Ladislav Lhotka wrote: > > Well, according to draft-ietf-netmod-revised-datastores-07: > > o 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. > > And "when" determines whether a given schema node is valid or > not. So if a schema node is invalid in the schema of > but valid in the schema of , then the former can hardly be > a superset of the latter. I do not follow your notion of 'schema node is valid or not'. Where is this concept defined? I think RFC 7950 talks about validation of data trees against a "schema". Perhaps there are places where the wording is not clear enough? I know that there are places where the RFC 7950 text says just "node" without being explicit about the distinction between schema node and corresponding data nodes. If this is an issue here, we may consider posting erratas to clear things up. /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 Dec 4 13:09:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6221267BB for ; Mon, 4 Dec 2017 13:09:20 -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 6BFqf-TorxHU for ; Mon, 4 Dec 2017 13:09:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 97B42124BAC for ; Mon, 4 Dec 2017 13:09:18 -0800 (PST) Received: from localhost (h-12-197.A165.priv.bahnhof.se [155.4.12.197]) by mail.tail-f.com (Postfix) with ESMTPSA id B84711AE0399; Mon, 4 Dec 2017 22:09:16 +0100 (CET) Date: Mon, 04 Dec 2017 22:09:16 +0100 (CET) Message-Id: <20171204.220916.1239542403096469961.mbj@tail-f.com> To: lhotka@nic.cz Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1512410991.8751.4.camel@nic.cz> References: <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> <1512410991.8751.4.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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 21:09:21 -0000 Ladislav Lhotka wrote: > On Mon, 2017-12-04 at 18:22 +0100, Juergen Schoenwaelder wrote: > > On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote: > > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > > > > > Hi, > > > > > > > > > > if we have > > > > > > > > > > augment "/target/node" { > > > > > when "..."; > > > > > ... > > > > > } > > > > > > > > > > is the "when" expression supposed to be evaluated separately in each > > > > > > > > datastore, > > > > > and the augment applied only in those datastores where the result is > > > > > true? > > > > > > > > Yes. > > > > > > But then it cannot be guaranteed that the schema for is a > > > superset > > > of the schema of configuration datastores - the when expression can evaluate > > > to > > > false in but true in . > > > > > > > For me, its still the same schema - a when expression does not change > > my notion of 'schema'. Agreed. > Well, according to draft-ietf-netmod-revised-datastores-07: > > o 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. This text does not write that nodes with false when expressions are not considered part of the schema. > And "when" determines whether a given schema node is valid or not. So if a > schema node is invalid in the schema of but valid in the schema of > They are still part of the schema. Again, it is a matter of terminology - when we say that the "schema" of is a superset of the "schema" of the conventional datastores, we do not exclude false when expressions from the "schema". As per the defintion above we include the modules, their features and deviations in the term "schema". /martin >, then the former can hardly be a superset of the latter. > > Lada > > > > > /js > > > -- > 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 Mon Dec 4 14:10:51 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2AD12785F for ; Mon, 4 Dec 2017 14:10:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 IClB-mJKJRac for ; Mon, 4 Dec 2017 14:10:48 -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 3A71C126BF3 for ; Mon, 4 Dec 2017 14:10:48 -0800 (PST) From: Alex Campbell To: Ladislav Lhotka , Juergen Schoenwaelder CC: NETMOD WG Thread-Topic: [netmod] evaluation of "when" under NMDA Thread-Index: AQHTbRy3igyGlOvLkUCH4At/TPQkAqMz52iAgAAIyQCAAASzgIAADSaA//+7V0o= Date: Mon, 4 Dec 2017 22:10:46 +0000 Message-ID: <1512425445999.89017@Aviatnet.com> References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local>, <1512410991.8751.4.camel@nic.cz> In-Reply-To: <1512410991.8751.4.camel@nic.cz> 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2017 22:10:50 -0000 Hi,=0A= =0A= 'when' does not affect schema nodes, only data nodes.=0A= The schema nodes is essentially the YANG itself, without reference to any p= articular instance data.=0A= =0A= Given an example YANG fragment:=0A= =0A= list widgets {=0A= key name;=0A= leaf name {type string;}=0A= leaf can-frob {type boolean;}=0A= container frob-data {=0A= when "../frob-data =3D 'true'";=0A= leaf frob-count {type uint32; mandatory true;}=0A= }=0A= }=0A= =0A= The schema could be written like this: (not in any real language)=0A= =0A= widgets [list] [keys: name]=0A= - name [name]=0A= - can-frob [boolean]=0A= - frob-data [container] [when ../frob-data =3D 'true']=0A= - frob-count [uint32]=0A= =0A= The when statement does not make schema nodes "valid" or "invalid". It only= indicates the conditions under which the nodes will be present in the data= tree.=0A= =0A= A data tree for this schema might look like this: (in the same not-real-lan= guage)=0A= widgets=0A= - name: Widget1=0A= - can-frob: false=0A= widgets=0A= - name: Widget2=0A= - can-frob: true=0A= - frob-data:=0A= - frob-count: 5=0A= =0A= Widget1 doesn't have any frob-data because its can-frob is false, while Wid= get2 does because its can-frob is true.=0A= However that doesn't mean Widget1 and Widget2 have different schemas. They = are both instances of the same schema written above.=0A= =0A= ________________________________________=0A= From: netmod on behalf of Ladislav Lhotka =0A= Sent: Tuesday, 5 December 2017 7:09 a.m.=0A= To: Juergen Schoenwaelder=0A= Cc: NETMOD WG=0A= Subject: Re: [netmod] evaluation of "when" under NMDA=0A= =0A= On Mon, 2017-12-04 at 18:22 +0100, Juergen Schoenwaelder wrote:=0A= > On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote:=0A= > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote:=0A= > > > Ladislav Lhotka wrote:=0A= > > > > Hi,=0A= > > > >=0A= > > > > if we have=0A= > > > >=0A= > > > > augment "/target/node" {=0A= > > > > when "...";=0A= > > > > ...=0A= > > > > }=0A= > > > >=0A= > > > > is the "when" expression supposed to be evaluated separately in eac= h=0A= > > >=0A= > > > datastore,=0A= > > > > and the augment applied only in those datastores where the result i= s=0A= > > > > true?=0A= > > >=0A= > > > Yes.=0A= > >=0A= > > But then it cannot be guaranteed that the schema for is a= =0A= > > superset=0A= > > of the schema of configuration datastores - the when expression can eva= luate=0A= > > to=0A= > > false in but true in .=0A= > >=0A= >=0A= > For me, its still the same schema - a when expression does not change=0A= > my notion of 'schema'.=0A= =0A= Well, according to draft-ietf-netmod-revised-datastores-07:=0A= =0A= o datastore schema: The combined set of schema nodes for all modules=0A= supported by a particular datastore, taking into consideration any=0A= deviations and enabled features for that datastore.=0A= =0A= And "when" determines whether a given schema node is valid or not. So if a= =0A= schema node is invalid in the schema of but valid in the sche= ma of=0A= , then the former can hardly be a superset of the latter.=0A= =0A= Lada=0A= =0A= >=0A= > /js=0A= >=0A= --=0A= Ladislav Lhotka=0A= Head, CZ.NIC Labs=0A= PGP Key ID: 0xB8F92B08A9F76C67=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Tue Dec 5 01:03:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F6A127342 for ; Tue, 5 Dec 2017 01:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF87_5TfdU_A for ; Tue, 5 Dec 2017 01:03:10 -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 76EEC126C26 for ; Tue, 5 Dec 2017 01:03:10 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id D27316374D; Tue, 5 Dec 2017 10:03:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512464587; bh=c/cxblXv09VG6gxH/Y7zBZAif0jlSL+fdwK3R7ttrqA=; h=From:To:Date; b=EcpXWHMBrSXvbigkgzkJQI9sOY0RLLb613C1Pw5T90iTzYwd91RzavamXHvLooUIE 7Ymdh+2wQZCnCBrzTSPcbdDGOC8hf82cjRzWWtNMUYK/uB7wAi06sxC4L6XmZn0Rve ktnXq9e+brTXIKbp31R+6C0oYbasXVLBopcD2Iuc= Message-ID: <1512464587.7827.13.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder Cc: NETMOD WG Date: Tue, 05 Dec 2017 10:03:07 +0100 In-Reply-To: <20171204200019.2xvocmusfwfatqav@elstar.local> References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> <1512410991.8751.4.camel@nic.cz> <20171204200019.2xvocmusfwfatqav@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 09:03:13 -0000 On Mon, 2017-12-04 at 21:00 +0100, Juergen Schoenwaelder wrote: > On Mon, Dec 04, 2017 at 07:09:51PM +0100, Ladislav Lhotka wrote: > > > > Well, according to draft-ietf-netmod-revised-datastores-07: > > > > o 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. > > > > And "when" determines whether a given schema node is valid or > > not. So if a schema node is invalid in the schema of > > but valid in the schema of , then the former can hardly be > > a superset of the latter. > > I do not follow your notion of 'schema node is valid or not'. Where is > this concept defined? I think RFC 7950 talks about validation of data Guess what, this notion is used in the definition of "when" statement (sec. 7.21.5): The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. ... This text clearly talks about a schema node, because it is what data definition statements define. > trees against a "schema". Perhaps there are places where the wording > is not clear enough? I know that there are places where the RFC 7950 > text says just "node" without being explicit about the distinction > between schema node and corresponding data nodes. If this is an issue Note that data node is just a special type of schema node (sec. 3). > here, we may consider posting erratas to clear things up. Right, the text above could say "The schema node defined ..." but it can never say "an instance of a data node" because "when" can also be used for "choice", "case" and "augment", and then there is no conditional (parent) instance. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 5 01:45:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C331275FD for ; Tue, 5 Dec 2017 01:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, 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 nt-nSHEOoH05 for ; Tue, 5 Dec 2017 01:45:52 -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 604A1124205 for ; Tue, 5 Dec 2017 01:45:52 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id C3B2E63826; Tue, 5 Dec 2017 10:45:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512467149; bh=9bqUXL3g44Z2fwh6ndMfteq4oiihhMGCUeSur2ZB19c=; h=From:To:Date; b=Sb0pRvF8udZuVbOIbIPCEVARYsN/4qfTMGE0HzoA/rsBnHzS5rqmqrIZejaZba1Cs clWeAysnAxZ6ysCXXkBZaRsdv8De+/YryTOq6lHySrguYCTVpqWCaaG+2Kj+yN1YZE P1uQAnzjCQgWIdTcCh8mYSyQrhTEmfOCP0jWy2JI= Message-ID: <1512467149.7827.39.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , NETMOD WG Date: Tue, 05 Dec 2017 10:45:49 +0100 In-Reply-To: References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 09:45:56 -0000 On Mon, 2017-12-04 at 17:29 +0000, Robert Wilton wrote: > Hi Lada, > > > On 04/12/2017 17:05, Ladislav Lhotka wrote: > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > > > > Hi, > > > > > > > > if we have > > > > > > > > augment "/target/node" { > > > > when "..."; > > > > ... > > > > } > > > > > > > > is the "when" expression supposed to be evaluated separately in each > > > > > > datastore, > > > > and the augment applied only in those datastores where the result is > > > > true? > > > > > > Yes. > > > > But then it cannot be guaranteed that the schema for is a > > superset > > of the schema of configuration datastores - the when expression can evaluate > > to > > false in but true in . > > I think that comes down to terminology, RFC 7950 section 7.21.5 on when > statements just talks about making data definition statements > conditional. I don't really think that when statements (or choice > statements) change the schema associated with a datastore, they just > make parts of it inactive based on the current data. I.e. you wouldn't > expect different information to be returned via YANG library depending > on how particular when statements in the implemented modules get evaluated. > > Is seems to me that the when processing falls out quite naturally. Is > there a scenario where you think that this could cause a problem? IMO it comes down to the distinction between syntactic (schema) and semantic constraints. An important syntactic constraint for a container are the children that a container instance (i) must, and (ii) may contain. Whenever "when" comes into play, this cannot be determined upfront, we first have to see a particular (complete) data tree and evaluate an XPath expression on it. It may seem that this is an academic issue and that the borderline between syntactic and semantic constraints is arbitrary, but it isn't: it is determined by the need for having a robust and efficient algorithm for syntactic analysis. Such an algorithm exists for regular and context-free grammars, as well as for XSD and RELAX NG, but not for YANG. As for problems caused by "when", it is by far the trickiest part in YANG and most complicated implementation-wise. Lada > > Thanks, > Rob > > > > > Lada > > > > > > RFC 7950 says in sec. 7.21.5 that the context node for XPath evaluation > > > > is > > > > > > "the > > > > augment's target node in the data tree", but with NMDA we have multiple > > > > data > > > > trees, hence multiple target nodes. > > > > > > We had multiple datastores even before NMDA. The when expression > > > could be true in candidate but false in running. > > > > > > /martin > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 5 02:05:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381461286D6 for ; Tue, 5 Dec 2017 02:05:01 -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, 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 6DiLiCoYf2nW for ; Tue, 5 Dec 2017 02:04:58 -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 3A5271286B1 for ; Tue, 5 Dec 2017 02:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9835; q=dns/txt; s=iport; t=1512468298; x=1513677898; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=V23JDAl9HPPy/8n7JbPSB3xKIvl2G504BWU5alPiXws=; b=CoJYsxLTpa53NWMDvdodbIg8j+n9/PPkYMcupAB5uIPa6edVGH/osoEM T30PbMJc2yfVzJ70YF6ieHqebNjwkilUcP8jeglRUFNul2/M5pQfA/Wj1 cb0UMoGnFpZXS9Xy/XZDyfLd6ohtkgrYcBXdEjvBbZE4TKz628mzhSR0L Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAQD/biZa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQjbieEAIsUj1QvfpA4h2AKGAEKhElPAoV/FAEBAQEBAQEBAWs?= =?us-ascii?q?ohSIBAQEBAgEBASFLCwULCxgnAwICJx8RBgEMBgIBAYoXCBCpRoInJoo8AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDSINggWkpgkw2hQuDK4JjBZk8iTqVE4wLh0y?= =?us-ascii?q?OVId8gTo2IoFNMhoIGxU6gimCGYI8QTeKIgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,363,1508803200"; d="scan'208,217";a="648598" 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; 05 Dec 2017 10:04:56 +0000 Received: from [10.63.23.85] (dhcp-ensft1-uk-vla370-10-63-23-85.cisco.com [10.63.23.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB5A4tlX018552; Tue, 5 Dec 2017 10:04:55 GMT To: Andy Bierman , Ladislav Lhotka Cc: NETMOD WG References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> From: Robert Wilton Message-ID: <409e9bb5-fcbe-d94f-a7cb-cb7961d9fdb2@cisco.com> Date: Tue, 5 Dec 2017 10:04:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E95BC6E73067132C2D39A1B6" Content-Language: en-US Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 10:05:01 -0000 This is a multi-part message in MIME format. --------------E95BC6E73067132C2D39A1B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 04/12/2017 17:47, Andy Bierman wrote: > > > On Mon, Dec 4, 2017 at 9:05 AM, Ladislav Lhotka > wrote: > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: > > Ladislav Lhotka > wrote: > > > Hi, > > > > > > if we have > > > > > > augment "/target/node" { > > >   when "..."; > > >   ... > > > } > > > > > > is the "when" expression supposed to be evaluated separately > in each > > > > datastore, > > > and the augment applied only in those datastores where the > result is true? > > > > Yes. > > But then it cannot be guaranteed that the schema for > is a superset > of the schema of configuration datastores - the when expression > can evaluate to > false in but true in . > > > > I see your point now. > The server has to evaluate the when-stmts in operational. I think that this is probably down to implementation, but I don't think that this is necessarily required.  A server is meant to conform to 'when' statements in (e.g. if the system is in a normal steady state), but they are allowed to be violated, and I'm not expecting that a server would evaluate them (except perhaps to discover implementation bugs).  Further, if violations of when statements in are detected then I don't think that there is anything that the server can reasonable do. > Even though the schema trees are the same, the client has a complex > task comparing > to . I don't get why this isn't just a simple diff between the and data trees.  What is causing the complexity? Thanks, Rob > However it is no different than the existing > complexity comparing to . > > Lada > > > Andy > > > > > > RFC 7950 says in sec. 7.21.5 that the context node for XPath > evaluation is > > > > "the > > > augment's target node in the data tree", but with NMDA we have > multiple data > > > trees, hence multiple target nodes. > > > > We had multiple datastores even before NMDA.  The when expression > > could be true in candidate but false in running. > > > > /martin > -- > 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 --------------E95BC6E73067132C2D39A1B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 04/12/2017 17:47, Andy Bierman wrote:


On Mon, Dec 4, 2017 at 9:05 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Hi,
> >
> > if we have
> >
> > augment "/target/node" {
> >   when "...";
> >   ...
> > }
> >
> > is the "when" expression supposed to be evaluated separately in each
>
> datastore,
> > and the augment applied only in those datastores where the result is true?
>
> Yes.

But then it cannot be guaranteed that the schema for <operational> is a superset
of the schema of configuration datastores - the when expression can evaluate to
false in <operational> but true in <intended>.



I see your point now.
The server has to evaluate the when-stmts in operational.

I think that this is probably down to implementation, but I don't think that this is necessarily required.  A server is meant to conform to 'when' statements in <operational> (e.g. if the system is in a normal steady state), but they are allowed to be violated, and I'm not expecting that a server would evaluate them (except perhaps to discover implementation bugs).  Further, if violations of when statements in <operational> are detected then I don't think that there is anything that the server can reasonable do.
 

Even though the schema trees are the same, the client has a complex task comparing
<intended> to <operational>.

I don't get why this isn't just a simple diff between the <intended> and <operational> data trees.  What is causing the complexity?

Thanks,
Rob


However it is no different than the existing
complexity comparing <candidate> to <running>.

 
Lada


Andy
 
>
> > RFC 7950 says in sec. 7.21.5 that the context node for XPath evaluation is
>
> "the
> > augment's target node in the data tree", but with NMDA we have multiple data
> > trees, hence multiple target nodes.
>
> We had multiple datastores even before NMDA.  The when expression
> could be true in candidate but false in running.
>
> /martin
--
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

--------------E95BC6E73067132C2D39A1B6-- From nobody Tue Dec 5 02:27:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2343128E19 for ; Tue, 5 Dec 2017 02:27:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 IKMLQiji-NLH for ; Tue, 5 Dec 2017 02:27:30 -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 0608C127058 for ; Tue, 5 Dec 2017 02:27:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CC768677; Tue, 5 Dec 2017 11:27: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 mk5DVgd_i60C; Tue, 5 Dec 2017 11:27:25 +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, 5 Dec 2017 11:27:25 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B873F20128; Tue, 5 Dec 2017 11:27:25 +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 aiNV9vp9wPOJ; Tue, 5 Dec 2017 11:27:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20F2B20126; Tue, 5 Dec 2017 11:27:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 163CC418C542; Tue, 5 Dec 2017 11:25:54 +0100 (CET) Date: Tue, 5 Dec 2017 11:25:54 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: NETMOD WG Message-ID: <20171205102554.ggiyqj6fx2bhcrvo@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> <1512410991.8751.4.camel@nic.cz> <20171204200019.2xvocmusfwfatqav@elstar.local> <1512464587.7827.13.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512464587.7827.13.camel@nic.cz> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 10:27:32 -0000 On Tue, Dec 05, 2017 at 10:03:07AM +0100, Ladislav Lhotka wrote: > On Mon, 2017-12-04 at 21:00 +0100, Juergen Schoenwaelder wrote: > > On Mon, Dec 04, 2017 at 07:09:51PM +0100, Ladislav Lhotka wrote: > > > > > > Well, according to draft-ietf-netmod-revised-datastores-07: > > > > > > o 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. > > > > > > And "when" determines whether a given schema node is valid or > > > not. So if a schema node is invalid in the schema of > > > but valid in the schema of , then the former can hardly be > > > a superset of the latter. > > > > I do not follow your notion of 'schema node is valid or not'. Where is > > this concept defined? I think RFC 7950 talks about validation of data > > Guess what, this notion is used in the definition of "when" statement (sec. > 7.21.5): > > The "when" statement makes its parent data definition statement > conditional. The node defined by the parent data definition > statement is only valid when the condition specified by the "when" > statement is satisfied. ... > > This text clearly talks about a schema node, because it is what data definition > statements define. This is not how I understand the text. Perhaps a clearer phrasing would have been this: The "when" statement makes its parent data definition statement conditional. A node in the data tree corresponding to the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. ... For me, the schema is static, the schema does not change with the content of the data tree. YANG specifies what a valid data tree is, I do not thnk it defines schemas that mutate according to some notion of schema validity. > > trees against a "schema". Perhaps there are places where the wording > > is not clear enough? I know that there are places where the RFC 7950 > > text says just "node" without being explicit about the distinction > > between schema node and corresponding data nodes. If this is an issue > > Note that data node is just a special type of schema node (sec. 3). Oops, yes I meant 'node in the data tree' or 'data node instance' or 'data tree node' (it seems we have no term for this and data node is indeed used for a different purpose). > > here, we may consider posting erratas to clear things up. > > Right, the text above could say "The schema node defined ..." but it can never > say "an instance of a data node" because "when" can also be used for "choice", > "case" and "augment", and then there is no conditional (parent) instance. The first thing is to settle on what the intention of the YANG specification was and then we can discuss how to fix any wording ambiguities. It seems we do not even agree on the intention so far. /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 Dec 5 04:04:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982CE127286 for ; Tue, 5 Dec 2017 04:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKmhrhz6hiHr for ; Tue, 5 Dec 2017 04:04:10 -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 B7F591243F3 for ; Tue, 5 Dec 2017 04:04:09 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 3A27C63BD5; Tue, 5 Dec 2017 13:04:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512475448; bh=Z0s7Wb8Jzjc3V5fbenmri7kOcJH1oTS+RTOnp0UbOJo=; h=From:To:Date; b=kUnRE67m7YPURzUQeyDU5xxGMlPJuBPZ42tQnl4jv7ld0hzPOFq3eIPKLlLtqonPv 21Tumofg0uHLrnpSbyJr7jWkXbWh5iE4yAkUk6opDWT3srmwK4xVzFTrCkCC2zdo4f siyReYj49DvG5YLFWp58JzOqBEoewmi6A/OhBRKw= Message-ID: <1512475448.7827.75.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder Cc: NETMOD WG Date: Tue, 05 Dec 2017 13:04:08 +0100 In-Reply-To: <20171205102554.ggiyqj6fx2bhcrvo@elstar.local> References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> <1512410991.8751.4.camel@nic.cz> <20171204200019.2xvocmusfwfatqav@elstar.local> <1512464587.7827.13.camel@nic.cz> <20171205102554.ggiyqj6fx2bhcrvo@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 12:04:12 -0000 On Tue, 2017-12-05 at 11:25 +0100, Juergen Schoenwaelder wrote: > On Tue, Dec 05, 2017 at 10:03:07AM +0100, Ladislav Lhotka wrote: > > On Mon, 2017-12-04 at 21:00 +0100, Juergen Schoenwaelder wrote: > > > On Mon, Dec 04, 2017 at 07:09:51PM +0100, Ladislav Lhotka wrote: > > > > > > > > Well, according to draft-ietf-netmod-revised-datastores-07: > > > > > > > > o 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. > > > > > > > > And "when" determines whether a given schema node is valid or > > > > not. So if a schema node is invalid in the schema of > > > > but valid in the schema of , then the former can hardly be > > > > a superset of the latter. > > > > > > I do not follow your notion of 'schema node is valid or not'. Where is > > > this concept defined? I think RFC 7950 talks about validation of data > > > > Guess what, this notion is used in the definition of "when" statement (sec. > > 7.21.5): > > > > The "when" statement makes its parent data definition statement > > conditional. The node defined by the parent data definition > > statement is only valid when the condition specified by the "when" > > statement is satisfied. ... > > > > This text clearly talks about a schema node, because it is what data > > definition > > statements define. > > This is not how I understand the text. Perhaps a clearer phrasing > would have been this: > > The "when" statement makes its parent data definition statement > conditional. A node in the data tree corresponding to the parent > data definition statement is only valid when the condition > specified by the "when" statement is satisfied. ... As I wrote, this doesn't work if the parent statement is "augment", "choice" or "case" - there is then no such node in the data tree. > > For me, the schema is static, the schema does not change with the > content of the data tree. YANG specifies what a valid data tree is, I > do not thnk it defines schemas that mutate according to some notion of > schema validity. > > > > trees against a "schema". Perhaps there are places where the wording > > > is not clear enough? I know that there are places where the RFC 7950 > > > text says just "node" without being explicit about the distinction > > > between schema node and corresponding data nodes. If this is an issue > > > > Note that data node is just a special type of schema node (sec. 3). > > Oops, yes I meant 'node in the data tree' or 'data node instance' or > 'data tree node' (it seems we have no term for this and data node is > indeed used for a different purpose). > > > > here, we may consider posting erratas to clear things up. > > > > Right, the text above could say "The schema node defined ..." but it can > > never > > say "an instance of a data node" because "when" can also be used for > > "choice", > > "case" and "augment", and then there is no conditional (parent) instance. > > The first thing is to settle on what the intention of the YANG > specification was and then we can discuss how to fix any wording > ambiguities. It seems we do not even agree on the intention so far. What really matters is that "when" is a part of the constraints that have to be satisfied in all data trees (per sec. 8.1). This is why DSDL schemas (RFC 6110) never worked exactly according to RFC 6020 (let alone 7950): in RELAX NG there is no possibility to evaluate XPath expressions, this has to be done in Schematron. Moving "when" to semantic constraints (required only for a valid tree) would IMO remove a lot of complexity at very little cost. For NMDA in particular it would mean that "when" is only enforced in . Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 5 04:07:36 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CE4129449; Tue, 5 Dec 2017 04:07:35 -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 6OBRv-96R0ig; Tue, 5 Dec 2017 04:07:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 04DCC129442; Tue, 5 Dec 2017 04:07:33 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 126D11AE0144; Tue, 5 Dec 2017 13:07:33 +0100 (CET) Date: Tue, 05 Dec 2017 13:06:13 +0100 (CET) Message-Id: <20171205.130613.1426678366033684761.mbj@tail-f.com> To: netmod@ietf.org, draft-rtgyangdt-netmod-module-tags@ietf.org From: Martin Bjorklund 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: [netmod] draft-rtgyangdt-netmod-module-tags X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 12:07:35 -0000 Hi, What is the plan for draft-rtgyangdt-netmod-module-tags? I think it is important and would like to see it as a WG document. /martin From nobody Tue Dec 5 05:18:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FCB129476 for ; Tue, 5 Dec 2017 05:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 VpAetr3c2hmJ for ; Tue, 5 Dec 2017 05:18:30 -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 0E4A5129465 for ; Tue, 5 Dec 2017 05:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4751; q=dns/txt; s=iport; t=1512479910; x=1513689510; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=e1W49j3e5zasoW4uDDoRs6U7NsXCYEIeifJZAr090/s=; b=nBlGPneQ/vZURaJyFlqTVgTgJUgjZ9C8d0K8uHQLPRP5mxW/PwnyTAin ZYiRfX+1cxUHlxMO1zysNprmqqyFZhGWiLAtUBIVA1gZxdzVVTRD8xPb3 odwv4jRvKOem/zOIJU5epIjWU1buWQjrVbBFCMRPZTMRnjbRZeUirPeBk A=; X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208";a="659910" 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; 05 Dec 2017 13:18:28 +0000 Received: from [10.61.175.124] ([10.61.175.124]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB5DISJv014793; Tue, 5 Dec 2017 13:18:28 GMT To: "Acee Lindem (acee)" , Vladimir Vassilev , "netmod@ietf.org" References: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com> From: Benoit Claise Message-ID: Date: Tue, 5 Dec 2017 14:18:27 +0100 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] review of draft-acee-netmod-rfc8022bis-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: Tue, 05 Dec 2017 13:18:33 -0000 On 11/3/2017 5:49 PM, Acee Lindem (acee) wrote: > Hi Vladimir, > > Thanks for comments - see inline. > > On 10/29/17, 8:43 PM, "netmod on behalf of Vladimir Vassilev" > wrote: > >> Hello, >> >> I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that >> the YANG modules part of the draft have been successfully modified in >> accordance with sec. '4.23.3 NMDA Transition Guidelines' of >> draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the >> ietf-interfaces@2017-08-17.yang module in >> draft-ietf-netmod-rfc7277bis-00 and ietf-ip@2017-08-21.yang module in >> draft-ietf-netmod-rfc7277bis-00. >> >> Vladimir >> >> >> Review of draft-acee-netmod-rfc8022bis-05. >> Vladimir Vassilev >> 2017-10-30 >> >> 'Abstract': >> 'Introduction 1': >> - Both Abstract and Sec 1. contain duplicated text which can be removed > >from Abstract. The text in Sec 1. can be simplified: >> OLD: >> This version of these YANG modules uses new names for these YANG >> models. The main difference from the first version is that this >> version fully conforms to the Network Management Datastore >> Architecture (NMDA). Consequently, this document obsoletes RFC 8022. >> NEW: >> This version of the Routing Management data model supports the Network >> Management Datastore Architecture (NMDA) >> [I-D.ietf-netmod-revised-datastores]. > The Abstract and Introduction sections are independent and the information > is pertinent to both. Acee, The point (as reported by someone else to me) is that this sentence is not correct and should be removed. This version of these YANG modules uses new names for these YANG models. Regards, Benoit > >> >> '7. Routing Management YANG Module': >> >> - Why should address-family identity be different e.g. mandatory >> "false"; for system created RIBs? I think this needs some explanation >> (Page 21): >> ... >> uses address-family { >> description >> "Address family of the RIB. >> >> It is mandatory for user-controlled RIBs. For >> system-controlled RIBs it can be omitted; otherwise, it >> must match the address family of the corresponding state >> entry."; >> refine "address-family" { >> mandatory "false"; >> } >> } >> ... > I will discuss this with my co-authors. >> - Suggested change of 'base address-family;' -> 'base >> rt:address-family;' for identity ipv4 and ipv6 (ref. >> draft-ietf-netmod-rfc6087bis-14#section-4.2): >> >> o The local module prefix MUST be used instead of no prefix in >> all "default" statements for an "identityref" or >> "instance-identifier" >> data type > I added “rt:” where it was missing to the identityref statements. This > will be in the next revision. >> '8. IPv4 Unicast Routing Management YANG Module' >> (ietf-ipv4-unicast-routing@2017-10-14.yang): >> '9. IPv6 Unicast Routing Management YANG Module' >> (ietf-ipv6-unicast-routing@2017-10-14.yang): >> >> >> - The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules >> import the ietf-routing without revision (ref. rfc6087#section-4.6): >> >> >> o The revision-date substatement within the imports statement SHOULD >> be >> present if any groupings are used from the external module." > Since these modules are all in the same draft, I’d rather leave out the > revision date as it is cleaner without it. Let me discuss with my > co-authors. >> >> 'Appendix D. Data Tree Example': >> >> - The example in the Appendix D. has not been updated and it must be >> extended in order to demonstrate a usecase of operational datastore of >> configuration data with different origin (intended, system, etc.) >> similar to the 'Appendix C. Example Data' of >> draft-ietf-netmod-revised-datastores-05. > Actually, none of the examples accessed operational state date in RFC > 8022. However, I agree that this should be added and we’ll work on it. >> >> Nits: >> - s/Figures 1/Figure 1/ >> - s/systemindependently/system independently/ > Thanks for catching - I fixed these in the -01 version of > draft-ietf-netmod-rfc8022bis-01.txt. > > Thanks, > Acee >> _______________________________________________ >> 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 Dec 5 06:35:38 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998DB124F57 for ; Tue, 5 Dec 2017 06:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, 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 75U4SO_aUzg7 for ; Tue, 5 Dec 2017 06:35:32 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F261294E7 for ; Tue, 5 Dec 2017 06:35:32 -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=wCxsR8aycApL49oHOJmueYrV8kA0ZYLGz+XgGggjGmk=; b=IlBJPZASMHd76Z9U8MyQd9bv+I1L4LqAKhI674rUshPz0iscMUzhveuWsGZ6I8lFglQ24MI6SSlmhYYKD0OLY2jOrr3OTa1mIw/m08ZlMBxCqTQfpCgGzE/lk+dhtEF90hm40Zub/QH/htPSxUppSESgSQbXay+26x/0xwdafB8= Received: from VI1PR07MB3069.eurprd07.prod.outlook.com (10.175.242.143) by VI1PR07MB3072.eurprd07.prod.outlook.com (10.175.242.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Tue, 5 Dec 2017 14:35:30 +0000 Received: from VI1PR07MB3069.eurprd07.prod.outlook.com ([fe80::288c:aecd:ef7f:2627]) by VI1PR07MB3069.eurprd07.prod.outlook.com ([fe80::288c:aecd:ef7f:2627%13]) with mapi id 15.20.0282.012; Tue, 5 Dec 2017 14:35:30 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: NetMod WG Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-entity-05 Thread-Index: AQHTaTiKqKmzwOAcZUCbDVKBDx0N2aM01axQ Date: Tue, 5 Dec 2017 14:35:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.245.212.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3072; 6:99pnAeiOutlNuN14atI72Wh4hfNBDF8Y9wZJYF2S7LdBAYPw3DswRs4i2ddszBO+i2fMehnhF4ZUMztmV6jBtWgsVxbAMoXPDyLD+zpiiKHRPHcIZoWq404f6eOBpcLwI+VsY1IHkuPIt7V0vASTU7JEGdBQFEBJ28xMRnRHT5PFMsF8o/b+E5TrEqGzUo9Y6EcvgqMwp5zRdhRcNeHl6peHlyh+evGX/xkgd+s8OK1eO5rrZAf84biOE1fnp0E/IyDDtT5YVtu9grmQTSTy1zugGgW4OqTeyZdkDAU+0K1Ub5hEoywCkgXnCRv70NqtnsXkyHZH4i55VqF+rIud/a98Vbh6QfjZuVX/8NClkiI=; 5:weY3MMFBFZiMkODEyCQ/e1aTnqS2I0K2tfIcJ3mBRT9VZXIRae0dYsUfolbDTi4ObiLx8uiqbWoxGaXk2wbvxaKxFksW2oYk1l/ahu5n2FS5lSI6Zm2qAJCXEvDIrHjlqsCa7GcUlykEr9Hhb1GTdeyh3olc7OBH6XLtM4cn/0I=; 24:vGpqb/t+JRev91ikDn8eENIW1mPlmG3TJEB5i8J8sNjY3TKpNvejmeGN1JBaNZa5X0DgjFynslxSa5rVUkCfC2BNEzIj5xHzKy4XqAUaAdg=; 7:SfNqY+Q+lfZJUzt4TqJscMa7l8I0l+g73JgoH6OBKrLuRbe1eOzlX3cSFWrkjDxEw4SmlHpbQB9dk2eqsZsi++yUqaKXWU5v3lQgBIq0eTc4xs539ToUxt2Q7vmc9hhF97GxT0dL8ylVEwBLHpCxDt1PnFqy2wdn1BjcGgLpKzq6qLFz+3GELiI3jTfBX5cUITYd7uAN36AkSTXRy1Th8fgmdiE6UktojvO7Z3TVU3nA82Q6YB1FMgZ7mbUrR25i x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 036b7833-21e0-4d0a-4b52-08d53bed6f1d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286)(49563074); SRVR:VI1PR07MB3072; x-ms-traffictypediagnostic: VI1PR07MB3072: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011); SRVR:VI1PR07MB3072; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3072; x-forefront-prvs: 0512CC5201 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(366004)(39860400002)(189002)(13464003)(199003)(74316002)(105586002)(305945005)(7696005)(7736002)(53546010)(189998001)(5250100002)(2900100001)(54356011)(76176011)(478600001)(68736007)(81166006)(966005)(5660300001)(97736004)(2950100002)(81156014)(8676002)(6916009)(3660700001)(86362001)(106356001)(66066001)(53936002)(6116002)(6506006)(2906002)(102836003)(6436002)(6246003)(3846002)(99936001)(25786009)(8936002)(3280700002)(101416001)(99286004)(229853002)(14454004)(316002)(6306002)(33656002)(55016002)(230783001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3072; H:VI1PR07MB3069.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01D36DDE.AD194C80" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 036b7833-21e0-4d0a-4b52-08d53bed6f1d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 14:35:29.9021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3072 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-entity-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: Tue, 05 Dec 2017 14:35:36 -0000 ------=_NextPart_000_005F_01D36DDE.AD194C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, The latest draft does not contain an appendix with the deprecated state tree (to support the non-NMDA model as specified in RFC6087bis section 4.23.3), so if it is published in this way, there is an issue at the level of BBF TR-383. Note that the draft-ietfnetmod-rfc7223bis does include the deprecated container interfaces-state. Best regards, Bart Bogaert -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, November 29, 2017 6:36 PM To: NetMod WG Cc: NetMod WG Chairs Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05 All, This starts a two-week working group last call on draft-ietf-netmod-entity-05. The working group last call ends on December 13. 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. Thank you, Netmod Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_005F_01D36DDE.AD194C80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEyMDUxNDM1MjdaMCMGCSqGSIb3DQEJBDEWBBTt7I2J 4oRoJXX2DJUAcvxtcUCl1jCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAFSiPE/IEUlzQyV9ml4XtqxUrfgTryxWK/6WIgpr8ivjFfL5gVcoJotIpKhz 7r0CaZKY78f+d4zgnfeyhqX1X+5CMe/Q0BEGRaaLbUZinBevNBr87qdeJ2AoVRfnlwn4URDQAjxl 8dXTlFxSp6Lc5CnwFT3UNDG6Z54cVLj/aHuFUzwN8z1/r8Z9DwZuJ8Ero2r82bzUGA44maGcGeav P9XBgMeVjGGh5hojitPBL0q+OebM/8K/qDm8uJqtHFQu/y+Bx8VNpN4fF0w+KOP1sIctdBur3j2x 5syc3Z0gMuFgRgDAtHDAzydNPA45oTOOD5pWhUOFsTV4+YT7sa3SHhYAAAAAAAA= ------=_NextPart_000_005F_01D36DDE.AD194C80-- From nobody Tue Dec 5 06:37:51 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135821294EC for ; Tue, 5 Dec 2017 06:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 yeFhcgeo8K-z for ; Tue, 5 Dec 2017 06:37:46 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A969127076 for ; Tue, 5 Dec 2017 06:37:45 -0800 (PST) X-AuditID: c1b4fb2d-d57ff700000036aa-49-5a26af38565c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5E.A6.13994.83FA62A5; Tue, 5 Dec 2017 15:37:44 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 5 Dec 2017 15:37:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p/UVbfTBPIKc9eYjLgt4WV1FjFM7ajjkUbP5H0udl0k=; b=mYI6L4ldSVQ+FFCizh789fX3XHb6j08kVgwzWDnlDmzieAqbryvGvx5IAyQYtk6EDqvzw3/Vv5h+uC+CFaZs1pbdbeRgNYyqI5L+WFAk058kfKZdhDmKLi969mTL/6HLujjMatUGYFCE0yHYxhgHVBAN+39ecIqT7yWH5f9q9JU= Received: from [159.107.197.124] (91.82.100.59) by AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Tue, 5 Dec 2017 14:37:42 +0000 To: Robert Wilton , Andy Bierman , Ladislav Lhotka CC: NETMOD WG References: <1512404811.1422.63.camel@nic.cz> <20171204.173431.1294203680272812703.mbj@tail-f.com> <1512407158.6635.8.camel@nic.cz> <409e9bb5-fcbe-d94f-a7cb-cb7961d9fdb2@cisco.com> From: Balazs Lengyel Message-ID: Date: Tue, 5 Dec 2017 15:37:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <409e9bb5-fcbe-d94f-a7cb-cb7961d9fdb2@cisco.com> Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1P191CA0009.EURP191.PROD.OUTLOOK.COM (2603:10a6:3:cf::19) To AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13) X-MS-Office365-Filtering-Correlation-Id: ee72b4e7-76e5-4867-e63b-08d53bedbe47 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:AM4PR07MB3428; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 3:uwOxmM5BsuTkJvlsQBZCGpv+/euRMavnAC+bxqm3MPweMGz2vNsSdOgzpPTn80lBd74PhH2szrt6KWhnUR19nlv1VRQXVqu12Mx5/a8ekA4Z9BYk6Z0PD0dyqeW62rq4qv4K9tfpWzNZ1WIAzVYtO0STAZWThO+KkazRNS7BvkN85HJc+15g0zkIHs71dT1GN5rOp+baV/CglbKw8X17m+ABsL5IwW8OaZUaYdEto5ZQWUd4RxLUicJ3i7EXjIya; 25:ERYroukop4MADriU+jN7SvADCasE9T/6Kppuu7uXj7OrG6omqBLIIjvxLoCUEv55WeOf6SsmPXKJW8XN71O+S5nmOuuMFjikfzOznjgc/EZMEk7sbFbT61V3PBIY6zZUZxfn6x5+L7LinG6YfBywWD0cg0bP3AMCdTX4RgHkKJLwpn+UcDX2xLKJ0ejH+98YEZe5bLEt1Rx1X+NDBOlxcRcZO8jpcdrC3D+wB/3s62z6b74xxII6qhUroM7IZ/HFrBPYiMm7+hiefG14LAIr5iyF90Ml0tI+IiINvTL3alXqQaD3c7BUyQyY1hpu7RJe2UCgm7HD5gKEasqdzKIUpQ==; 31:D/SkCEVZ0jj06rG7RMR+OeJi+BL3MeLO5/WCAo5oYV2SFnqmBtyd6JeM3tQVwuzQOHqeeseW6t4Ujb8bDF6jZrom8NZVpgHOJ80/mkq/fwV1T7wlh18d+WpnYE857bnFHgZmbfsHCowQTUCjZflB4HXQU+dzcr/A9CBkUskoK3tIA9tleCxdPh1mYSG4dgvvK6s1NwbCXGPE52nsqRcMsCZ9pBA6wDgvQ0NBInLEttY= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM4PR07MB3428: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 20:nJkbiOymBxA7OUvyN/3w6CxC8IqHnV+9UFTM/Lm/KBFfxRQJsnQMHwxkgatFcaygMQnCZkmvHwvGySQwqnN8NRlUMKNxrhgc74uhRfa8d+GgI6913mq+CLJSEc4nMlFfOUOWycKQBFMlDjG0tF6QBQ7PQEq4FI1J/fArd90OWhm+uQ37vgsjfGKBBOkA3fBXbVQEBspX+pOGuvg6ClRbLTid2LaJxSn8Gm31DKfWdA/zbpKPPmtG2OToZsZy6V9dvBK9LJfUb8FOm7ocMZNXc9Ex1ZJBGFHhZOFl12gtIfZqNTYpAfrQfBm3BOnPoJs1ysPRECJZjkZ64b/wPw29Dh2NtlD7zeayd6/Ej8snUkaJbgKvgyXWDhHufqJhyB1wxNmG+Aa9g9gBgOkqx+t+Cb2UVpAu5/FiVFRkbF34XzFVqH2Zn11uRdqpRNJfI3gt00LJM37f9oU8bqHzlE4vv1Pgoqf4oeki70yzvdVmz+iZwB0iaVWju1TuTVsp2eyG; 4:yrmre8RmK+ZD3ywVTXjHQegVIpGMav4Hb538lt8+ypDL/NvyYkeRcM+Ji3ix/auvH/oOvoyqgXbDMxx9ZbAn/+uYMJaOHcjbD1Umy7bOtgkgTmQHk6+EuLitLNwprWFPWmK9gc4kR65RK8dRqtmkPOCWvANC1EZMGQBm+ayU6T4pT0VTfsgV42GlHzJDjXcjM2innmlU197tuszqgRgqiDAnHVLT+Qvz0b3QGcpXtFHUoWt86RCCXDt2IL5tW0BS5E1Fzm0Cdhwc9lFUGSG8O0g0uZaULESTLhhImHgZ4ehYmE7wNo2AyeNZxAh8kWUF/yMW9Bfa5UCR7iDZIZMgpd42Jsbs9LHqIatBORCARtI7HA5KruqARs1jXXOahI30 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:AM4PR07MB3428; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3428; X-Forefront-PRVS: 0512CC5201 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(376002)(346002)(39860400002)(189002)(252514010)(24454002)(51444003)(377424004)(199003)(110136005)(93886005)(7736002)(53546010)(58126008)(316002)(16576012)(68736007)(2950100002)(6666003)(5660300001)(65826007)(86362001)(81156014)(81166006)(36756003)(31696002)(25786009)(8676002)(65956001)(66066001)(65806001)(16526018)(478600001)(97736004)(49976008)(64126003)(229853002)(4326008)(54896002)(236005)(105586002)(2870700001)(23846002)(83506002)(189998001)(31686004)(52116002)(101416001)(3846002)(6116002)(6486002)(33646002)(76176011)(54356011)(23676004)(2486003)(106356001)(6246003)(8936002)(53936002)(52146003)(50466002)(2906002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3428; H:[159.107.197.124]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI4OzIzOld4RUJ3bmJoc3lOTkh6S0NVQzFqdndYQVdS?= =?utf-8?B?R1pQS1ZRQUhkQ3A4MUpyTUZTc24rV3N1U2l2MFZGdXIwai9aaHNkRy9sVkJH?= =?utf-8?B?WlZLRndIMUoveEx5M2VIOXdSYVhQTTh5eDJjS3dDSFJrWFZ1OVAyemJScGhH?= =?utf-8?B?VzR6K1FuQ0x1blB1akVSejJNaWFoeEV3TzEzSDZ4MnJXU2F0eks3VTEwaG1v?= =?utf-8?B?N0FLSlUzbmw5YldydDlKMURzN3Zha3ZGbUZTRjRUWXhSR1M3bk9ESDMybHhq?= =?utf-8?B?UW9PVEV0a1NibUFRYlRjcVc2SGE0bm5FYVRkQkJPUmwycXQ0VHVydC9JNzUz?= =?utf-8?B?eGRQbmU0MGxOK3dpZ0J4QVZQVWdKV0tjRDFwbzhZc2xWbVVoKzQrTDFwUkRE?= =?utf-8?B?Zi83SHZMaXJrc05Ha1NvVHJ0NkZ2YjlPSjRHMmdiaEV5YVdubGdNVklVTXlD?= =?utf-8?B?WXlnVEtYK2llOTloZHpQU1E2SzBSYnFRZ3RYWlJDbHgrU3d2MFZCRy8zRERi?= =?utf-8?B?WWttSFNtOEJ4b2pZVzlybjJzQjhyZHNQc1loaTB1NERrVG9ndlJwNlNGdnRQ?= =?utf-8?B?Vyt6SEsycm5BTDhOUzNDTExtajFOMDRiRmRXTURQeE1KSzBsVzBObFpmT0dv?= =?utf-8?B?UHhtbjJzNmxwT2NZbUpBZDEwN1pNeExoNFplNEJ3K0d4aG9Kcnc2ZjdPcXQy?= =?utf-8?B?M2Y1ayswS3RkYmZoWFdBZ2xPVEFXTklkNG1vK1VsK2RBaDNNWWtqU0dsMFRT?= =?utf-8?B?dU5xTXU1QmtBNHl2SnpWOUVqTjdNQ21jWWRGU1RmNmsxc1RPb2I4QWtCVGEr?= =?utf-8?B?WFp5SHViQ2NtTmhIWHNWRDhBU0kwL0paM1BRN0d5bGFPY3FGYXI5YXFrRU0x?= =?utf-8?B?eFBuVDdqVHNmZk5CUXpNekl6NlRyWmdRcWRLR0FpSVZ2aXhzNDZtZUVvY0kv?= =?utf-8?B?amdnTW96SkQyQlhuODcvNU1VMlU3K01tWERTcEpIV29KREtQd3FZcWVxNFd2?= =?utf-8?B?WExSSklQQTh2bTRkR1ZMTHNtVGxqdStEUGxVK29IcVR3eDM5NDlrM3l6bWNs?= =?utf-8?B?dTMya3hYaCs0Qi9JZThUOWFVRmU3NDkwWm5NeVVLcjFJY1ZXeERDcHFjUGJr?= =?utf-8?B?M205OHNubldLRVZKVFhkOUh1ek44ckF0WDh6R01qTU1ld2VkSW5RWXB5NTE2?= =?utf-8?B?aUxKOC9jNTRuTis2cHcrNTMzR25ENFNSMnZ5a2o0OVdlTGtEZENrcU5kYXpa?= =?utf-8?B?bzhWS3VBMXR5OFI4NHd6MkVxNjk5RHBGRjl4VE1HQ3RzM2daMUZIak9BajVD?= =?utf-8?B?dkhvQ1FFUW5FMDN3bnNtSnVqUmU4TFU5Z1RSMk5PWGg1NC9KeEduVHJRL2wv?= =?utf-8?B?b1FlcVl0Z25WQmE0YzJ4aGVxcjlXelVVNGZPcVA4R2J2RDA0dVIrNElrMkJD?= =?utf-8?B?blVDakFjVFF3UzJYTEMxVE9OcEQzMzJVZVJNWE8yMFdDdStGMWFYM2dYL285?= =?utf-8?B?ektzdkl1K3BqNXA2UFh2RHR6N0wxT0JnalNWa3dPUTc2ZmI5S2NrR0hLbC9j?= =?utf-8?B?dDdtWkRja1FMcmZoV2FuVk82RzFDWDdmSVNmMXQ5dGVPenVYaG12NUtDTlFW?= =?utf-8?B?S09XcHpHN3FiKzh4VzNYeWZjSnQ4dVh0cmhuRHp3TEpUNVVCakFiNnZWTEZC?= =?utf-8?B?K0pwcThJNHNPQ2hGOTdmZ2JYY2hpU0xjK2IrQ0dPYXc4c05lSmZOZGZuL0RM?= =?utf-8?B?SG5mbmppK2tYd2JYY1pucXVIeFdLWlljeG5jM1hsUHZJNHJqeWg2czd6QmNO?= =?utf-8?B?NUhMNzNTTGtiOFE4dXJaakFCSzlxL1pNSG90cG1UR0djUXVadTdEMmNDbjlO?= =?utf-8?B?RnlNMFkraWZabmpkSWtNTDdYdEhZRkZvaE94UGlZbVlEYVBOZ2Y5UWNvYzVZ?= =?utf-8?B?M0N4ZmNRSTYra0JsaTVTZ0YwMGJ3cGhTc1VIM2hXZmFWR3NVODNOVEppci9X?= =?utf-8?B?V1cweENMTVJTUjNOV3hrd211U04zeHIraS9mbnp3YVVSRnlTT0ZVR08vMFBS?= =?utf-8?Q?59Nw=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 6:Fgn0bnMJ4f/w852+5CmshjmX1aKaGGf58TKnDj61igN5ZFXBTxncyRPiBEg81H1F457XYesYSWRwzPn6Ij770XijSliQNlwTnMaMXqNyI8VK8jN5nfJ8NDxIo9CA/IWw9TronS6R1YxXEuUyoizzOagkBytLEce39SucUaJ6WQM5GDwO9x8ysFDdgaiVw5IvqMnp9+Tgwb7Weq77Dm/syUs0XLIWCAIwgt1TcIrsI3kDySzgvwhDu64ObjsPoPWURuQ13+9DryaOugxzwTQ8GL4gmviOZG/IACUTk80UytQc16KCtrFXvmkiFNExhyvb4OBC6uXB62sFikSEk+DSFHHoMGMmOHij1/OulrEOkII=; 5:ZplaiJglu9HGyA8npEvD9NeZmOlaXpEGAHwc0bXLUbBfGrQUXodsj1xmBxGOE69MOZZFxKKd8tadUnzlifwijA0SDqv88QraXcIFUN506dSxMxsKUAEix9DDAVCHanCJhSj+fyKjF0Ccf4FFlagerSb8qlM7zUrMM2PCYLl8RPI=; 24:+CCLsdmQ+4P8Fjotd/uJVTr+uMWeAMr3YH73QfF5fVxTXmVQedAhiOZoalKIgnj7dCiH8oy3LnoJ9KnehsNFD6GkHrAhgMHNp3tog8tOkg4=; 7:NZsiaGkLK5qMNWlvQE0+HyhOJBGsxtqMaSimSo3Dv/0bQ7Q8ZHCoSP3RdCXIlsJ3IjrTUtoIwAu64nnlsSDqN1SRhmuCHUElyFNwkVNuCU/gRLxWB5TkK0ax13JoE9pfIkqDJ1XFzhWz3oM9eCs9OzipPy73HzCK1JpxTBEDFxQsqHK5bMzZWJXQ0mJV74SqVtxzLsAqH3EaxOrTlrniG1L6JzG8JMGQZwYKUZNlxdq6WJMr06ABmpwB+gBxwsJg SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2017 14:37:42.0026 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ee72b4e7-76e5-4867-e63b-08d53bedbe47 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3428 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUyM2K7tK7FerUog/8PxCweHJnFbnFh1Vw2 i/kXG1ktTpzrY3Zg8ZjyeyOrx5IlP5k8Nl2+w+jR0n+RJYAlissmJTUnsyy1SN8ugStj0TKr go+CFTu+r2VuYJzO28XIySEhYCJxYu41JhBbSOAwo8TnrX5djFxA9nFGid6DZ5hBHBaBXmaJ 2ZvmMkJk2pgkrv9by97FyMEhLGAq0fmmDKRbRCBbYmbfZFYQm1lAXqJ75guo+kYmiVfnn4Al 2ASMJKb2n2cBsXkF7CX2zukHi7MIqEh0XlrMDmKLCsRIHO6ZzgpRIyhxcuYTsHpOAVuJXZcb mSAWaEi0zpnLDmGLS9x6Mp8JZnHz1tnMEK8pSFzffJ0F5AgJgYmMEkeftkH9qSHx8MJfVogi X4mlp5qgGpYwSrRdj4RoaGCXWHGqGapIVuLo2TksELaWRMf0DYwgNqNAnMTONQtZIRp2sEv8 v/yQBRQsEsCwOPdAEaI+WuLQsV9sEDULmCW+PTkHNVRG4vzVRSwTGHVmIfl0FpLvZiH5bhaS 7xYwsqxiFC1OLS7OTTcy1kstykwuLs7P08tLLdnECEwvB7f81t3BuPq14yFGAQ5GJR5etklq UUKsiWXFlbmHGCU4mJVEeJn7gUK8KYmVValF+fFFpTmpxYcYpTlYlMR5T3ryRgkJpCeWpGan phakFsFkmTg4pRoYfddMuDTBQfNRqYvk2/Mcf4Qv3L7xgZ+zrLVoaubM65x7HWQ7r6aFmqfW yXFXHF0/ea+aaE3WbYn2wuOTWm9u9/3hwhhv+KTVMI3r0wOtrx7/ZZW+7i5m0ptg9rPgWnJZ CIsJ80/BO5ECPwvLo3zsD1hcj0g+aizFpSCuVDfhxba1E66dT+xWYinOSDTUYi4qTgQAlqk0 bCsDAAA= Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 14:37:48 -0000



On 2017-12-05 11:04, Robert Wilton wrote:
I see your point now.
The server has to evaluate the when-stmts in operational.

I think that this is probably down to implementation, but I don't think that this is necessarily required.  A server is meant to conform to 'when' statements in <operational> (e.g. if the system is in a normal steady state), but they are allowed to be violated, and I'm not expecting that a server would evaluate them (except perhaps to discover implementation bugs).  Further, if violations of when statements in <operational> are detected then I don't think that there is anything that the server can reasonable do.
 
BALAZS: I always thought that if a when statement's argument was true but becomes false, all instance data that is set/written according to the schema nodes affected by the when statement shall be removed by the server.  So IMHO the server can and should do something about a violated when statement.

Actually I would like a list of statements and constraints that MUST be satisfied in the different data stores. Speaking about syntactic versus semantic seems fluffy.
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Tue Dec 5 06:39:49 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416CC1294E6 for ; Tue, 5 Dec 2017 06:39:47 -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 vjeS0qmvD3xD for ; Tue, 5 Dec 2017 06:39:45 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C709124F57 for ; Tue, 5 Dec 2017 06:39:45 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 37B1D1AE0144; Tue, 5 Dec 2017 15:39:44 +0100 (CET) Date: Tue, 05 Dec 2017 15:38:24 +0100 (CET) Message-Id: <20171205.153824.189055168841663121.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: rwilton@cisco.com, andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <409e9bb5-fcbe-d94f-a7cb-cb7961d9fdb2@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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 14:39:47 -0000 Balazs Lengyel wrote: > On 2017-12-05 11:04, Robert Wilton wrote: > > > > > > I see your point now. > The server has to evaluate the when-stmts in operational. > > I think that this is probably down to implementation, but I don't > think that this is necessarily required. A server is meant to > conform to 'when' statements in (e.g. if the system > is in a normal steady state), but they are allowed to be violated, > and I'm not expecting that a server would evaluate them (except > perhaps to discover implementation bugs). Further, if violations > of when statements in are detected then I don't > think that there is anything that the server can reasonable do. > > > > BALAZS: I always thought that if a when statement's argument was true > but becomes false, all instance data that is set/written according to > the schema nodes affected by the when statement shall be removed by > the server. So IMHO the server can and should do something about a > violated when statement. Yes. > Actually I would like a list of statements and constraints that MUST > be satisfied in the different data stores. Speaking about syntactic > versus semantic seems fluffy. See RFC 7950, section 8 (esp. 8.1 and 8.2). /martin From nobody Tue Dec 5 06:45:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BC91294F5 for ; Tue, 5 Dec 2017 06:45:32 -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 Jo1Qz7pyZrOv for ; Tue, 5 Dec 2017 06:45: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 6E4E81294D8 for ; Tue, 5 Dec 2017 06:45:26 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 95E221AE0144; Tue, 5 Dec 2017 15:45:25 +0100 (CET) Date: Tue, 05 Dec 2017 15:44:05 +0100 (CET) Message-Id: <20171205.154405.1949121812945596037.mbj@tail-f.com> To: bart.bogaert@nokia.com 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] WG Last Call: draft-ietf-netmod-entity-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: Tue, 05 Dec 2017 14:45:33 -0000 Hi, "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > Hello, > > The latest draft does not contain an appendix with the deprecated state tree Nothing has been deprecated since this will be the first published version of this module. > (to support the non-NMDA model as specified in RFC6087bis section 4.23.3), This would be a "New module". > so if it is published in this way, there is an issue at the level of BBF > TR-383. Can you elaborate on this? 6087bis says that we MAY include a temporay non-NMDA version (i.e., a module with just /hardware-state), but it would be a different module name (ietf-hardware-state) and a different XML namespace. > Note that the draft-ietfnetmod-rfc7223bis does include the deprecated > container interfaces-state. Yes, since ietf-interface has already been published. /martin > > Best regards, > Bart Bogaert > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, November 29, 2017 6:36 PM > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05 > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-entity-05. > > The working group last call ends on December 13. > 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. > > Thank you, > Netmod Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 5 06:46:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1231294EE for ; Tue, 5 Dec 2017 06:46:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rr8NiQn_Jad3 for ; Tue, 5 Dec 2017 06:46:40 -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 117F71294D8 for ; Tue, 5 Dec 2017 06:46: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 D88F0F33; Tue, 5 Dec 2017 15:46:38 +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 x8pPOLwe7pIZ; Tue, 5 Dec 2017 15:46: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; Tue, 5 Dec 2017 15:46:38 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBE7620128; Tue, 5 Dec 2017 15:46:38 +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 Man4rr1uLYit; Tue, 5 Dec 2017 15:46:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5229B20126; Tue, 5 Dec 2017 15:46:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 934F7418CC31; Tue, 5 Dec 2017 15:45:09 +0100 (CET) Date: Tue, 5 Dec 2017 15:45:09 +0100 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: NetMod WG Message-ID: <20171205144509.q2fktqg3u7knk2yv@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , NetMod WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-entity-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: Tue, 05 Dec 2017 14:46:43 -0000 Bart, I think the reason for the difference is that the interfaces model was published as an RFC before while the hardware model is new and hence it seems to look a bit odd to define new deprecated objects. If these deprecated objects are essential for BBF (please confirm), then it might be better to define them in a separate module that then can silently die while systems move to NMDA (and so we do not have the deprecated objects with us in the hardware module forever - or at least as long as we use YANG 1.1). /js On Tue, Dec 05, 2017 at 02:35:29PM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Hello, > > The latest draft does not contain an appendix with the deprecated state tree > (to support the non-NMDA model as specified in RFC6087bis section 4.23.3), > so if it is published in this way, there is an issue at the level of BBF > TR-383. > > Note that the draft-ietfnetmod-rfc7223bis does include the deprecated > container interfaces-state. > > Best regards, > Bart Bogaert > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, November 29, 2017 6:36 PM > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05 > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-entity-05. > > The working group last call ends on December 13. > 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. > > Thank you, > Netmod 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 -- 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 Dec 5 07:16:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FC0127369 for ; Tue, 5 Dec 2017 07:15:58 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 K7n6RrMsFABh for ; Tue, 5 Dec 2017 07:15:56 -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 74E17127333 for ; Tue, 5 Dec 2017 07:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6948; q=dns/txt; s=iport; t=1512486956; x=1513696556; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VcdSUazjPJNuyWj486PSdLnM9oPubP8tc37PwsnNRlA=; b=PM/BL3qyRe2/fgYsdKbIWdHEIW2zu0QfUI4x44k/by6eN63pJm/u0mTY 9VXi4mrZLFzv5HyEpbBg6BNIRv7eg6MBurxsOH4QWye8u50MLN3AkmQai ldAXMT7NWsGQEfkamoSN6AMkIlR0lu9uw+XIrBwNlSgWyFHcdN7vGzDNz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAAC4tyZa/4QNJK1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPWZuJweDeYogjnqBfZcCFIIBChgLhElPAhqFLD8YAQEBAQE?= =?us-ascii?q?BAQEBayiFIgEBAQECAQEBIQQNOhsCAQgSBgICJgICAiULFQIOAgQBEoobCBCoe?= =?us-ascii?q?YFtOopcAQEBAQEBAQEBAQEBAQEBAQEBAQEZBYEPgjmCCoM/gyuEdxIYF4J+gmM?= =?us-ascii?q?FonYCi1+JMpNYliQCERkBgTkBHzmBTW8VOoIphFV4iRWBFAEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208";a="326888809" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Dec 2017 15:15:43 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vB5FFgSh014286 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Dec 2017 15:15:43 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; Tue, 5 Dec 2017 10:15: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; Tue, 5 Dec 2017 10:15:42 -0500 From: "Acee Lindem (acee)" To: "Benoit Claise (bclaise)" , Vladimir Vassilev , "netmod@ietf.org" Thread-Topic: [netmod] review of draft-acee-netmod-rfc8022bis-05 Thread-Index: AQHTbcuMZJuCpmbmyUq+Ic+vgACwAKM03CSA Date: Tue, 5 Dec 2017 15:15:41 +0000 Message-ID: References: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com> 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: text/plain; charset="utf-8" Content-ID: <295F791060E48E498B9BE738936DBEEA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] review of draft-acee-netmod-rfc8022bis-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: Tue, 05 Dec 2017 15:15:59 -0000 SGkgQmVub2l0LA0KDQoNCk9uIDEyLzUvMTcsIDg6MTggQU0sICJCZW5vaXQgQ2xhaXNlIChiY2xh aXNlKSIgPGJjbGFpc2VAY2lzY28uY29tPiB3cm90ZToNCg0KPk9uIDExLzMvMjAxNyA1OjQ5IFBN LCBBY2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6DQo+PiBIaSBWbGFkaW1pciwNCj4+DQo+PiBUaGFu a3MgZm9yIGNvbW1lbnRzIC0gc2VlIGlubGluZS4NCj4+DQo+PiBPbiAxMC8yOS8xNywgODo0MyBQ TSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgVmxhZGltaXIgVmFzc2lsZXYiDQo+PiA8bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHZsYWRpbWlyQHRyYW5zcGFja2V0LmNvbT4gd3Jv dGU6DQo+Pg0KPj4+IEhlbGxvLA0KPj4+DQo+Pj4gSSBoYXZlIHJldmlld2VkIGRyYWZ0LWFjZWUt bmV0bW9kLXJmYzgwMjJiaXMtMDUuIE15IGNvbmNsdXNpb24gaXMgdGhhdA0KPj4+IHRoZSBZQU5H IG1vZHVsZXMgcGFydCBvZiB0aGUgZHJhZnQgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBtb2RpZmll ZCBpbg0KPj4+IGFjY29yZGFuY2Ugd2l0aCBzZWMuICc0LjIzLjMgTk1EQSBUcmFuc2l0aW9uIEd1 aWRlbGluZXMnIG9mDQo+Pj4gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2Jpcy0xNC4gVGhlIG1v ZGlmaWNhdGlvbnMgYXJlIGNvaGVyZW50IHdpdGgNCj4+PnRoZQ0KPj4+IGlldGYtaW50ZXJmYWNl c0AyMDE3LTA4LTE3LnlhbmcgbW9kdWxlIGluDQo+Pj4gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzI3 N2Jpcy0wMCBhbmQgaWV0Zi1pcEAyMDE3LTA4LTIxLnlhbmcgbW9kdWxlIGluDQo+Pj4gZHJhZnQt aWV0Zi1uZXRtb2QtcmZjNzI3N2Jpcy0wMC4NCj4+Pg0KPj4+IFZsYWRpbWlyDQo+Pj4NCj4+Pg0K Pj4+IFJldmlldyBvZiBkcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTA1Lg0KPj4+IFZsYWRp bWlyIFZhc3NpbGV2DQo+Pj4gMjAxNy0xMC0zMA0KPj4+DQo+Pj4gJ0Fic3RyYWN0JzoNCj4+PiAn SW50cm9kdWN0aW9uIDEnOg0KPj4+ICAgLSBCb3RoIEFic3RyYWN0IGFuZCBTZWMgMS4gY29udGFp biBkdXBsaWNhdGVkIHRleHQgd2hpY2ggY2FuIGJlDQo+Pj5yZW1vdmVkDQo+PiA+ZnJvbSBBYnN0 cmFjdC4gVGhlIHRleHQgaW4gU2VjIDEuIGNhbiBiZSBzaW1wbGlmaWVkOg0KPj4+IE9MRDoNCj4+ PiAgICAgVGhpcyB2ZXJzaW9uIG9mIHRoZXNlIFlBTkcgbW9kdWxlcyB1c2VzIG5ldyBuYW1lcyBm b3IgdGhlc2UgWUFORw0KPj4+ICAgICBtb2RlbHMuICBUaGUgbWFpbiBkaWZmZXJlbmNlIGZyb20g dGhlIGZpcnN0IHZlcnNpb24gaXMgdGhhdCB0aGlzDQo+Pj4gICAgIHZlcnNpb24gZnVsbHkgY29u Zm9ybXMgdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudCBEYXRhc3RvcmUNCj4+PiAgICAgQXJjaGl0 ZWN0dXJlIChOTURBKS4gIENvbnNlcXVlbnRseSwgdGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZD DQo+Pj44MDIyLg0KPj4+IE5FVzoNCj4+PiAgICAgVGhpcyB2ZXJzaW9uIG9mIHRoZSBSb3V0aW5n IE1hbmFnZW1lbnQgZGF0YSBtb2RlbCBzdXBwb3J0cyB0aGUNCj4+Pk5ldHdvcmsNCj4+PiAgICAg TWFuYWdlbWVudCBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIChOTURBKQ0KPj4+IFtJLUQuaWV0Zi1u ZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzXS4NCj4+IFRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0 aW9uIHNlY3Rpb25zIGFyZSBpbmRlcGVuZGVudCBhbmQgdGhlDQo+PmluZm9ybWF0aW9uDQo+PiBp cyBwZXJ0aW5lbnQgdG8gYm90aC4NCj5BY2VlLA0KPlRoZSBwb2ludCAoYXMgcmVwb3J0ZWQgYnkg c29tZW9uZSBlbHNlIHRvIG1lKSBpcyB0aGF0IHRoaXMgc2VudGVuY2UgaXMNCj5ub3QgY29ycmVj dCBhbmQgc2hvdWxkIGJlIHJlbW92ZWQuDQo+DQo+ICAgIFRoaXMgdmVyc2lvbiBvZiB0aGVzZSBZ QU5HIG1vZHVsZXMgdXNlcyBuZXcgbmFtZXMgZm9yIHRoZXNlIFlBTkcNCj4gICAgbW9kZWxzLg0K DQpBZ3JlZWQuIFdpbGwgZml4IGFzIHBhcnQgb2YgV0cgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpU aGFua3MsDQpBY2VlDQoNCj4NCj5SZWdhcmRzLCBCZW5vaXQNCj4+DQo+Pj4NCj4+PiAnNy4gIFJv dXRpbmcgTWFuYWdlbWVudCBZQU5HIE1vZHVsZSc6DQo+Pj4NCj4+PiAgIC0gV2h5IHNob3VsZCBh ZGRyZXNzLWZhbWlseSBpZGVudGl0eSBiZSBkaWZmZXJlbnQgZS5nLiBtYW5kYXRvcnkNCj4+PiAi ZmFsc2UiOyBmb3Igc3lzdGVtIGNyZWF0ZWQgUklCcz8gSSB0aGluayB0aGlzIG5lZWRzIHNvbWUg ZXhwbGFuYXRpb24NCj4+PiAoUGFnZSAyMSk6DQo+Pj4gICAgICAgICAgICAgLi4uDQo+Pj4gICAg ICAgICAgICAgdXNlcyBhZGRyZXNzLWZhbWlseSB7DQo+Pj4gICAgICAgICAgICAgICBkZXNjcmlw dGlvbg0KPj4+ICAgICAgICAgICAgICAgICAiQWRkcmVzcyBmYW1pbHkgb2YgdGhlIFJJQi4NCj4+ Pg0KPj4+ICAgICAgICAgICAgICAgICAgSXQgaXMgbWFuZGF0b3J5IGZvciB1c2VyLWNvbnRyb2xs ZWQgUklCcy4gIEZvcg0KPj4+ICAgICAgICAgICAgICAgICAgc3lzdGVtLWNvbnRyb2xsZWQgUklC cyBpdCBjYW4gYmUgb21pdHRlZDsgb3RoZXJ3aXNlLA0KPj4+aXQNCj4+PiAgICAgICAgICAgICAg ICAgIG11c3QgbWF0Y2ggdGhlIGFkZHJlc3MgZmFtaWx5IG9mIHRoZSBjb3JyZXNwb25kaW5nDQo+ Pj5zdGF0ZQ0KPj4+ICAgICAgICAgICAgICAgICAgZW50cnkuIjsNCj4+PiAgICAgICAgICAgICAg IHJlZmluZSAiYWRkcmVzcy1mYW1pbHkiIHsNCj4+PiAgICAgICAgICAgICAgICAgbWFuZGF0b3J5 ICJmYWxzZSI7DQo+Pj4gICAgICAgICAgICAgICB9DQo+Pj4gICAgICAgICAgICAgfQ0KPj4+ICAg ICAgICAgICAgIC4uLg0KPj4gSSB3aWxsIGRpc2N1c3MgdGhpcyB3aXRoIG15IGNvLWF1dGhvcnMu DQo+Pj4gICAtIFN1Z2dlc3RlZCBjaGFuZ2Ugb2YgJ2Jhc2UgYWRkcmVzcy1mYW1pbHk7JyAtPiAn YmFzZQ0KPj4+IHJ0OmFkZHJlc3MtZmFtaWx5OycgZm9yIGlkZW50aXR5IGlwdjQgYW5kIGlwdjYg KHJlZi4NCj4+PiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTE0I3NlY3Rpb24tNC4yKToN Cj4+Pg0KPj4+ICAgICAgbyBUaGUgbG9jYWwgbW9kdWxlIHByZWZpeCBNVVNUIGJlIHVzZWQgaW5z dGVhZCBvZiBubyBwcmVmaXggaW4NCj4+PiAgICAgIGFsbCAiZGVmYXVsdCIgc3RhdGVtZW50cyBm b3IgYW4gImlkZW50aXR5cmVmIiBvcg0KPj4+ICJpbnN0YW5jZS1pZGVudGlmaWVyIg0KPj4+ICAg ICAgICAgIGRhdGEgdHlwZQ0KPj4gSSBhZGRlZCDigJxydDrigJ0gd2hlcmUgaXQgd2FzIG1pc3Np bmcgdG8gdGhlIGlkZW50aXR5cmVmIHN0YXRlbWVudHMuIFRoaXMNCj4+IHdpbGwgYmUgaW4gdGhl IG5leHQgcmV2aXNpb24uDQo+Pj4gJzguICBJUHY0IFVuaWNhc3QgUm91dGluZyBNYW5hZ2VtZW50 IFlBTkcgTW9kdWxlJw0KPj4+IChpZXRmLWlwdjQtdW5pY2FzdC1yb3V0aW5nQDIwMTctMTAtMTQu eWFuZyk6DQo+Pj4gJzkuICBJUHY2IFVuaWNhc3QgUm91dGluZyBNYW5hZ2VtZW50IFlBTkcgTW9k dWxlJw0KPj4+IChpZXRmLWlwdjYtdW5pY2FzdC1yb3V0aW5nQDIwMTctMTAtMTQueWFuZyk6DQo+ Pj4NCj4+Pg0KPj4+ICAgLSBUaGUgaWV0Zi1pcHY0LXVuaWNhc3Qtcm91dGluZyBhbmQgaWV0Zi1p cHY2LXVuaWNhc3Qtcm91dGluZyBtb2R1bGVzDQo+Pj4gaW1wb3J0IHRoZSBpZXRmLXJvdXRpbmcg d2l0aG91dCByZXZpc2lvbiAocmVmLiByZmM2MDg3I3NlY3Rpb24tNC42KToNCj4+Pg0KPj4+DQo+ Pj4gICAgICBvIFRoZSByZXZpc2lvbi1kYXRlIHN1YnN0YXRlbWVudCB3aXRoaW4gdGhlIGltcG9y dHMgc3RhdGVtZW50DQo+Pj5TSE9VTEQNCj4+PiBiZQ0KPj4+ICAgICAgcHJlc2VudCBpZiBhbnkg Z3JvdXBpbmdzIGFyZSB1c2VkIGZyb20gdGhlIGV4dGVybmFsIG1vZHVsZS4iDQo+PiBTaW5jZSB0 aGVzZSBtb2R1bGVzIGFyZSBhbGwgaW4gdGhlIHNhbWUgZHJhZnQsIEnigJlkIHJhdGhlciBsZWF2 ZSBvdXQgdGhlDQo+PiByZXZpc2lvbiBkYXRlIGFzIGl0IGlzIGNsZWFuZXIgd2l0aG91dCBpdC4g TGV0IG1lIGRpc2N1c3Mgd2l0aCBteQ0KPj4gY28tYXV0aG9ycy4NCj4+Pg0KPj4+ICdBcHBlbmRp eCBELiBEYXRhIFRyZWUgRXhhbXBsZSc6DQo+Pj4NCj4+PiAgIC0gVGhlIGV4YW1wbGUgaW4gdGhl IEFwcGVuZGl4IEQuIGhhcyBub3QgYmVlbiB1cGRhdGVkIGFuZCBpdCBtdXN0IGJlDQo+Pj4gZXh0 ZW5kZWQgaW4gb3JkZXIgdG8gZGVtb25zdHJhdGUgYSB1c2VjYXNlIG9mIG9wZXJhdGlvbmFsIGRh dGFzdG9yZSBvZg0KPj4+IGNvbmZpZ3VyYXRpb24gZGF0YSB3aXRoIGRpZmZlcmVudCBvcmlnaW4g KGludGVuZGVkLCBzeXN0ZW0sIGV0Yy4pDQo+Pj4gc2ltaWxhciB0byB0aGUgJ0FwcGVuZGl4IEMu IEV4YW1wbGUgRGF0YScgb2YNCj4+PiBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9y ZXMtMDUuDQo+PiBBY3R1YWxseSwgbm9uZSBvZiB0aGUgZXhhbXBsZXMgYWNjZXNzZWQgb3BlcmF0 aW9uYWwgc3RhdGUgZGF0ZSBpbiBSRkMNCj4+IDgwMjIuIEhvd2V2ZXIsIEkgYWdyZWUgdGhhdCB0 aGlzIHNob3VsZCBiZSBhZGRlZCBhbmQgd2XigJlsbCB3b3JrIG9uIGl0Lg0KPj4+DQo+Pj4gTml0 czoNCj4+PiAgIC0gcy9GaWd1cmVzIDEvRmlndXJlIDEvDQo+Pj4gICAtIHMvc3lzdGVtaW5kZXBl bmRlbnRseS9zeXN0ZW0gaW5kZXBlbmRlbnRseS8NCj4+IFRoYW5rcyBmb3IgY2F0Y2hpbmcgLSBJ IGZpeGVkIHRoZXNlIGluIHRoZSAtMDEgdmVyc2lvbiBvZg0KPj4gZHJhZnQtaWV0Zi1uZXRtb2Qt cmZjODAyMmJpcy0wMS50eHQuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gQWNlZQ0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0K DQo= From nobody Tue Dec 5 07:31:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22855129537 for ; Tue, 5 Dec 2017 07:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 HwC1xpJi-Q9f for ; Tue, 5 Dec 2017 07:31:54 -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 648FC129536 for ; Tue, 5 Dec 2017 07:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1512487914; x=1513697514; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5VyrmV5JSkMxXOTZ0uAWBDF+uF4aOjSYyEhV5vEYEzY=; b=WV2PxNwoLOW61IHP5cgLz5aIngcGRl8sMmDY9So88eTWznp2b98W0Jrw 52Orc8Udo09deOKUgA0QGqlkwrymFxjMYCcV1D/CPf20bEYXY0dnxOjv6 V9As55q2E8d4Q+Wxpbe0j3tVPW2mTQU8UDTyHps+/MBy80DK141m5jQ1C 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAQA6uyZa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYURJ4QAixSPVAkmlxaCAQqFOwKGChQBAQEBAQEBAQFrKIUiAQE?= =?us-ascii?q?BAQIBIw8BBUEQCw4KAgImAgJXBgEMBgIBAYoXCKkvgieKXAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBASCBD4I5g2CBaSkLgneFCQKDK4JjAQSidpUTghaJdYdNij6EF4d8gTo?= =?us-ascii?q?2IoFNMhoIGxU6gimEVUE3iikBAQE?= X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208";a="655282" 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; 05 Dec 2017 15:31:52 +0000 Received: from [10.63.23.85] (dhcp-ensft1-uk-vla370-10-63-23-85.cisco.com [10.63.23.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB5FVpub011854; Tue, 5 Dec 2017 15:31:52 GMT To: Martin Bjorklund , balazs.lengyel@ericsson.com Cc: andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org References: <409e9bb5-fcbe-d94f-a7cb-cb7961d9fdb2@cisco.com> <20171205.153824.189055168841663121.mbj@tail-f.com> From: Robert Wilton Message-ID: <4e1e5ccd-4338-0cd7-5aa2-978da8103f0e@cisco.com> Date: Tue, 5 Dec 2017 15:31:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171205.153824.189055168841663121.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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 15:31:56 -0000 On 05/12/2017 14:38, Martin Bjorklund wrote: > Balazs Lengyel wrote: >> On 2017-12-05 11:04, Robert Wilton wrote: >> >> >> >> >> >> I see your point now. >> The server has to evaluate the when-stmts in operational. >> >> I think that this is probably down to implementation, but I don't >> think that this is necessarily required. A server is meant to >> conform to 'when' statements in (e.g. if the system >> is in a normal steady state), but they are allowed to be violated, >> and I'm not expecting that a server would evaluate them (except >> perhaps to discover implementation bugs). Further, if violations >> of when statements in are detected then I don't >> think that there is anything that the server can reasonable do. >> >> >> >> BALAZS: I always thought that if a when statement's argument was true >> but becomes false, all instance data that is set/written according to >> the schema nodes affected by the when statement shall be removed by >> the server. So IMHO the server can and should do something about a >> violated when statement. > Yes. But I still don't think that requires that you have to evaluate when constraints on . E.g. [implementation dependent]:  - user sends config to  - server calculates change to including implicit deletes due to now false when statements.  - server sends calculated config change to daemons.  - config daemons late update operational with the updated applied configuration.  When statements can be transiently violated in operational, but should converge to the behavior defined in the data model, all being well. Thanks, Rob > >> Actually I would like a list of statements and constraints that MUST >> be satisfied in the different data stores. Speaking about syntactic >> versus semantic seems fluffy. > See RFC 7950, section 8 (esp. 8.1 and 8.2). > > > /martin > . > From nobody Tue Dec 5 07:53:04 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542B9129564 for ; Tue, 5 Dec 2017 07:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, 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 pDN3l-tlxSa8 for ; Tue, 5 Dec 2017 07:52:59 -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 638A5129562 for ; Tue, 5 Dec 2017 07:52:58 -0800 (PST) Received: from birdie (cst-prg-19-60.cust.vodafone.cz [46.135.19.60]) by mail.nic.cz (Postfix) with ESMTPSA id 0B09B63F16; Tue, 5 Dec 2017 16:52:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512489176; bh=/LLoPKlsfk1Ikm/7e2WgLmnBwQ2CGQN8pEh7uT1HoeY=; h=From:To:Date; b=Pyp/jWFvmD1QsgIZEE9sd2gljf5ijVfdZI8oiKhJpsKqRVetwqeQlZfauO5X2Xe0A INVVIAZ1lDmXkgR2lqtCHtIhOzpjcCFn8coQx2iQTojcbkxuGl8EVFfRJPu28DPF4B IkSQPlH/DRMjNJvMS95b2BVN77wPG7gVTWNE25q4= Message-ID: <1512489175.18679.7.camel@nic.cz> From: Ladislav Lhotka To: Martin Bjorklund , balazs.lengyel@ericsson.com Cc: rwilton@cisco.com, andy@yumaworks.com, netmod@ietf.org Date: Tue, 05 Dec 2017 16:52:55 +0100 In-Reply-To: <20171205.153824.189055168841663121.mbj@tail-f.com> References: <409e9bb5-fcbe-d94f-a7cb-cb7961d9fdb2@cisco.com> <20171205.153824.189055168841663121.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 15:53:03 -0000 On Tue, 2017-12-05 at 15:38 +0100, Martin Bjorklund wrote: > Balazs Lengyel wrote: > > On 2017-12-05 11:04, Robert Wilton wrote: > > > > > > > > > > > > I see your point now. > > The server has to evaluate the when-stmts in operational. > > > > I think that this is probably down to implementation, but I don't > > think that this is necessarily required. A server is meant to > > conform to 'when' statements in (e.g. if the system > > is in a normal steady state), but they are allowed to be violated, > > and I'm not expecting that a server would evaluate them (except > > perhaps to discover implementation bugs). Further, if violations > > of when statements in are detected then I don't > > think that there is anything that the server can reasonable do. > > > > > > > > BALAZS: I always thought that if a when statement's argument was true > > but becomes false, all instance data that is set/written according to > > the schema nodes affected by the when statement shall be removed by > > the server. So IMHO the server can and should do something about a > > violated when statement. > > Yes. Even in ? > > > Actually I would like a list of statements and constraints that MUST > > be satisfied in the different data stores. Speaking about syntactic > > versus semantic seems fluffy. > > See RFC 7950, section 8 (esp. 8.1 and 8.2). Yes, and I think it is fully appropriate to denote constraints that have to be satisfied in all data trees as "syntactic" (or "schema constraints") and those that are needed for validity as "semantic". That said, I think it would be useful to reconsider the allocations of constraints into these two categories. Lada > > > /martin -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 5 08:07:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1685129557 for ; Tue, 5 Dec 2017 08:07:20 -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 TXF3EfZU9zIl for ; Tue, 5 Dec 2017 08:07:14 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 699D2127342 for ; Tue, 5 Dec 2017 08:07:14 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 6E79D18215DE; Tue, 5 Dec 2017 17:06:08 +0100 (CET) Received: from localhost (cst-prg-19-60.cust.vodafone.cz [46.135.19.60]) by trail.lhotka.name (Postfix) with ESMTPSA id 143D91820F78; Tue, 5 Dec 2017 17:06:03 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org In-Reply-To: <20171204.220916.1239542403096469961.mbj@tail-f.com> References: <1512407158.6635.8.camel@nic.cz> <20171204172247.rj3ilazharvzbyn6@elstar.local> <1512410991.8751.4.camel@nic.cz> <20171204.220916.1239542403096469961.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de, netmod@ietf.org Date: Tue, 05 Dec 2017 17:06:57 +0100 Message-ID: <87374pduqm.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] evaluation of "when" under NMDA X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 16:07:21 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> On Mon, 2017-12-04 at 18:22 +0100, Juergen Schoenwaelder wrote: >> > On Mon, Dec 04, 2017 at 06:05:58PM +0100, Ladislav Lhotka wrote: >> > > On Mon, 2017-12-04 at 17:34 +0100, Martin Bjorklund wrote: >> > > > Ladislav Lhotka wrote: >> > > > > Hi, >> > > > > >> > > > > if we have >> > > > > >> > > > > augment "/target/node" { >> > > > > when "..."; >> > > > > ... >> > > > > } >> > > > > >> > > > > is the "when" expression supposed to be evaluated separately in each >> > > > >> > > > datastore, >> > > > > and the augment applied only in those datastores where the result is >> > > > > true? >> > > > >> > > > Yes. >> > > >> > > But then it cannot be guaranteed that the schema for is a >> > > superset >> > > of the schema of configuration datastores - the when expression can evaluate >> > > to >> > > false in but true in . >> > > >> > >> > For me, its still the same schema - a when expression does not change >> > my notion of 'schema'. > > Agreed. > >> Well, according to draft-ietf-netmod-revised-datastores-07: >> >> o 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. > > This text does not write that nodes with false when expressions are > not considered part of the schema. > >> And "when" determines whether a given schema node is valid or not. So if a >> schema node is invalid in the schema of but valid in the schema of >> > > They are still part of the schema. > > Again, it is a matter of terminology - when we say that the "schema" > of is a superset of the "schema" of the conventional > datastores, we do not exclude false when expressions from the > "schema". As per the defintion above we include the modules, their > features and deviations in the term "schema". My understanding was that superset means that the schema tree of has to be a subtree of schema tree. The paragraph in revised-datastores-07 seems to support this interpretation as it talks about "YANG nodes omitted from ", not about modules, features and deviations: The datastore schema for MUST be a superset of the combined datastore schema used in all configuration datastores except that YANG nodes supported in a configuration datastore MAY be omitted from if a server is not able to accurately report them. Lada > > > /martin > > > >>, then the former can hardly be a superset of the latter. >> >> Lada >> >> > >> > /js >> > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> 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 Dec 5 09:22:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EA0127871; Tue, 5 Dec 2017 09:22:19 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 K1Wt69U1J13w; Tue, 5 Dec 2017 09:22:17 -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 9C8951272E1; Tue, 5 Dec 2017 09:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1640; q=dns/txt; s=iport; t=1512494537; x=1513704137; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AWh7vyXTrGgHwdRQUO6TFG3F7o2nHVBdtFNoOMoWdjo=; b=X+rCRV2ws6qVolgkWwsBfiHZa5lDCBGQaETXw7RMaLbnSYMI4jsuc2rs FOC6WlIFA6hL7/dZ0cz4yu3bPPY2ndXDGiAL05ZYJXa/X60vBbjj3Dm61 ps2uwbcWrjqT3Y0g5gRVBfY2zKHe1gBA6qEr3nbmeGW+Je+7wjAg+JrM+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAC61CZa/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9Zm4nB44ZjnuBfZcCghUKGAuESU8ChUg/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohSIBAQEBAgEBATg0CwULAgEIDgoeECcLJQIEAQ0FCIoTCBCsA4pcAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDSIIKgVaBaYMrg0uHTgWidgKHdI0Ugh+GEYsxij6?= =?us-ascii?q?CQ4kjAhEZAYE5AR85gU1vFTqCKYRVeAGJFIEUAQEB?= X-IronPort-AV: E=Sophos;i="5.45,364,1508803200"; d="scan'208";a="322595306" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 17:22:16 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vB5HMGwc019589 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Dec 2017 17:22:16 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Dec 2017 12:22:15 -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; Tue, 5 Dec 2017 12:22:15 -0500 From: "Eric Voit (evoit)" To: Kent Watsen , "netmod@ietf.org" , "Acee Lindem (acee)" CC: "netmod-chairs@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 Thread-Index: AQHTaYFiSitRVtWa5kmwd58FDuHquqM1Bb1g Date: Tue, 5 Dec 2017 17:22:15 +0000 Message-ID: <0841e825090340c1b0f2c09894a40f74@XCH-RTP-013.cisco.com> References: In-Reply-To: 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.86.244.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 17:22:19 -0000 I have reviewed the doc as well, and I also support publication. One thought for future work might be the interplay of this document and som= e LLDP model. There are YANG models for LLDP proving very interesting for= network management, and any consistency rules/interactions of this with rf= c7277bis' "rw neighbor*" objects could prove fairly complex. Eric > On 11/28/17, 2:43 PM, "netmod on behalf of Kent Watsen" > wrote: >=20 > >[resending] > > > > > >All, > > > >This starts a two-week working group last call on > >draft-ietf-netmod-rfc7277bis-00. > > > >Please recall that this update's intention is to modify the YANG module > >to be in line with the NMDA guidelines [1]. Reviewing the diff between > >the two drafts [2] should reveal just this. > > > >The working group last call ends on December 12. > >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. > > > >[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > >[2] > >https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7277bis-00.tx= t > > > >Thank you, > >Netmod Chairs > > > > > > > >_______________________________________________ > >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 Dec 5 13:06:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682351270AE; Tue, 5 Dec 2017 13:06:46 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 4xyEXBTRbJng; Tue, 5 Dec 2017 13:06:44 -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 4DDE4126DCA; Tue, 5 Dec 2017 13:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3766; q=dns/txt; s=iport; t=1512508004; x=1513717604; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eh3HDJ7Jdm4H+DUENz5FSotLXw+yc3hGk9+LKm151kU=; b=kq1K5PeGXLRahr6kxe2CeV6Y7GztSXdlgGt8mb+awHDyDkiz4Xchgy06 MXYJCMCOyRZftVNCwBPcW3OiVEelqel+uzFAtZ+jP9Uxb17RgHwCVdDCJ 5hgLEhYVBfvrh0aUr9xe82GQNFQw2c9u28Y0EYfB2U02tO4VJeyiLQ3Gp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAwDxCSda/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9Zm4nB4N5mRuYf4IVChgLhElPAhqFLkEWAQEBAQEBAQEBayh?= =?us-ascii?q?CDoRTAgEDAQEhEToLEAIBBgIODAIjAwICAiULFAEQAgQOBQiKGxCLcp1sgieKU?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+ERYFWgWmDK4NLhGuCYwWSBpBwAod?= =?us-ascii?q?0jRSCH4YRizGKPoJDiSMCERkBgTkBJQEygU1vFTqCKYRVeAGDQYVNgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,365,1508803200"; d="scan'208";a="327030891" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Dec 2017 21:06:43 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB5L6hWM006218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Dec 2017 21:06:43 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Dec 2017 16:06:42 -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; Tue, 5 Dec 2017 16:06:42 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netmod-chairs@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 Thread-Index: AQHTbQ5udz8cF8W6eU+ueJswQQEYXqM1NkGg Date: Tue, 5 Dec 2017 21:06:42 +0000 Message-ID: <9ce71a856a04495fa8d11fde4cc9c845@XCH-RTP-013.cisco.com> References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <20171204.154448.2155397561484121188.mbj@tail-f.com> In-Reply-To: <20171204.154448.2155397561484121188.mbj@tail-f.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.86.244.103] 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-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2017 21:06:46 -0000 SGkgTWFydGluLA0KDQpTZXZlcmFsIGNvbW1lbnRzIG9uIHRoZSBZQU5HIG1vZGVsIHdpdGhpbiBy ZmM3MjIzYmlzLg0KDQpsaXN0IGludGVyZmFjZSB7DQogICAgICAgIGtleSAibmFtZSI7DQogICAg ICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgIlRoZSBsaXN0IG9mIGludGVyZmFjZXMgb24gdGhl IGRldmljZS4gIFRoZSBzdGF0dXMgb2YgYW4gaW50ZXJmYWNlIGlzIGF2YWlsYWJsZSBpbiB0aGlz IGxpc3QgaW4gdGhlDQogICAgICAgICAgIG9wZXJhdGlvbmFsIHN0YXRlLi4uDQoNCkEgZmV3IHF1 ZXN0aW9ucyBvbiB0aGlzLg0KKGEpIFRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgbGlzdCBkZWZpbmVz IGJlaGF2aW9ycyBvZiB2YXJpb3VzIGxpc3Qgbm9kZXMgd2hpY2ggbWlnaHQgb3IgbWlnaHQgbm90 IGV4aXN0IGluIGRpZmZlcmVudCBOTURBIGRhdGFzdG9yZXMuICBJdCBhbHNvIHN1Z2dlc3RzIHdo ZW4gY2VydGFpbiBlbGVtZW50cyBzaG91bGQgYmUgcG9wdWxhdGVkIGluIHZhcmlvdXMgZGF0YXN0 b3Jlcy4gIElzIHRoZSBwcmVjZWRlbmNlIGJlaW5nIHNldCB0aGF0IGRhdGFzdG9yZSBzcGVjaWZp YyBiZWhhdmlvcnMgbWF5IGJlIHBsYWNlZCBpbnRvIGRlc2NyaXB0aW9ucz8gIElzIHRoaXMgdHlw ZSBvZiBkb2N1bWVudGF0aW9uIGd1aWRhbmNlIHNvbWV0aGluZyB3aGljaCBleHBsb3JlZCBpbiBk cmFmdC1kc2R0LW5tZGEtZ3VpZGVsaW5lcz8gICANCihiKSBEb2VzIHN0YXR1cyBtZWFuICdhZG1p bi1zdGF0dXMnLCAnb3Blci1zdGF0dXMnIG9yIGJvdGg/ICAoSSB0aGluayAnb3Blci1zdGF0dXMn LikNCihjKSBzaG91bGQgcXVvdGVzIGJlIHVzZWQgYXJvdW5kIHN0YXR1cz8NCg0KbGVhZiBuYW1l IHssICAgbGVhZiB0eXBlIHsgLi4uLg0KVGhlcmUgYXJlIE5FVENPTkYgc3BlY2lmaWMgYmVoYXZp b3JzIGluIHRoZSBkZWZpbml0aW9uIG9mIHRoZXNlIHR3byBsZWF2ZXMuICAgSXQgd291bGQgYmUg Z3JlYXQgdG8gaGF2ZSB0aGlzIHRyYW5zcG9ydCBhZ25vc3RpYy4gIEkgcmVhbGl6ZSB0aGF0IHN1 Y2ggYSB0cmFuc3BvcnQgc2VnbWVudGF0aW9uIGRpc3NvY2lhdGVzIHRyYW5zcG9ydCBlcnJvciBo YW5kbGluZyBmcm9tIHRoZSBub2RlcyBiZWluZyBoYW5kbGVkLg0KDQpsZWFmIGFkbWluLXN0YXR1 cyB7Li4uDQppbmNvcnJlY3RseSBtYXJrZWQgIGFzIGNvbmZpZyBmYWxzZTsNCg0KVGhhbmtzLA0K RXJpYw0KDQoNCj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBuZXRt b2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEtlbnQgV2F0c2VuDQo+ ID4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTHmnIgyOeaXpSAzOjI5DQo+ID4g5pS25Lu25Lq6OiBu ZXRtb2RAaWV0Zi5vcmcNCj4gPiDmioTpgIE6IG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmcNCj4gPiDk uLvpopg6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzIyM2Jp cy0wMA0KPiA+DQo+ID4gQWxsLA0KPiA+DQo+ID4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW5ldG1vZC0NCj4gcmZjNzIyM2Jpcy0w MC4NCj4gPg0KPiA+IFBsZWFzZSByZWNhbGwgdGhhdCB0aGlzIHVwZGF0ZSdzIGludGVudGlvbiBp cyB0byBtb2RpZnkgdGhlIFlBTkcgbW9kdWxlIHRvDQo+IGJlIGluIGxpbmUgd2l0aCB0aGUgTk1E QSBndWlkZWxpbmVzIFsxXS4gIFJldmlld2luZyB0aGUgZGlmZiBiZXR3ZWVuIHRoZQ0KPiB0d28g ZHJhZnRzIFsyXSBzaG91bGQgcmV2ZWFsIGp1c3QgdGhpcy4NCj4gPg0KPiA+IFRoZSB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIERlY2VtYmVyIDEyLg0KPiA+IFBsZWFzZSBzZW5kIHlv dXIgY29tbWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QuDQo+ID4NCj4gPiBQb3NpdGl2 ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgYmVsaWV2 ZSBpdCBpcw0KPiByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENCj4gPiBUaGlz IGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCj4gPg0KPiA+IFsx XSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMt MDENCj4gPiBbMl0NCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAwLnR4DQo+ID4gdA0KPiA+DQo+ID4gVGhhbmsgeW91 LA0KPiA+IE5ldG1vZCBDaGFpcnMNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4g bmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBs aXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0K From nobody Wed Dec 6 04:37:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5DE12762F for ; Wed, 6 Dec 2017 04:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlnQ_vxOY8LQ for ; Wed, 6 Dec 2017 04:37: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 988D71273E2 for ; Wed, 6 Dec 2017 04:37:37 -0800 (PST) Received: from birdie1784 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 395176434A for ; Wed, 6 Dec 2017 13:37:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512563856; bh=DIq7nvtNFHu0CfPlhKEmpktvsAjhWB7+/0fmcmw9B30=; h=From:To:Date; b=jfTkc1OmnQOgIIPvjLkXepJhhq+IcgMsb7EQe6PD7LRSwRzrwY5H4TofQbX3PsKtP LBGwzskOEFPb41VurB6R+bbE+fTyvv8mrBT6wZgZB0VOSeteN0c6pBPhs+nCH9sWv8 dgHuQO9slk8EiLtHePp0ecjCIkFH7iz3yekT0mGE= Message-ID: <1512563856.2653.41.camel@nic.cz> From: Ladislav Lhotka To: NETMOD WG Date: Wed, 06 Dec 2017 13:37:36 +0100 Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] summary line in descriptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2017 12:37:39 -0000 Hi, although detailed descriptions is a good thing, my recent experiences with web clients for RESTCONF indicate that they can become clumsy and unwieldy in such user interfaces. I think it would be useful to adopt a convention similar to Git commit messages: one relatively short summary line followed by an empty line, and the rest of the description after that. User interfaces could then easily recognize and use the summary line. Perhaps 6087bis could include such a recommendation. Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 6 04:49:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1D128AB0 for ; Wed, 6 Dec 2017 04:49: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 oUYwI5S-Epaw for ; Wed, 6 Dec 2017 04:49: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 40668128954 for ; Wed, 6 Dec 2017 04:49:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 88E7A1500FFC; Wed, 6 Dec 2017 13:49:02 +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 QJWl4xrk017x; Wed, 6 Dec 2017 13:49:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 646231501003; Wed, 6 Dec 2017 13:49:02 +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 zWBnk8VC3w76; Wed, 6 Dec 2017 13:49:02 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 369D81500FFC; Wed, 6 Dec 2017 13:49:02 +0100 (CET) To: "Eric Voit (evoit)" Cc: "netmod@ietf.org" References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> <20171204.154448.2155397561484121188.mbj@tail-f.com> <9ce71a856a04495fa8d11fde4cc9c845@XCH-RTP-013.cisco.com> From: Vladimir Vassilev Message-ID: <8766f78c-2ff6-e948-f736-9a18507ec7b9@transpacket.com> Date: Wed, 6 Dec 2017 13:49:01 +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: <9ce71a856a04495fa8d11fde4cc9c845@XCH-RTP-013.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2017 12:49:12 -0000 On 12/05/2017 10:06 PM, Eric Voit (evoit) wrote: > Hi Martin, > > Several comments on the YANG model within rfc7223bis. > > list interface { > key "name"; > description > "The list of interfaces on the device. The status of an int= erface is available in this list in the > operational state... > > A few questions on this. > (a) The description of the list defines behaviors of various list nodes= which might or might not exist in different NMDA datastores. It also su= ggests when certain elements should be populated in various datastores. = Is the precedence being set that datastore specific behaviors may be plac= ed into descriptions? Is this type of documentation guidance something w= hich explored in draft-dsdt-nmda-guidelines? > (b) Does status mean 'admin-status', 'oper-status' or both? (I think '= oper-status'.) > (c) should quotes be used around status? > > leaf name {, leaf type { .... > There are NETCONF specific behaviors in the definition of these two lea= ves. It would be great to have this transport agnostic. I realize that= such a transport segmentation dissociates transport error handling from = the nodes being handled. > > leaf admin-status {... > incorrectly marked as config false; I think config false; is correct. The 'admin-status' leaf is a pre-NMDA=20 workaround for IF-MIB implementations that coexist with the=20 ietf-interfaces implementation e.g. reflect the value of ifAdminStatus=20 independently configurable of the /interfaces/interface/enabled value.=20 This is described in the description statement of=20 /interfaces/interface/enabled. This potentially could also be accomplished by using NMDA origin meta=20 notation in operational showing /interfaces/interface/enabled is=20 overwritten by origin that is not 'intended' e.g. or:origin=3Dor:system o= r=20 maybe custom origin or:origin=3Dor-snmp:snmp? IMO 'admin-status' is a too broad name for something that is only if-mib=20 relevant. This is an example of something that can be solved with NMDA=20 in a more general way without clogging the model with additional leaf=20 but for backward compatibility and to avoid unnecessary confusion should=20 be kept the way it is in draft-ietf-netmod-rfc7223bis-00. Vladimir > > Thanks, > Eric > > >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Kent Watsen >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B411=E6=9C=8829=E6=97= =A5 3:29 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org >>> =E6=8A=84=E9=80=81: netmod-chairs@ietf.org >>> =E4=B8=BB=E9=A2=98: [netmod] WG Last Call: draft-ietf-netmod-rfc7223b= is-00 >>> >>> All, >>> >>> This starts a two-week working group last call on draft-ietf-netmod- >> rfc7223bis-00. >>> Please recall that this update's intention is to modify the YANG modu= le to >> be in line with the NMDA guidelines [1]. Reviewing the diff between t= he >> two drafts [2] should reveal just this. >>> The working group last call ends on December 12. >>> 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. >>> >>> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 >>> [2] >>> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7223bis-00= .tx >>> t >>> >>> Thank you, >>> Netmod 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Dec 6 05:15:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550481286C7 for ; Wed, 6 Dec 2017 05:15:43 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg5jjDmtbZOM for ; Wed, 6 Dec 2017 05:15:40 -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 E466E128792 for ; Wed, 6 Dec 2017 05:15:37 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 15CFEE91; Wed, 6 Dec 2017 14:15:36 +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 WZPZMnZ_YOa7; Wed, 6 Dec 2017 14:15:34 +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, 6 Dec 2017 14:15:36 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 020F420129; Wed, 6 Dec 2017 14:15:36 +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 f9WlFG_fPwvQ; Wed, 6 Dec 2017 14:15:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D313C2012C; Wed, 6 Dec 2017 14:15:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7B952418DECC; Wed, 6 Dec 2017 14:14:05 +0100 (CET) Date: Wed, 6 Dec 2017 14:14:05 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: NETMOD WG Message-ID: <20171206131405.cwi4eoikau67abps@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , NETMOD WG References: <1512563856.2653.41.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512563856.2653.41.camel@nic.cz> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] summary line in descriptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2017 13:15:43 -0000 I am not sure design decisions of some web clients that provide clumsy user experience should impact how we write data models. If we need summary lines, we should properly separate them via ext:summary "this does magic, see the description" instead of relying on conventions. /js On Wed, Dec 06, 2017 at 01:37:36PM +0100, Ladislav Lhotka wrote: > Hi, > > although detailed descriptions is a good thing, my recent experiences with web > clients for RESTCONF indicate that they can become clumsy and unwieldy in such > user interfaces. I think it would be useful to adopt a convention similar to Git > commit messages: one relatively short summary line followed by an empty line, > and the rest of the description after that. User interfaces could then easily > recognize and use the summary line. > > Perhaps 6087bis could include such a recommendation. > > Lada > > -- > 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 Wed Dec 6 05:52:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B925128AB0 for ; Wed, 6 Dec 2017 05:52:33 -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 jg_-TCQzA5-o for ; Wed, 6 Dec 2017 05:52:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A924312895E for ; Wed, 6 Dec 2017 05:52:31 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B4B841AE0336; Wed, 6 Dec 2017 14:52:30 +0100 (CET) Date: Wed, 06 Dec 2017 14:51:10 +0100 (CET) Message-Id: <20171206.145110.2020944959715437189.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: lhotka@nic.cz, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20171206131405.cwi4eoikau67abps@elstar.local> References: <1512563856.2653.41.camel@nic.cz> <20171206131405.cwi4eoikau67abps@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] summary line in descriptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2017 13:52:34 -0000 Juergen Schoenwaelder wrote: > I am not sure design decisions of some web clients that provide clumsy > user experience should impact how we write data models. If we need > summary lines, we should properly separate them via > > ext:summary "this does magic, see the description" > > instead of relying on conventions. I agree. Incidentally, that's what we do (with a vendor specific extension). /martin > > /js > > On Wed, Dec 06, 2017 at 01:37:36PM +0100, Ladislav Lhotka wrote: > > Hi, > > > > although detailed descriptions is a good thing, my recent experiences with web > > clients for RESTCONF indicate that they can become clumsy and unwieldy in such > > user interfaces. I think it would be useful to adopt a convention similar to Git > > commit messages: one relatively short summary line followed by an empty line, > > and the rest of the description after that. User interfaces could then easily > > recognize and use the summary line. > > > > Perhaps 6087bis could include such a recommendation. > > > > Lada > > > > -- > > 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Dec 6 05:55:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5FE128DF3 for ; Wed, 6 Dec 2017 05:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpzIfHp5bn78 for ; Wed, 6 Dec 2017 05:55:51 -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 6E135128AB0 for ; Wed, 6 Dec 2017 05:55:51 -0800 (PST) Received: from birdie1784 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 882BA64435; Wed, 6 Dec 2017 14:55:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512568549; bh=eUqBa+M9SOOUUEzyD6azhtKYmSqLx4QuvaIwH+cWEAM=; h=From:To:Date; b=aYtdf2Tmjc+VPVAHPBb6GOM2kqOK62iidzffA7TJL0MWM7Y3uYvTAuArFP7SiODAb fVZSGw0MPgrOJ5mzkBimEKHGk9H3tqn40cI1R90DhSxYevAN8YVAU9kEgcVg4zmjzT ms3vA41BYkT9ATUYVoMQOxndAGukyk/OG/ET1rtU= Message-ID: <1512568549.2653.62.camel@nic.cz> From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org Date: Wed, 06 Dec 2017 14:55:49 +0100 In-Reply-To: <20171206.145110.2020944959715437189.mbj@tail-f.com> References: <1512563856.2653.41.camel@nic.cz> <20171206131405.cwi4eoikau67abps@elstar.local> <20171206.145110.2020944959715437189.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] summary line in descriptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2017 13:55:55 -0000 On Wed, 2017-12-06 at 14:51 +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > I am not sure design decisions of some web clients that provide clumsy > > user experience should impact how we write data models. If we need > > summary lines, we should properly separate them via > > > > ext:summary "this does magic, see the description" > > > > instead of relying on conventions. > > I agree. Incidentally, that's what we do (with a vendor specific > extension). So if you have a single-line description, you replicate it in this extension's parameter? Lada > > > /martin > > > > > > /js > > > > On Wed, Dec 06, 2017 at 01:37:36PM +0100, Ladislav Lhotka wrote: > > > Hi, > > > > > > although detailed descriptions is a good thing, my recent experiences with > web > > > clients for RESTCONF indicate that they can become clumsy and unwieldy in > such > > > user interfaces. I think it would be useful to adopt a convention similar > to Git > > > commit messages: one relatively short summary line followed by an empty > line, > > > and the rest of the description after that. User interfaces could then > easily > > > recognize and use the summary line. > > > > > > Perhaps 6087bis could include such a recommendation. > > > > > > Lada > > > > > > -- > > > 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 > > > > _______________________________________________ > > 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 Dec 6 06:02:10 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29E12896F for ; Wed, 6 Dec 2017 06:02:08 -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 g2osaoWs1qDx for ; Wed, 6 Dec 2017 06:02:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AACB91200B9 for ; Wed, 6 Dec 2017 06:02:01 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B52201AE0141; Wed, 6 Dec 2017 15:02:00 +0100 (CET) Date: Wed, 06 Dec 2017 15:00:41 +0100 (CET) Message-Id: <20171206.150041.1063143145053874766.mbj@tail-f.com> To: lhotka@nic.cz Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1512568549.2653.62.camel@nic.cz> References: <20171206131405.cwi4eoikau67abps@elstar.local> <20171206.145110.2020944959715437189.mbj@tail-f.com> <1512568549.2653.62.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] summary line in descriptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2017 14:02:08 -0000 Ladislav Lhotka wrote: > On Wed, 2017-12-06 at 14:51 +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > I am not sure design decisions of some web clients that provide clumsy > > > user experience should impact how we write data models. If we need > > > summary lines, we should properly separate them via > > > > > > ext:summary "this does magic, see the description" > > > > > > instead of relying on conventions. > > > > I agree. Incidentally, that's what we do (with a vendor specific > > extension). > > So if you have a single-line description, you replicate it in this extension's > parameter? I have seen that. In some cases people simply don't put in the normal description in that case, just tailf:info. But for "real" nodes, the description tend to be longer than the short info. /martin > > Lada > > > > > > > /martin > > > > > > > > > > /js > > > > > > On Wed, Dec 06, 2017 at 01:37:36PM +0100, Ladislav Lhotka wrote: > > > > Hi, > > > > > > > > although detailed descriptions is a good thing, my recent experiences with > > web > > > > clients for RESTCONF indicate that they can become clumsy and unwieldy in > > such > > > > user interfaces. I think it would be useful to adopt a convention similar > > to Git > > > > commit messages: one relatively short summary line followed by an empty > > line, > > > > and the rest of the description after that. User interfaces could then > > easily > > > > recognize and use the summary line. > > > > > > > > Perhaps 6087bis could include such a recommendation. > > > > > > > > Lada > > > > > > > > -- > > > > 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 > > > > > > _______________________________________________ > > > 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 Dec 6 06:25:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C67126DD9 for ; Wed, 6 Dec 2017 06:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKE8GgwD_g0A for ; Wed, 6 Dec 2017 06:25:40 -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 B357D1270FC for ; Wed, 6 Dec 2017 06:25:39 -0800 (PST) Received: from birdie1784 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 17AF264491; Wed, 6 Dec 2017 15:25:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512570338; bh=0Qo2+MCZ5soKx2OPkbB5MobhNzFkN/teND8GcrLW8Dc=; h=From:To:Date; b=hd6aVixJGjpvuf9bZNO+5rorF+5zjYIk23r8OKfnxRCQKzIDqoBvJ3QJD9ulr1Bai 8FEsgEkpivOJeNWBd2e87RUKGe2KFKX7V+1dNc3U86Ha7TjGfESeTeLdd1j5+QUoiw 8y8g9sZGoQXEqr2C679W3fgEV4CG+EHBP8XCcTBM= Message-ID: <1512570337.2653.68.camel@nic.cz> From: Ladislav Lhotka To: Martin Bjorklund Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org Date: Wed, 06 Dec 2017 15:25:37 +0100 In-Reply-To: <20171206.150041.1063143145053874766.mbj@tail-f.com> References: <20171206131405.cwi4eoikau67abps@elstar.local> <20171206.145110.2020944959715437189.mbj@tail-f.com> <1512568549.2653.62.camel@nic.cz> <20171206.150041.1063143145053874766.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] summary line in descriptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Dec 2017 14:25:42 -0000 On Wed, 2017-12-06 at 15:00 +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > On Wed, 2017-12-06 at 14:51 +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > I am not sure design decisions of some web clients that provide clumsy > > > > user experience should impact how we write data models. If we need > > > > summary lines, we should properly separate them via > > > > > > > > ext:summary "this does magic, see the description" > > > > > > > > instead of relying on conventions. > > > > > > I agree. Incidentally, that's what we do (with a vendor specific > > > extension). > > > > So if you have a single-line description, you replicate it in this > extension's > > parameter? > > I have seen that. In some cases people simply don't put in the normal > description in that case, just tailf:info. But for "real" nodes, the > description tend to be longer than the short info. I just briefly checked "ietf-interfaces" and "ietf-routing", and most descriptions for data nodes are either single line or already follow the convention that I proposed. Lada > > > /martin > > > > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > > > > > > /js > > > > > > > > On Wed, Dec 06, 2017 at 01:37:36PM +0100, Ladislav Lhotka wrote: > > > > > Hi, > > > > > > > > > > although detailed descriptions is a good thing, my recent experiences > with > > > web > > > > > clients for RESTCONF indicate that they can become clumsy and unwieldy > in > > > such > > > > > user interfaces. I think it would be useful to adopt a convention > similar > > > to Git > > > > > commit messages: one relatively short summary line followed by an > empty > > > line, > > > > > and the rest of the description after that. User interfaces could then > > > easily > > > > > recognize and use the summary line. > > > > > > > > > > Perhaps 6087bis could include such a recommendation. > > > > > > > > > > Lada > > > > > > > > > > -- > > > > > 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 > > > > > > > > _______________________________________________ > > > > 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 Dec 6 10:23:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0562A124239 for ; Wed, 6 Dec 2017 10:23: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 covLPjkDv549 for ; Wed, 6 Dec 2017 10:23:39 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 E3A0D1241F5 for ; Wed, 6 Dec 2017 10:23:38 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id k15so2536426pgr.7 for ; Wed, 06 Dec 2017 10:23: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:message-id:references :to; bh=r4iurvGgKe25GbiLNBWmx+Hr1/RJAuwXMcdLRXIEMHU=; b=tuunu5+f0ztjmxk7olTX4aiOWp8dYDK0DBogM4+txon0i/VeF51HyUNiJzCWXt45Nd qtbiGMHXt8tTpKxwnEfpN0+bITsPZnMojMqGd8EufagPXfCwQQKeELjbsAjVgUj4ntLv bpTQcN76H8ZFtwn5SxZzfiRb3aGnslDe3OIaAFIe3zWrFC8CiBQsEOgkJ6XjzWaIv8Ay /XxroDLEQ/OpCbxvJ3ui/VB1J/kCbsDnc4zM0ik219YP3mqOvNlTdsSOoriNCBBicqX0 h/JdMj/4RQkTWxMCwPGuxfgY/niLhD1DCgcXTB/VLdqkPLCb2g7fjtKUho3cfmI2+HwM gxiQ== 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 :message-id:references:to; bh=r4iurvGgKe25GbiLNBWmx+Hr1/RJAuwXMcdLRXIEMHU=; b=A/1dZlz9p86gcKda2eEDEY4ZdiP1ooMjb3wQBPgZW4fVesMavsPOkQPjzyZv0LcVf6 GVAQBgt8CBlI4IvVu5g7SYL3UHNktb+FCQeIl7f22wP6PAZAXpyP4IJjPA2VwVKmLEjy gqhbLVrl4w0JKUE37BWrDR3aFkzaqEx8uLXG065dWwpggtxfQgKyKwbqaSgtuWcq1DwD 2HvTbyi7cFIqPTiKX+O9qR1WLYcbd8Ype8sU1/FTXL3XfQjdc3ETUjvKhciuusjh1bMs SHRjOJYK2GDHffwHCTbEyB7zFW27xTsqZyS67ZHHdpm+DgSKfQgotspeGqs8gcWjF0j8 Ztfw== X-Gm-Message-State: AKGB3mIlcvRm5xHu1pgcufI+Yc83u6kJWHr61LqBTc1UlpYYI7rzFBqh 8znX7aqK1HNOBeJdYjMFNdi5OqK+ X-Google-Smtp-Source: AGs4zMaExMS/EBwJCaNlOLDqh6YIw1T+k+te3j6bDrnN5k+E6iQIHBO4jvBdcXvqNbgAJcT8M7FRpg== X-Received: by 10.84.213.9 with SMTP id f9mr5569731pli.26.1512584618297; Wed, 06 Dec 2017 10:23:38 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:9837:a310:fafb:a3a2]) by smtp.gmail.com with ESMTPSA id m8sm4795848pgc.64.2017.12.06.10.23.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Dec 2017 10:23:37 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6FD691BA-8EDE-4E1D-BC94-4BF7AE461BC6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <20171103084231.GE12688@spritelink.se> Date: Wed, 6 Dec 2017 10:23:28 -0800 Cc: Robert Wilton , Martin Bjorklund , netmod@ietf.org 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> To: Kristian Larsson X-Mailer: Apple Mail (2.3124) 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, 06 Dec 2017 18:23:41 -0000 --Apple-Mail=_6FD691BA-8EDE-4E1D-BC94-4BF7AE461BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Moving to the next issue on the list > On Nov 3, 2017, at 1:42 AM, Kristian Larsson = wrote: >=20 >> Personally, I would put the ACL interface attachment points as an >> augmentation of if:interfaces/interface rather than having a separate = top >> level list, but perhaps that is just want I am used to ... >=20 > +1 on augmentation of interfaces. 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. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6FD691BA-8EDE-4E1D-BC94-4BF7AE461BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Moving to the next issue on the list

On = Nov 3, 2017, at 1:42 AM, Kristian Larsson <kristian@spritelink.net> wrote:

Personally, I would put the ACL interface attachment points = as an
augmentation of if:interfaces/interface rather than = having a separate top
level list, but perhaps that is just = want I am used to ...

+1 on augmentation of = interfaces.

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.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_6FD691BA-8EDE-4E1D-BC94-4BF7AE461BC6-- From nobody Wed Dec 6 11:43:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C9F128959 for ; Wed, 6 Dec 2017 11:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 fkY3kW4eLuAY for ; Wed, 6 Dec 2017 11:43:09 -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 15287127873 for ; Wed, 6 Dec 2017 11:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2451; q=dns/txt; s=iport; t=1512589389; x=1513798989; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=+0usHRIvBNlLQabpducmsgImpu4VzxdYKU908SyjAJk=; b=GALyyHpcj/t1z9Wy3leZwlag8OemLN5GhKZ/HDN1Pi/H5QzyBANnhwwh qUdp800y/6TOF2LjMgTpMXR5g37uosACTwGhw2/uNOGP9EuC659tkgJnK bLWgvwMGuRiurctfW1vzMZI7r6TxFq1vH/woHVFM/8WGAbKHI1PLzkUS9 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCERyha/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYURhCmLFJAEmRoHA4U7AoYXFAEBAQEBAQEBAWsohSMBBSNWEAk?= =?us-ascii?q?CDgoqAgJXBgEMCAEBih+LG51sgieKVAEBAQEBAQEBAQEBAQEBAQEBAREPiUSDA?= =?us-ascii?q?og2gmMBBKJ9hEmCK44lgX2KD4dPllOBOjYigU4yGggbFYJkhFVAiiQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,369,1508803200"; d="asc'?scan'208";a="735021" 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; 06 Dec 2017 19:43:05 +0000 Received: from [10.61.224.198] ([10.61.224.198]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vB6Jh5Zg028464; Wed, 6 Dec 2017 19:43:05 GMT To: Mahesh Jethanandani , Kristian Larsson Cc: 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> From: Eliot Lear Message-ID: Date: Wed, 6 Dec 2017 20:43:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d4nrxHkcwpbT7k2bp0xEUsQx7MwtkNmeH" 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, 06 Dec 2017 19:43:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d4nrxHkcwpbT7k2bp0xEUsQx7MwtkNmeH Content-Type: multipart/mixed; boundary="XPR9cvNhNOnX4HSTNvwjaCwV0T0RCeuH7"; protected-headers="v1" From: Eliot Lear To: Mahesh Jethanandani , Kristian Larsson Cc: 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> In-Reply-To: --XPR9cvNhNOnX4HSTNvwjaCwV0T0RCeuH7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US 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 m= ight 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. --XPR9cvNhNOnX4HSTNvwjaCwV0T0RCeuH7-- --d4nrxHkcwpbT7k2bp0xEUsQx7MwtkNmeH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJaKEhHAAoJEIe2a0bZ0nozak8H/RQ/TOBY464A5uWEQQAGXxF0 iBwZaJpfdBq9/dwtLW7AATTBenVd17LXP1aMC68o8wu5RPAnQaFhh9MH1nEr7f96 FGCNx3QCx83emrPexopuiyENtXb1NO26xDlptiHm6VCoC1dnsVKaPqN6oP69to8y Pt3Pfl4Zoav01z3DUNFgBGRH69YufBgA9pXg0Eq+exxsoMb+GYD419mwAs3WcXYq 7XRgQyX6VKr3zr3J7TcbDgniKel1Rjq/JlPth+TJsi0wIeSlq2qJNVqdfvHzqdG/ +/1Ka2aUtnO6q8woiVTfJI0WHYn+XrXXYADEuPs7zm/lPgSKI36/Bl6KYIS8gr8= =RUIz -----END PGP SIGNATURE----- --d4nrxHkcwpbT7k2bp0xEUsQx7MwtkNmeH-- From nobody Thu Dec 7 00:01:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B051201F8; Thu, 7 Dec 2017 00:01:49 -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 LIuGCw-G0830; Thu, 7 Dec 2017 00:01: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 3534A126C0F; Thu, 7 Dec 2017 00:01:47 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EFFB1AE0335; Thu, 7 Dec 2017 09:01:46 +0100 (CET) Date: Thu, 07 Dec 2017 09:00:26 +0100 (CET) Message-Id: <20171207.090026.2261269114308135275.mbj@tail-f.com> To: evoit@cisco.com Cc: netmod-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <9ce71a856a04495fa8d11fde4cc9c845@XCH-RTP-013.cisco.com> References: <20171204.154448.2155397561484121188.mbj@tail-f.com> <9ce71a856a04495fa8d11fde4cc9c845@XCH-RTP-013.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] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2017 08:01:49 -0000 SGkgRXJpYywNCg0KDQoiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb20+IHdyb3Rl Og0KPiBIaSBNYXJ0aW4sDQo+IA0KPiBTZXZlcmFsIGNvbW1lbnRzIG9uIHRoZSBZQU5HIG1vZGVs IHdpdGhpbiByZmM3MjIzYmlzLg0KPiANCj4gbGlzdCBpbnRlcmZhY2Ugew0KPiAgICAgICAgIGtl eSAibmFtZSI7DQo+ICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgICJUaGUgbGlzdCBv ZiBpbnRlcmZhY2VzIG9uIHRoZSBkZXZpY2UuICBUaGUgc3RhdHVzIG9mIGFuIGludGVyZmFjZQ0K PiAgICAgICAgICAgaXMgYXZhaWxhYmxlIGluIHRoaXMgbGlzdCBpbiB0aGUNCj4gICAgICAgICAg ICBvcGVyYXRpb25hbCBzdGF0ZS4uLg0KPiANCj4gQSBmZXcgcXVlc3Rpb25zIG9uIHRoaXMuDQo+ IChhKSBUaGUgZGVzY3JpcHRpb24gb2YgdGhlIGxpc3QgZGVmaW5lcyBiZWhhdmlvcnMgb2YgdmFy aW91cyBsaXN0DQo+IG5vZGVzIHdoaWNoIG1pZ2h0IG9yIG1pZ2h0IG5vdCBleGlzdCBpbiBkaWZm ZXJlbnQgTk1EQSBkYXRhc3RvcmVzLiAgSXQNCj4gYWxzbyBzdWdnZXN0cyB3aGVuIGNlcnRhaW4g ZWxlbWVudHMgc2hvdWxkIGJlIHBvcHVsYXRlZCBpbiB2YXJpb3VzDQo+IGRhdGFzdG9yZXMuICBJ cyB0aGUgcHJlY2VkZW5jZSBiZWluZyBzZXQgdGhhdCBkYXRhc3RvcmUgc3BlY2lmaWMNCj4gYmVo YXZpb3JzIG1heSBiZSBwbGFjZWQgaW50byBkZXNjcmlwdGlvbnM/DQoNCkkgZG9uJ3Qga25vdzsg SSBndWVzcyBpdCBkZXBlbmRzIG9uIHdoYXQgcGVvcGxlIHRoaW5rIGFib3V0IHRoaXMNCnN0eWxl LiAgSSB0aGluayB0aGF0IHdoZW4gdGhlIG1hcHBpbmcgYmV0d2VlbiBjb25maWcgYW5kIG9wZXJh dGlvbmFsDQpzdGF0ZSBpcyBub3QgMS0xIGFuZCBvYnZpb3VzLCBpdCBuZWVkcyB0byBiZSBzb21l aG93IGV4cGxhaW5lZCBpbiB0aGUNCmRlc2NyaXB0aW9uIC0ganVzdCBsaWtlIHRoZSBvbGQgZGVz Y3JpcHRpb25zIGRpZCwgZXhjZXB0IHRoYXQgd2hlcmUNCnRoZSBvbGQgZGVzY3JpcHRpb25zIHJl ZmVyZWQgdG8gZGlmZmVyZW50ICpub2RlcyosIHdlIG5vdyByZWZlciB0bw0KZGlmZmVyZW50ICpp bnRhbnRpYXRpb25zKiBvZiB0aGUgc2FtZSBub2RlLg0KDQoNCj4gSXMgdGhpcyB0eXBlIG9mDQo+ IGRvY3VtZW50YXRpb24gZ3VpZGFuY2Ugc29tZXRoaW5nIHdoaWNoIGV4cGxvcmVkIGluDQo+IGRy YWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzPw0KDQpJIGRvbid0IHRoaW5rIHNvLg0KDQo+IChiKSBE b2VzIHN0YXR1cyBtZWFuICdhZG1pbi1zdGF0dXMnLCAnb3Blci1zdGF0dXMnIG9yIGJvdGg/ICAo SSB0aGluaw0KPiAnb3Blci1zdGF0dXMnLikNCg0KTm8sIGl0IGlzIGludGVuZGVkIHRvIG1lYW4g dGhlIHN0YXR1cyBvZiB0aGUgaW50ZXJmYWNlIGluIGdlbmVyYWwuDQoNCj4gKGMpIHNob3VsZCBx dW90ZXMgYmUgdXNlZCBhcm91bmQgc3RhdHVzPw0KDQpObywgc2luY2UgaXQncyBub3QgdGhlIG5h bWUgb2YgYSBzcGVjaWZpYyBub2RlLg0KDQo+IGxlYWYgbmFtZSB7LCAgIGxlYWYgdHlwZSB7IC4u Li4NCj4gVGhlcmUgYXJlIE5FVENPTkYgc3BlY2lmaWMgYmVoYXZpb3JzIGluIHRoZSBkZWZpbml0 aW9uIG9mIHRoZXNlIHR3bw0KPiBsZWF2ZXMuICBJdCB3b3VsZCBiZSBncmVhdCB0byBoYXZlIHRo aXMgdHJhbnNwb3J0IGFnbm9zdGljLg0KDQpPbmUgdGhpbmcgdG8gbm90ZSBpcyB0aGF0IHRoaXMg YWxzbyBzaG91bGQgYXBwbHkgdG8gYSBSRVNUQ09ORg0Kc2VydmVyLiAgQnV0IGFkZGluZyB0aGF0 IGRvZXNuJ3QgcmVhbGx5IGFkZHJlc3MgeW91ciBwb2ludCA6KQ0KSG93ZXZlciwgSSBkb24ndCBr bm93IHdoYXQgdGhlIGNvcnJlY3Qgd2F5IG9mIGhhbmRsaW5nIHRoaXMgd291bGQgYmUuDQpXZSBj b3VsZCBiZSBsZXNzIHNwZWNpZmljIGFuZCBqdXN0IHdyaXRlIHRoYXQgdGhlIHNlcnZlciBNVVNU IHJldHVybg0KYW4gImludmFsaWQtdmFsdWUiIGVycm9yLCBidXQgbGVzcyBzcGVjaWZpYyBtaWdo dCBhbHNvIGJlIG1vcmUNCmNvbmZ1c2luZy4NCg0KPiBJIHJlYWxpemUNCj4gdGhhdCBzdWNoIGEg dHJhbnNwb3J0IHNlZ21lbnRhdGlvbiBkaXNzb2NpYXRlcyB0cmFuc3BvcnQgZXJyb3INCj4gaGFu ZGxpbmcgZnJvbSB0aGUgbm9kZXMgYmVpbmcgaGFuZGxlZC4NCj4gDQo+IGxlYWYgYWRtaW4tc3Rh dHVzIHsuLi4NCj4gaW5jb3JyZWN0bHkgbWFya2VkICBhcyBjb25maWcgZmFsc2U7DQoNClNlZSB0 aGUgcmVwbHkgZnJvbSBWbGFkaW1pcjsgdGhpcyBpcyBjb3JyY2VjdC4NCg0KDQovbWFydGluDQoN Cg0KPiANCj4gVGhhbmtzLA0KPiBFcmljDQo+IA0KPiANCj4gPiA+IC0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCj4gPiA+IOWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqCBLZW50IFdhdHNlbg0KPiA+ID4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTHm nIgyOeaXpSAzOjI5DQo+ID4gPiDmlLbku7bkuro6IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4g5oqE 6YCBOiBuZXRtb2QtY2hhaXJzQGlldGYub3JnDQo+ID4gPiDkuLvpopg6IFtuZXRtb2RdIFdHIExh c3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzIyM2Jpcy0wMA0KPiA+ID4NCj4gPiA+IEFs bCwNCj4gPiA+DQo+ID4gPiBUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIG9uIGRyYWZ0LWlldGYtbmV0bW9kLQ0KPiA+IHJmYzcyMjNiaXMtMDAuDQo+ID4gPg0K PiA+ID4gUGxlYXNlIHJlY2FsbCB0aGF0IHRoaXMgdXBkYXRlJ3MgaW50ZW50aW9uIGlzIHRvIG1v ZGlmeSB0aGUgWUFORw0KPiA+ID4gbW9kdWxlIHRvDQo+ID4gYmUgaW4gbGluZSB3aXRoIHRoZSBO TURBIGd1aWRlbGluZXMgWzFdLiAgUmV2aWV3aW5nIHRoZSBkaWZmIGJldHdlZW4NCj4gPiB0aGUN Cj4gPiB0d28gZHJhZnRzIFsyXSBzaG91bGQgcmV2ZWFsIGp1c3QgdGhpcy4NCj4gPiA+DQo+ID4g PiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBEZWNlbWJlciAxMi4NCj4gPiA+ IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QuDQo+ ID4gPg0KPiA+ID4gUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQNCj4gPiA+IGlzDQo+ID4gcmVhZHkgZm9yIHB1YmxpY2F0 aW9uIiwgYXJlIHdlbGNvbWUhDQo+ID4gPiBUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBl dmVuIGZyb20gYXV0aG9ycy4NCj4gPiA+DQo+ID4gPiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzLTAxDQo+ID4gPiBbMl0NCj4gPiA+IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXJmYzcy MjNiaXMtMDAudHgNCj4gPiA+IHQNCj4gPiA+DQo+ID4gPiBUaGFuayB5b3UsDQo+ID4gPiBOZXRt b2QgQ2hhaXJzDQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBu ZXRtb2RAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYub3Jn DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0 bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Thu Dec 7 12:03:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318DD1294CE for ; Thu, 7 Dec 2017 12:03:04 -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, 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 sn_XcViaNOdg for ; Thu, 7 Dec 2017 12:03:02 -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 08BBF1293EE for ; Thu, 7 Dec 2017 12:03:02 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB7JxCII027454; Thu, 7 Dec 2017 12:03:00 -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=zqs/0x9L4DkkxVyJCJzJ0Faf+QoIxX+aDi8N/rRCVEA=; b=OjbRMAib2TDmB+e3KOICWsIpUkl/yM32vIwDaOJrF8vEElSyGOdqoah8AZbZBdRoPbvC HCYhkzUiiVe8BaNUYYKQi8OkoNrudGNh7GEI69mH8C2zbxFc27W7Ar0tN5UsaDPZh6Ey nbsf0hSXblV2bJxwe9LCG+oFtmfEWLe9Kckechq3GggFJIGhVlmXfBrMBAl1GoUi3w/L wE+/dM88QpnrUfy7/LdMkd9P6P1LJA5oDX4hzkAQBjeQwxMj/7wzRgPXyvQq6rv0vw8n lw65RSBMAdQeLZRygW+OkjLtCSzsszwB/xxhHXvJJtb7zRL2DHxFYPMerSa9IGMc24SD Fg== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0055.outbound.protection.outlook.com [216.32.180.55]) by mx0a-00273201.pphosted.com with ESMTP id 2eqb7gr686-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Dec 2017 12:02:59 -0800 Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB279.namprd05.prod.outlook.com (10.141.64.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Thu, 7 Dec 2017 20:02:57 +0000 Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::38c7:9ea8:b320:1eb]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::38c7:9ea8:b320:1eb%14]) with mapi id 15.20.0302.010; Thu, 7 Dec 2017 20:02:57 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Bogaert, Bart (Nokia - BE/Antwerp)" CC: NetMod WG Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-entity-05 Thread-Index: AQHTaTiKb8BGrVZUXkOliaJmI9zIUKM02iaAgAACtICAAymjgA== Date: Thu, 7 Dec 2017 20:02:57 +0000 Message-ID: <25A8BF74-A6F2-4F0B-AD73-AA992FF28E05@juniper.net> References: <20171205144509.q2fktqg3u7knk2yv@elstar.local> In-Reply-To: <20171205144509.q2fktqg3u7knk2yv@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.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN1PR05MB279; 6:llLplvrk5G5hav3qiLQxX1lphj5ebuKQgQ26GkcdQvSFflSXObwJYTBCg34KiqwZQv+NzinJLMbejXZxoUnMpTRQjlZlaB3XpgJn7o0H+K1RaHIahnoIArT6IbJ2jkuWOlkcugg11cx2cfB8sgfoUixOCiDDyBbD6DI5kFPljiNu+qVrzuzf7/PV6PeVUa7Ow72TE/BYQljawoIlPnz1xpexYsK2TppTB/eZlDLNITDDAkVtDAzU5cRwqfwWvmdOSdz44Zu6NfzAU3lHDFuuJL16sQZEheAjm2iST6gHovqOLPOOIPmyTOYXv2jYovxK/PEm+N2k8oQ0a5L7gns4s7uBy0Ei5QvXy6HtNCPxfSE=; 5:78m6euTYfeJuwUO8Atptl4wQUM4xss0KGfZAwRttKfM1nG/NSqSzyQy/D2eJ1g71S3mDZWuLc4QSPGNIuICx54+j7xlheH7GWuTVtaY4aNnt1L1ihu2tSWTG3LPQI8+2yG1lnp6W4WsX/LsY7S2c1NdriPloldJyNYu4GDJBDtw=; 24:JoRj+rT0TV0PIRO60iIbhcSUFN3b/iva6bAtH2Og0tkodp2TRZ1P5dNjS4hpiTWbdZPNJuh8JKRw7qEmLjGQyx8OgkIoRad4Zact8aGUh28=; 7:7fMc1bi7Pum5C2Ti0Yb6R2Eb3urvCoA5SREaNpT4hCNgXYKWFgtxAfuSLYRmJUPlxTWwE9N79gCA680lI04TRmiU5kUZmat/ebdZhlQ7lhZOasECdYGZVifJNSbAQ2th2BplO7p8tgfeQDlMK2OhedgoZeFh8AzWOY0Lnq12UCDRHpeZQptwRVhUdt+pfVxO3KLngQx97oA1D2ljNCHCWMaFiD4M/28JFY0LvR9HBYh67DeyP7A6mKBNh4/Pk5Vv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 98bae02a-df01-47fb-b127-08d53dad8309 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603286); SRVR:BN1PR05MB279; x-ms-traffictypediagnostic: BN1PR05MB279: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:BN1PR05MB279; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN1PR05MB279; x-forefront-prvs: 05143A8241 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(346002)(13464003)(24454002)(199004)(189003)(106356001)(33656002)(230783001)(478600001)(105586002)(229853002)(101416001)(6486002)(966005)(8936002)(14454004)(6506006)(66066001)(110136005)(86362001)(575784001)(53546010)(81156014)(58126008)(316002)(4326008)(8676002)(81166006)(2906002)(97736004)(6436002)(6306002)(2900100001)(6246003)(53936002)(7736002)(68736007)(83716003)(36756003)(3846002)(305945005)(102836003)(3280700002)(6116002)(76176011)(82746002)(5660300001)(3660700001)(25786009)(99286004)(5250100002)(2950100002)(83506002)(8656006)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB279; H:BN1PR05MB280.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) 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: 98bae02a-df01-47fb-b127-08d53dad8309 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 20:02:57.8942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB279 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-07_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-1712070293 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-entity-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: Thu, 07 Dec 2017 20:03:04 -0000 QWxsLA0KDQpQaWNraW5nIHVwIG9uIEp1ZXJnZW4ncyBjb21tZW50Og0KDQo+IElmIHRoZXNlIGRl cHJlY2F0ZWQgb2JqZWN0cyBhcmUgZXNzZW50aWFsIGZvciBCQkYgKHBsZWFzZSBjb25maXJtKSwN Cj4gdGhlbiBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gZGVmaW5lIHRoZW0gaW4gYSBzZXBhcmF0ZSBt b2R1bGUuLi4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBvYmplY3RzIHNob3VsZCBiZSBkZWZpbmVkIGlu IGEgc2VwYXJhdGUgbW9kdWxlLiAgVGhlDQpyZXF1ZXN0LCBhcyBJIHVuZGVyc3RhbmQgaXQsIGlz IGZvciB0aGVyZSBiZSBhbiAiaWV0Zi1oYXJkd2FyZS1zdGF0ZSINCm1vZHVsZSBkZWZpbmVkIGlu IHRoZSBBcHBlbmRpeCBvZiB0aGlzIGRyYWZ0LiAgSSBiZWxpZXZlIHRoYXQgZG9pbmcNCnNvIGlz IGNvbnNpc3RlbnQgd2l0aCB0aGUgTk1EQSBndWlkZWxpbmVzOg0KDQogICAoYikgTW9kZWxzIHRo YXQgcmVxdWlyZSBpbW1lZGlhdGUgc3VwcG9ydCBmb3IgImluIHVzZSIgYW5kICJzeXN0ZW0NCiAg IGNyZWF0ZWQiIGluZm9ybWF0aW9uIFNIT1VMRCBiZSBzdHJ1Y3R1cmVkIGZvciBOTURBLiAgQSBu b24tTk1EQQ0KICAgdmVyc2lvbiBvZiB0aGVzZSBtb2RlbHMgU0hPVUxEIGV4aXN0LCBlaXRoZXIg YW4gZXhpc3RpbmcgbW9kZWwgb3IgYQ0KICAgbW9kZWwgY3JlYXRlZCBlaXRoZXIgYnkgaGFuZCBv ciB3aXRoIHN1aXRhYmxlIHRvb2xzIHRoYXQgbWlycm9yIHRoZQ0KICAgY3VycmVudCBtb2RlbGlu ZyBzdHJhdGVnaWVzLiAgQm90aCB0aGUgTk1EQSBhbmQgdGhlIG5vbi1OTURBIG1vZHVsZXMNCiAg IFNIT1VMRCBiZSBwdWJsaXNoZWQgaW4gdGhlIHNhbWUgZG9jdW1lbnQsIHdpdGggTk1EQSBtb2R1 bGVzIGluIHRoZQ0KICAgZG9jdW1lbnQgbWFpbiBib2R5IGFuZCB0aGUgbm9uLU5NREEgbW9kdWxl cyBpbiBhIG5vbi1ub3JtYXRpdmUNCiAgIGFwcGVuZGl4LiAgVGhlIHVzZSBvZiB0aGUgbm9uLU5N REEgbW9kZWwgd2lsbCBhbGxvdyB0ZW1wb3JhcnkNCiAgIGJyaWRnaW5nIG9mIHRoZSB0aW1lIHBl cmlvZCB1bnRpbCBOTURBIGltcGxlbWVudGF0aW9ucyBhcmUgYXZhaWxhYmxlLg0KDQpPZiBjb3Vy c2UsIHdlIHNob3VsZCBhc2ssIGZvciBob3cgbG9uZyBpcyBpdCB0aGF0IHRoZSBJRVRGIChTRE9z IGluIA0KZ2VuZXJhbCkgc2hvdWxkIHB1Ymxpc2ggdGhlc2UgLXN0YXRlIG1vZHVsZXM/ICAgRHVy aW5nIHRoZSBkaXNjdXNzaW9uDQphdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBmaXJzdCBzZXNzaW9u IGluIFNpbmdhcG9yZSwgSSBzYWlkIHNvbWV0aGluZw0KYWxvbmcgdGhlIGxpbmVzIG9mICJzbyBs b25nIGFzIHRoZXJlIGlzIG1hcmtldCBkZW1hbmQgZm9yIGl0Iiwgd2hpY2gNCnNlZW1zIGEgYml0 IHRvbyBvcGVuLWVuZGVkIGZvciBteSB0YXN0ZS4gICBJIHJlY29tbWVuZCB0aGF0IHdlIHNldCBh IA0KZGF0ZSwgcGVyaGFwcyBhIGNvdXBsZSB5ZWFycyBvdXQsIGFmdGVyIHdoaWNoIHdlICh0aGUg SUVURikgd2lsbCBubyANCmxvbmdlciBwdWJsaXNoIG9yIG1haW50YWluIHN1Y2ggZm9vLXN0YXRl IG1vZHVsZXMuDQoNClRob3VnaHRzPw0KDQpLZW50ICAvLyBhcyBjby1jaGFpcg0KDQoNCj09PT09 IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT09DQoNCkJhcnQsDQoNCkkgdGhpbmsgdGhlIHJlYXNvbiBm b3IgdGhlIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgaW50ZXJmYWNlcyBtb2RlbCB3YXMNCnB1Ymxp c2hlZCBhcyBhbiBSRkMgYmVmb3JlIHdoaWxlIHRoZSBoYXJkd2FyZSBtb2RlbCBpcyBuZXcgYW5k IGhlbmNlDQppdCBzZWVtcyB0byBsb29rIGEgYml0IG9kZCB0byBkZWZpbmUgbmV3IGRlcHJlY2F0 ZWQgb2JqZWN0cy4NCg0KSWYgdGhlc2UgZGVwcmVjYXRlZCBvYmplY3RzIGFyZSBlc3NlbnRpYWwg Zm9yIEJCRiAocGxlYXNlIGNvbmZpcm0pLA0KdGhlbiBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gZGVm aW5lIHRoZW0gaW4gYSBzZXBhcmF0ZSBtb2R1bGUgdGhhdCB0aGVuDQpjYW4gc2lsZW50bHkgZGll IHdoaWxlIHN5c3RlbXMgbW92ZSB0byBOTURBIChhbmQgc28gd2UgZG8gbm90IGhhdmUgdGhlDQpk ZXByZWNhdGVkIG9iamVjdHMgd2l0aCB1cyBpbiB0aGUgaGFyZHdhcmUgbW9kdWxlIGZvcmV2ZXIg LSBvciBhdA0KbGVhc3QgYXMgbG9uZyBhcyB3ZSB1c2UgWUFORyAxLjEpLg0KDQovanMNCg0KT24g VHVlLCBEZWMgMDUsIDIwMTcgYXQgMDI6MzU6MjlQTSArMDAwMCwgQm9nYWVydCwgQmFydCAoTm9r aWEgLSBCRS9BbnR3ZXJwKSB3cm90ZToNCj4gSGVsbG8sDQo+IA0KPiBUaGUgbGF0ZXN0IGRyYWZ0 IGRvZXMgbm90IGNvbnRhaW4gYW4gYXBwZW5kaXggd2l0aCB0aGUgZGVwcmVjYXRlZCBzdGF0ZSB0 cmVlDQo+ICh0byBzdXBwb3J0IHRoZSBub24tTk1EQSBtb2RlbCBhcyBzcGVjaWZpZWQgaW4gUkZD NjA4N2JpcyBzZWN0aW9uIDQuMjMuMyksDQo+IHNvIGlmIGl0IGlzIHB1Ymxpc2hlZCBpbiB0aGlz IHdheSwgdGhlcmUgaXMgYW4gaXNzdWUgYXQgdGhlIGxldmVsIG9mIEJCRg0KPiBUUi0zODMuDQo+ IA0KPiBOb3RlIHRoYXQgdGhlIGRyYWZ0LWlldGZuZXRtb2QtcmZjNzIyM2JpcyBkb2VzIGluY2x1 ZGUgdGhlIGRlcHJlY2F0ZWQNCj4gY29udGFpbmVyIGludGVyZmFjZXMtc3RhdGUuDQo+IA0KPiBC ZXN0IHJlZ2FyZHMsDQo+IEJhcnQgQm9nYWVydA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIw MTcgNjozNiBQTQ0KPiBUbzogTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+DQo+IENjOiBOZXRN b2QgV0cgQ2hhaXJzIDxuZXRtb2QtY2hhaXJzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbbmV0bW9k XSBXRyBMYXN0IENhbGw6IGRyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS0wNQ0KPiANCj4gQWxsLA0K PiANCj4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0K PiBkcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHktMDUuDQo+IA0KPiBUaGUgd29ya2luZyBncm91cCBs YXN0IGNhbGwgZW5kcyBvbiBEZWNlbWJlciAxMy4NCj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCj4gDQo+IFBvc2l0aXZlIGNvbW1lbnRzLCBl LmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzDQo+IHJl YWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KPiBUaGlzIGlzIHVzZWZ1bCBhbmQg aW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCj4gDQo+IFRoYW5rIHlvdSwNCj4gTmV0bW9k IENoYWlycw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZo MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh R1R2aklTbGFKZGNabyZtPWNoTFZLd2FBY2RDNkxsa284U2FnR1RkdGFMVlRNSlJWdUZ4eC1NYlh2 UVUmcz0xc3hHY1ZVOU9NYnBqVE1Oa2VfcjhDa0xHblNuTmhyd1hsMWFxQWlxZElzJmU9DQoNCg0K DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5l dG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5k YjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj Wm8mbT1jaExWS3dhQWNkQzZMbGtvOFNhZ0dUZHRhTFZUTUpSVnVGeHgtTWJYdlFVJnM9MXN4R2NW VTlPTWJwalRNTmtlX3I4Q2tMR25Tbk5ocndYbDFhcUFpcWRJcyZlPQ0KDQoNCi0tIA0KSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuamFjb2JzLTJE dW5pdmVyc2l0eS5kZV8mZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRi M3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa byZtPWNoTFZLd2FBY2RDNkxsa284U2FnR1RkdGFMVlRNSlJWdUZ4eC1NYlh2UVUmcz00Q0I3YkQ1 dXR5WDZjNHlBRXlIWmJwMWg3bkhyeEZBUWRyUzJjLXFsbDZNJmU9Pg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0K bmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNB ZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhu SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Y2hMVkt3YUFjZEM2TGxrbzhT YWdHVGR0YUxWVE1KUlZ1Rnh4LU1iWHZRVSZzPTFzeEdjVlU5T01icGpUTU5rZV9yOENrTEduU25O aHJ3WGwxYXFBaXFkSXMmZT0NCg0KDQo= From nobody Thu Dec 7 12:19:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325491294E0 for ; Thu, 7 Dec 2017 12:19:36 -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, 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 ktzQ5DT_3kRt for ; Thu, 7 Dec 2017 12:19:34 -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 4BC6C12948F for ; Thu, 7 Dec 2017 12:19:34 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB7KGU2m009983 for ; Thu, 7 Dec 2017 12:19:33 -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=CAw4M3Fg/rdbCacJbyEqgFO2H366Fvt4Y8aL2xqGmcI=; b=pWUBIeTBS97UJPylCi1AGqNWtG6hoUzgh05aVy0jM8QZ5aO1rmEyvtX2QOsR6e/s+1bI d1smufCnmqVzckvQFuMEMPVVPZ6p2ikgSLwbMWFOUfLuvgYAqHOcQU+Pvn1sFbsJB572 CxD4tgzdtG/HYRdnPNBjtCvocMahMgx6JhO3c5IJi/pX2hR+8y3wbRNX84aF883WqW// IioCFRPOy8UGiV7/WLZwoVwE/qwZqRhjZ06UKDKlYs6CJRw/n3Qvcuy39OjVRVms5tyk pZbjfERAUuzvRm7Xjeur8zyeb7oPSOsKY1EUM9zhXa6jZOB3cNJJL/2rCCeKyz6QbOKn Ig== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0175.outbound.protection.outlook.com [216.32.181.175]) by mx0b-00273201.pphosted.com with ESMTP id 2eqcfn00ug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 07 Dec 2017 12:19:32 -0800 Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Thu, 7 Dec 2017 20:19:30 +0000 Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::38c7:9ea8:b320:1eb]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::38c7:9ea8:b320:1eb%14]) with mapi id 15.20.0302.010; Thu, 7 Dec 2017 20:19:30 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: referencing the tree-diagrams draft Thread-Index: AQHTb5iwyyNfFQtM5UimioeWnsDeDA== Date: Thu, 7 Dec 2017 20:19:30 +0000 Message-ID: <8999577A-227E-4F59-A4C4-23AED7AD8576@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; BN1PR05MB280; 6:wn34hfAX6G735hu0snWHic4At5jYXN5mCc7pQY78rdGDbsf1mW1WP6cKbtVFaYr0G1jJVs/A7OozekmQUejXvlWHkM7rcWM6VUYxK1eVfQRfvPzIitF9kO/uphoY4o1A6QT1gkscKujXx3VUfKFPb83tx8JR75AYyCl9HIZg7ww0dUGo4Mq3048MijRE+Fk8wLjpCfbao7z3Is6OBwwNR0LdXvCR0tnqbhXM2vD18Dokntrb72COSZlhQLyoXKwTmmhilhT7q4FgvaBZIl6pMJYvdY8EKVQCbuae0SAkhCkVbtbkkjGOie7wpaFooTr3gfC/I9vyNHhV2am5E6bT96czrShaXCWan4iGX+IGfmM=; 5:RwjOVlkCchrZ+iVndodqA4gkqqys4FvkmdB0mr5Kfyjo9+VSPxHGkggOaYVuCLQx7fedQEDemHCRe+qZejnP8CB6p5zEHy1XlzzIuT5KxjQi9NnzwL+k6P6hexPZ08bXoxdxpNUeoZQ5z28XtPfsQeLxyCJr09dKRPqATVEDhl0=; 24:I8hOIXLxTGQ1EXKxkLCEZZbPqNT748ZwaAyD5YLNca9flVomSWUq+zli5Hv9shFSL8JSN5w3ykRcurbhoTy0tnTc4Ib7akptja91Z8DfItI=; 7:dQhD/4VzDWfAJUk/Urgm1j6JpsQLDeM4lqaD2sCZ225ymRFiVXtOa1HpcMm5Tm7/Al4UtdOlfowrzIl3fzgKE8LCHNQ8w2B3KG/YCfYg9E3K/Qpflft/HudwaziDzUIPsHS5ypfQ095SmgYSIZLJfKoqoejxlw5hU/BDPOVSBWNTKBuSx12rMr0/FymUDhe4Syxb469bI0rLet0MxWabc3Mh7uZIIbp26LdyJ5xOT9jixFYK5pTV7kqE1xi2pbvb x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c188471c-f868-47d0-f0b3-08d53dafd2e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603286); SRVR:BN1PR05MB280; x-ms-traffictypediagnostic: BN1PR05MB280: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:BN1PR05MB280; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN1PR05MB280; x-forefront-prvs: 05143A8241 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(199004)(189003)(81166006)(1730700003)(86362001)(106356001)(8676002)(81156014)(6512007)(6306002)(33656002)(101416001)(66066001)(7736002)(2351001)(53936002)(305945005)(36756003)(99286004)(83506002)(2900100001)(68736007)(5250100002)(105586002)(5640700003)(6486002)(6506006)(6436002)(8936002)(3480700004)(3280700002)(966005)(478600001)(6116002)(83716003)(25786009)(3660700001)(14454004)(3846002)(102836003)(2501003)(316002)(97736004)(2906002)(58126008)(82746002)(6916009)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB280; H:BN1PR05MB280.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <74A9D4CDF808694EA8B4866291B3995A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c188471c-f868-47d0-f0b3-08d53dafd2e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 20:19:30.7980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB280 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-07_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=924 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712070297 Archived-At: Subject: [netmod] referencing the tree-diagrams draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2017 20:19:36 -0000 DQpBbGwsDQoNCkxvb2tpbmcgYXQgYSBmZXcgZHJhZnRzIGdvaW5nIHRocm91Z2ggbGFzdCBjYWxs IGN1cnJlbnRseSwgSSBub3RpY2UgdGhhdCB0aGV5IGFsbCBkZWZpbmUgdGhlaXIgb3duICJUcmVl IERpYWdyYW1zIiBzZWN0aW9uIHJhdGhlciB0aGFuIHJlZmVyZW5jZSB0aGUgdHJlZS1kaWFncmFt cyBkcmFmdDoNCg0KICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRt b2QtZW50aXR5LTA1I3NlY3Rpb24tMS4xLjENCiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyNzdiaXMtMDAjc2VjdGlvbi0xLjMNCiAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMtMDAjc2VjdGlv bi0xLjMNCg0KSSByZWFsaXplIHRoYXQgdGhlIHRyZWUtZGlhZ3JhbXMgZHJhZnQgaXNuJ3QgcHVi bGlzaGVkIHlldCwgYnV0IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdHMgTGFzdCBDYWxsIGlz IGltbWluZW50LiAgV2l0aCB0aGF0IGluIG1pbmQsICpzaG91bGQqIHRoZXNlIHRocmVlIGRyYWZ0 cyAoYW5kLCBieSBleHRlbnNpb24sIGFsbCBkcmFmdHMgZ29pbmcgZm9yd2FyZCkgYmUgdXBkYXRl ZCB0byByZWZlcmVuY2UgdGhlIHRyZWUtZGlhZ3JhbXMgZHJhZnQ/ICAtIG9yIGFyZSB3ZSBjdXJy ZW50bHkgaW4gYSBncmV5IGFyZWEgd2hlcmUgaXQncyBhICJtYXkiIHVudGlsIHRoZSB0cmVlLWRp YWdyYW1zIGRyYWZ0IGlzIHB1Ymxpc2hlZCwgYXQgd2hpY2ggdGltZSBpdCBiZWNvbWVzIGEgIm11 c3QiPw0KDQpLZW50ICAvLyBjby1jaGFpcg0KDQoNCg0K From nobody Thu Dec 7 12:38:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1A2126CC4 for ; Thu, 7 Dec 2017 12:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, 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 GmWx6QWUY9CU for ; Thu, 7 Dec 2017 12:38:57 -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 05328124B09 for ; Thu, 7 Dec 2017 12:38:57 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id D57771E0D88 for ; Thu, 7 Dec 2017 13:38:55 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id j8es1w00F2SSUrH018evPh; Thu, 07 Dec 2017 13:38:55 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=Jovm65r4E1pkkVwkgUsA: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: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=PZDwD6reSCmNhx84pgsWj/NsXsu9wIt3vJQxwX+ehhE=; b=2XzfMAwmsfAzLmniM4va6Mp/z0 sQ1Mk1ccARJp0upgjH3p8XTB8WAoxtoaiRT/Fv/U9CGxU4kjaSKWbnKQqeI0b8vdK/jWOSgjkQAqI V7Id4sqJcx/AH1oxj+tC/qVU4; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:42822 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eN2wW-0021AJ-5z; Thu, 07 Dec 2017 13:38:52 -0700 To: Kent Watsen , "netmod@ietf.org" References: <8999577A-227E-4F59-A4C4-23AED7AD8576@juniper.net> From: Lou Berger Message-ID: <04d3a2fa-ee5b-0d8a-3b0c-32786de7ecd0@labn.net> Date: Thu, 7 Dec 2017 15:38:49 -0500 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: <8999577A-227E-4F59-A4C4-23AED7AD8576@juniper.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: 1eN2wW-0021AJ-5z 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]:42822 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] referencing the tree-diagrams draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2017 20:38:59 -0000 Kent, On 12/7/2017 3:19 PM, Kent Watsen wrote: > All, > > Looking at a few drafts going through last call currently, I notice that they all define their own "Tree Diagrams" section rather than reference the tree-diagrams draft: > > https://tools.ietf.org/html/draft-ietf-netmod-entity-05#section-1.1.1 > https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-00#section-1.3 > https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00#section-1.3 > > I realize that the tree-diagrams draft isn't published yet, but my understanding is that its Last Call is imminent. With that in mind, *should* these three drafts (and, by extension, all drafts going forward) be updated to reference the tree-diagrams draft? - or are we currently in a grey area where it's a "may" until the tree-diagrams draft is published, at which time it becomes a "must"? I think we're close enough to risk the MISREF state, ie.e., I think the drafts should point to tree diagrams. Lou (Co-author and co-chair...) > Kent // co-chair > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Dec 7 14:13:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA851294F3 for ; Thu, 7 Dec 2017 14:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, 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 PPiEvRCb_G9y for ; Thu, 7 Dec 2017 14:13:28 -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 A067B1294F0 for ; Thu, 7 Dec 2017 14:13:28 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 361AD1E066E for ; Thu, 7 Dec 2017 15:13:28 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id jADQ1w00r2SSUrH01ADTGZ; Thu, 07 Dec 2017 15:13:28 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=3LwNzHvKK53Cd23OwP8A: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=LOPyLkeDuq9Qn3rIiDAszcUVPyfuHxGOh5igDMflPv4=; b=KXw5Y/NvlbpkhFSlxVn0INp6FO 1N1j+l0fvUl66nAc++Ef+aaGGRpkHZDZvZesM3e9srMp4jeItumBePGvqVeXlYmDnaCQv52rtVkLF 9tQgvypSkqcgaWLm0mwgC8hJC; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47242 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eN4Q0-002MUj-8o; Thu, 07 Dec 2017 15:13:24 -0700 To: netmod@ietf.org, Kent Watsen , Benoit Claise , Juergen Schoenwaelder References: <20171115.135818.591114714397486064.mbj@tail-f.com> <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net> <20171117065424.ccnx3dufs7e5abk3@elstar.local> From: Lou Berger Message-ID: <1e71a94a-d07a-0c0b-bc02-56aefdf19329@labn.net> Date: Thu, 7 Dec 2017 17:13:21 -0500 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: <20171117065424.ccnx3dufs7e5abk3@elstar.local> Content-Type: text/plain; charset=utf-8 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: 1eN4Q0-002MUj-8o 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]:47242 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] intended status of the tree diagram document X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2017 22:13:30 -0000 Hi Juergen,     Sorry for the slow response, I missed this message. Circling back to this discussion made me go revisit RFC2026.  Based on all the factors/discussions I agree  that standards track isn't quite right for this document, but I also think informational isn't quite right either.  I do think BCP would as described in RFC2026 fits.  This said, I think it would be good to hear from at least Kent (as Chair) and Benoit (as AD) if they agree/disagree with publishing as a BCP. Kent, Benoit? Thanks, Lou On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote: > Lou, > > right now, the document says standards track, Martin's proposal was to > move to informational. So how do I parse "I think you are correct. We > should leave as is."? > > /js > > On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote: >> Martin, >> I think you are correct. We should leave as is. >> >> I'm sure Kent/the document Shepherd makes sure whatever we do is right >> before publication in any case. >> >> Lou (as contributor) >> >> On 11/15/2017 8:58 PM, Martin Bjorklund wrote: >>> Hi, >>> >>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status >>> Standards Track. I think I heard during the meeting today that it >>> ought to be Informational. I think this makes sense. It would then >>> imply that other standards track documents will have the tree diagram >>> document as an informative reference. >>> >>> Should we make this change? >>> >>> >>> /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 Thu Dec 7 15:38:27 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E655127869 for ; Thu, 7 Dec 2017 15:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 n1UyQ--My66M for ; Thu, 7 Dec 2017 15:38:23 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 EF00C127BA3 for ; Thu, 7 Dec 2017 15:38:21 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 6F83D215DBD for ; Thu, 7 Dec 2017 16:38:21 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id jBeH1w00P2SSUrH01BeL2C; Thu, 07 Dec 2017 16:38:21 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=AUd_NHdVAAAA:8 a=pGLkceISAAAA:8 a=vkzq32B2xekbnaBgMs4A: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: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=wtTZo+zbwJIaMl+VZUcDd0PB6Rcjy/MjES+m50Krf+4=; b=Zb4yp71MTINyd/SowMM0i80T+c Q7YQiDdgTTsVoEZwKdVt+R/uUi3Sv282r89+PrR+7jmQlFf5UbEthZSpiVneoBMWLXz+V+CJLR9i0 hHJbfBYRlGIpZsn1ENyJL62v3; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52124 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eN5k9-002eUW-8Q; Thu, 07 Dec 2017 16:38:17 -0700 To: Mehmet Ersue , 'Mahesh Jethanandani' , 'Robert Wilton' , netmod@ietf.org, Andy Bierman References: <20171115.101454.1576716701146734257.mbj@tail-f.com> <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net> <20171117070043.pm7rn25yj3hxum3q@elstar.local> From: Lou Berger Message-ID: <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> Date: Thu, 7 Dec 2017 18:38:14 -0500 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: <20171117070043.pm7rn25yj3hxum3q@elstar.local> Content-Type: text/plain; charset=utf-8 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: 1eN5k9-002eUW-8Q 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]:52124 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] tree diagram guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2017 23:38:26 -0000 Hi, Following up on this discussion (and hoping to wrap it up): I have created two  wikis off of https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis content and the other for section 3 of tree diagrams.  I also propose the following changes to the tree-diagrams draft: To section 3 intro, add:     For the most current quidelines being developed, please see the IETF NetMod Working    Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart Add :   3.2.  Groupings    If the YANG module is comprised of groupings only, then the tree    diagram should contain the groupings.  The 'pyang' compiler can be    used to produce a tree diagram with groupings using the "-f tree --    tree-print-groupings" command line parameters. And to section 3.3, start with:    Tree diagrams can be split into sections to correspond to document    structure. For 6087 bis, I think section 3.4 gets replaced with something like.     YANG tree diagrams provide a concise representation of a YANG module,    and SHOULD be included to help readers understand YANG module     structure.  Guidelines on tree diagrams can be found in Section 3 of     [I-D.ietf-netmod-yang-tree-diagrams]. These changes can be found at: https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c285758eb5aaaf02cf980269afff This leaves the intended status as the key open issue on the draft. Lou On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote: > I am confused. I think there was some consensus to > > - include all tree related guidelines in the tree document, remove all tree > related guidelines from 6087bis and have 6087bis point to the tree document > (which it already does) > > The rest is pointless since AFAIK there is no wiki guidelines pages to > point to and there is AFAIK nobody in place to actually maintain such > a wiki page. Perhaps a wiki is the future but until future has > arrived, we should not point to it. > > The other proposal I heard was to have a landing page that points to > the current guideline work which points to the relevant documents. A > wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not > affect the documents. > > /js > > PS: I am happy to add pointers to guidelines as a section to the > wikipedia page. > > On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote: >> To circle back to this. My sense of this discussion (as contributor) is >> (a) the tree diagrams draft should be updated to point to a "guidelines" >> wiki page for "the most current guidelines" >> (b) the tree diagrams draft should be updated to include a full set of the >> current tree related guidelines >> (c) 6087bis should be updated to point to a "guidelines" wiki page for "the >> most current guidelines" >> (d) 6087bis should have it's tree guidelines point to the tree diagrams >> document -- in addition to pointing to the wiki >> >> Does this sound right? >> >> Lou >> (as tree co-author) >> >> On 11/16/2017 11:04 AM, Mehmet Ersue wrote: >>> The Wiki is useful as a starting point providing a collection of pointers to guideline RFCs and the bis-revisions in development. >>> >>> Cheers, >>> Mehmet >>> >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh >>>> Jethanandani >>>> Sent: Thursday, November 16, 2017 7:39 AM >>>> To: Robert Wilton >>>> Cc: netmod@ietf.org >>>> Subject: Re: [netmod] tree diagram guidelines >>>> >>>> Other SDOs can and follow the work in IETF through the RFCs we publish. >>>> They do not follow wiki’s, unless the document itself says, “here are the >>>> guidelines, but if you are looking for the latest, go to this wiki”. I therefore >>>> would support the proposal outlined below. It gives the SDO a stable point of >>>> reference with a document, which gets updated occasionally, but also allows >>>> them to peak at what is coming down the pipeline. >>>> >>>> Thanks. >>>> >>>>> On Nov 15, 2017, at 6:53 PM, Robert Wilton wrote: >>>>> >>>>> I liked the suggestion from Chris Hopps: >>>>> >>>>> I think that it was along the lines of ... >>>>> >>>>> The RFC contains a reference at the top that states that updates to the >>>> guidelines is available on a wiki at .... >>>>> Every few years the guidelines on the wiki can be folded into a latest >>>> version of the guidelines draft. >>>>> 6087bis looks to be 3.5 years old. Should folks, e.g. at BBF,, IEEE, or MEF be >>>> using the latest draft guidelines, or should then use the published RFC until >>>> 6087bis is actually republshed? >>>>> Thanks, >>>>> Rob >>>>> >>>>> >>>>> On 15/11/2017 10:14, Martin Bjorklund wrote: >>>>>> Hi, >>>>>> >>>>>> There was a proposal in the meeting today to have the guidelines for >>>>>> tree diagrams in a wiki, instead of having them in 6087bis or in the >>>>>> tree diagram document. >>>>>> >>>>>> Was the proposal really to have a wiki for just the tree guidelines, >>>>>> or was the proposal to withdraw 6087bis from the process and instead >>>>>> publish all guidelines as a wiki? >>>>>> >>>>>> If it is the former, is it really worth it? >>>>>> >>>>>> Advantages with a wiki: >>>>>> >>>>>> + It can be updated more easily >>>>>> >>>>>> Some drawbacks: >>>>>> >>>>>> - It can be updated more easily >>>>>> (meaning they are less stable) >>>>>> >>>>>> - Wikis tend to not be alive after some time, and are not that >>>>>> easy to find. Just try to find the various YANG-related wikis >>>>>> we've tried to maintain over the years. >>>>>> >>>>>> - Links in RFCs also have problems. Sites are re-orginized etc. >>>>>> As an example, the link to the security guidelines template in >>>>>> RFC 6087 doesn't work anymore. >>>>>> >>>>>> - People that are looking for a stable reference will have problems >>>>>> (I think Rob mentioned that IEEE still refer to RFC 6087 (which >>>>>> is understandable; that's the published version). >>>>>> >>>>>> - Who maintains the Wiki, and what are the rules for updating it? >>>>>> >>>>>> >>>>>> I suggest we have the tree-related guidelines (actually just a few >>>>>> sentences) in the tree draft, and since 6087bis already refers to >>>>>> this document it is not a big problem that guidelines are spread out >>>>>> over several documents that are difficult to find. >>>>>> >>>>>> >>>>>> >>>>>> /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 >>>> 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 list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Dec 7 16:06:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED59127B73 for ; Thu, 7 Dec 2017 16:06:01 -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, 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 HFzn-SnVNh69 for ; Thu, 7 Dec 2017 16:05:59 -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 09229128768 for ; Thu, 7 Dec 2017 16:05:59 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB804oLq010180; Thu, 7 Dec 2017 16:05:56 -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=yRGHJAXdix2h+NpvRg+VgZfFRIHuoabotXNwqpiSJVo=; b=I7IBP91SiEpwk4AGCSnSGBP7OLi7lFyKkDsLHYaOHZ3gE0lNY1Pd0mukVDJ/u7/xW7sA LXR+NAXZMMS0F4naQAJXIN9PSAdJj0ic6v3B14ZE/lzk/a76xe66igh0ZZfstTuo6d0L MwGiGrxdjh1zs3VJTlWD5I3U+jpmUqP/d+oB276xOYB7GfmEQ3+4oQ685WPzfMcOEmv7 xNcRt/n5cW22ar/j1r7UC/AC/ucrpOztw/aTqJYAgcY9WhRrozleIABLec3BozdFBMtL k0Km2u0CN6jgRUduqf+b6oiaYPMh1eD/UTeQXuHD8KM5oJFuTJdS+hENa3jVoll4EgFq 0g== 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 2eqfty8099-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Dec 2017 16:05:56 -0800 Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Fri, 8 Dec 2017 00:05:53 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0323.004; Fri, 8 Dec 2017 00:05:53 +0000 From: Kent Watsen To: Lou Berger , "netmod@ietf.org" , "Benoit Claise" , Juergen Schoenwaelder Thread-Topic: [netmod] intended status of the tree diagram document Thread-Index: AQHTXhFt5pV/jz+PLk+uMh30thjRIKMXq3MAgAB6OACAIG9hgP//y54A Date: Fri, 8 Dec 2017 00:05:53 +0000 Message-ID: <296B481E-20A5-4362-AE5C-174481FEDFA4@juniper.net> References: <20171115.135818.591114714397486064.mbj@tail-f.com> <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net> <20171117065424.ccnx3dufs7e5abk3@elstar.local> <1e71a94a-d07a-0c0b-bc02-56aefdf19329@labn.net> In-Reply-To: <1e71a94a-d07a-0c0b-bc02-56aefdf19329@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.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:4F+SNNHFG5CF5CbAV17U8h0638rfVgNyvjoVfDxf7G4d+JigQo+x0klqptVsr55xRmnPFqCxibbbx/F8ROxSz1QNQTAw7e1vqpbwDcQU5/O21dftk9k+wGwqXHAfkeQ/DG6RD62GL+ZnN3ndx61eqoy7Sq/BYvOW/Gjm53lcxX4SVtoqim6Wb+06TPBUMdFKo3DE2i8F+2phoNdb12imgaCXCPRRPSNjMcxgsxfhgM2hjzr7J34TA2EwQmYt6AXjEWpaIxNHZiFYLUG38fco8BahN3ow2oWNVOuixF7hxIicVlKFK4bhgEN7ssC7Qfp9hcKwIRep29yGkSf+jImDU2YjBwwjhryzRf3uSzbKQ7U=; 5:P8xaWxCuvMYCuqsfS984cHy4S8wVmeHUnMY03RquJIzS6ANqOt9JEh7QiLGhX6Mtktre+Haw/JCk0wjK1RzAwOXuqavhImK7X+jmFH4bX4g910VsRdloy3oMD4x0T/nuIWoMp+5ERP2Ws/ue1nVL7O1ovlEj36cUU3pv3qcF7vA=; 24:GaFAxcbi133iX4vCNIqlQC1yQi3KupgeydtVTJiwLDZNfRU1+MkcbOfCKU3rDzLoqDa4RwAmoPIUDKroZgNE4J4bAP6OQj6kSlv5reLhYpI=; 7:uh7Ze68adRDAmRbsF7HuSmkUG+x6rUwVGwfb7x8iHrJnrNHm43nkJaJIJ3BidjhUK21V7b8hEaGNluYffYT5v/BcUdl+wmFrwTa7gtpfGzgz+D5zbO6dDbD1nXoMUhnCoETVe1pGmULoq0LYiBkRz09L64ncLdkkpnmx7QPQkqObcAeMNZQfIzROrlmb3Ib3ejBVb+pSsokRz3MNWtLhNbdbBNew62fWrzgB3MbsjKNB89jLJD8PHUUzp8grgrSE x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dd2fa4cb-c042-49ef-d9f5-08d53dcf72e4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307); SRVR:BLUPR05MB275; x-ms-traffictypediagnostic: BLUPR05MB275: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231022)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB275; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(346002)(199004)(189003)(24454002)(6306002)(6512007)(2900100001)(53936002)(478600001)(4326008)(7736002)(66066001)(58126008)(110136005)(76176011)(97736004)(93886005)(3280700002)(53546010)(6246003)(2501003)(305945005)(102836003)(2906002)(83716003)(316002)(3660700001)(6116002)(3846002)(8936002)(68736007)(14454004)(81166006)(966005)(575784001)(86362001)(8676002)(77096006)(82746002)(2950100002)(561944003)(25786009)(229853002)(6436002)(33656002)(5660300001)(6486002)(6506006)(99286004)(36756003)(83506002)(105586002)(106356001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.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) 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: dd2fa4cb-c042-49ef-d9f5-08d53dcf72e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 00:05:53.6512 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-07_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=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-1712070352 Archived-At: Subject: Re: [netmod] intended status of the tree diagram document X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 00:06:01 -0000 DQpCQ1AgZm9yIHRyZWUtZGlhZ3JhbXM/ICAgVGhpcyBkb2Vzbid0IHNlZW0gbGlrZSBhbiBhcHBy b3ByaWF0ZSBhcHBsaWNhdGlvbiBvZiB0aGF0IGRlc2lnbmF0aW9uLiAgSSBkb24ndCB2aWV3IHRo ZSBmb3JtYXQgZm9yIHRyZWUgZGlhZ3JhbXMgdG8gYmUgYSAicHJhY3RpY2UiLCB3aGVyZWFzIGl0 IGRlZmluaXRlbHkgc2VlbXMgImluZm9ybWF0aW9uYWwiLg0KDQpMb29raW5nIG1vcmUgZGVlcGx5 IGF0IFJGQzIwMjYsIEkgY2FuIHNlZSBob3cgU2VjdGlvbidzIDQuMi4yJ3MgIi4uLmRvZXMgbm90 IHJlcHJlc2VudCBhbiBJbnRlcm5ldCBjb21tdW5pdHkgY29uc2Vuc3VzIG9yIHJlY29tbWVuZGF0 aW9uIiBjb3VsZCBiZSBjYXVzZSBmb3Igb2JqZWN0aW9uLCBzaW5jZSB0aGlzIGRyYWZ0IGlzIG9i dmlvdXNseSBnb2luZyB0aHJvdWdoIGEgV0cgKE5FVE1PRCkgYW5kIHRoZXJlZm9yZSBkb2VzLCBp biBmYWN0LCByZXByZXNlbnQgc29tZSBmb3JtIG9mIGNvbnNlbnN1cywgYnV0IEknbSB3aWxsaW5n IHRvIGdsb3NzIG92ZXIgdGhhdCBsaW5lIGFzLCBjbGVhcmx5LCBtYW55IEluZm9ybWF0aW9uYWwg UkZDcyBhcmUgcHVibGlzaGVkIGJ5IFdHcywgd2hpY2ggd291bGRuJ3QgYmUgcG9zc2libGUgaWYg dGhhdCBsaW5lIHdlcmUgdGFrZW4gbGl0ZXJhbGx5LiAgUGVyaGFwcyB3ZSBzaG91bGQgZmlsZSBF cnJhdGEgYWdhaW5zdCBpdD8NCg0KS2VudCAvLyBjby1jaGFpcg0KDQoNCj09PT09IG9yaWdpbmFs IG1lc3NhZ2UgPT09PT0NCg0KSGkgSnVlcmdlbiwNCg0KICAgIFNvcnJ5IGZvciB0aGUgc2xvdyBy ZXNwb25zZSwgSSBtaXNzZWQgdGhpcyBtZXNzYWdlLg0KDQpDaXJjbGluZyBiYWNrIHRvIHRoaXMg ZGlzY3Vzc2lvbiBtYWRlIG1lIGdvIHJldmlzaXQgUkZDMjAyNi4gIEJhc2VkIG9uDQphbGwgdGhl IGZhY3RvcnMvZGlzY3Vzc2lvbnMgSSBhZ3JlZSAgdGhhdCBzdGFuZGFyZHMgdHJhY2sgaXNuJ3Qg cXVpdGUNCnJpZ2h0IGZvciB0aGlzIGRvY3VtZW50LCBidXQgSSBhbHNvIHRoaW5rIGluZm9ybWF0 aW9uYWwgaXNuJ3QgcXVpdGUNCnJpZ2h0IGVpdGhlci4gIEkgZG8gdGhpbmsgQkNQIHdvdWxkIGFz IGRlc2NyaWJlZCBpbiBSRkMyMDI2IGZpdHMuICBUaGlzDQpzYWlkLCBJIHRoaW5rIGl0IHdvdWxk IGJlIGdvb2QgdG8gaGVhciBmcm9tIGF0IGxlYXN0IEtlbnQgKGFzIENoYWlyKSBhbmQNCkJlbm9p dCAoYXMgQUQpIGlmIHRoZXkgYWdyZWUvZGlzYWdyZWUgd2l0aCBwdWJsaXNoaW5nIGFzIGEgQkNQ Lg0KDQpLZW50LCBCZW5vaXQ/DQoNClRoYW5rcywNCg0KTG91DQoNCk9uIDExLzE3LzIwMTcgMTo1 NCBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOg0KPiBMb3UsDQo+DQo+IHJpZ2h0IG5v dywgdGhlIGRvY3VtZW50IHNheXMgc3RhbmRhcmRzIHRyYWNrLCBNYXJ0aW4ncyBwcm9wb3NhbCB3 YXMgdG8NCj4gbW92ZSB0byBpbmZvcm1hdGlvbmFsLiBTbyBob3cgZG8gSSBwYXJzZSAiSSB0aGlu ayB5b3UgYXJlIGNvcnJlY3QuICBXZQ0KPiBzaG91bGQgbGVhdmUgYXMgaXMuIj8NCj4NCj4gL2pz DQo+DQo+IE9uIEZyaSwgTm92IDE3LCAyMDE3IGF0IDA3OjM2OjU4QU0gKzA4MDAsIExvdSBCZXJn ZXIgd3JvdGU6DQo+PiBNYXJ0aW4sDQo+PiAJSSB0aGluayB5b3UgYXJlIGNvcnJlY3QuICBXZSBz aG91bGQgbGVhdmUgYXMgaXMuDQo+Pg0KPj4gSSdtIHN1cmUgS2VudC90aGUgZG9jdW1lbnQgU2hl cGhlcmQgbWFrZXMgc3VyZSB3aGF0ZXZlciB3ZSBkbyBpcyByaWdodA0KPj4gYmVmb3JlIHB1Ymxp Y2F0aW9uIGluIGFueSBjYXNlLg0KPj4NCj4+IExvdSAoYXMgY29udHJpYnV0b3IpDQo+Pg0KPj4g T24gMTEvMTUvMjAxNyA4OjU4IFBNLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPj4+IEhpLA0K Pj4+DQo+Pj4gQ3VycmVudGx5LCBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMg aGFzIGludGVuZGVkIHN0YXR1cw0KPj4+IFN0YW5kYXJkcyBUcmFjay4gIEkgdGhpbmsgSSBoZWFy ZCBkdXJpbmcgdGhlIG1lZXRpbmcgdG9kYXkgdGhhdCBpdA0KPj4+IG91Z2h0IHRvIGJlIEluZm9y bWF0aW9uYWwuICBJIHRoaW5rIHRoaXMgbWFrZXMgc2Vuc2UuICBJdCB3b3VsZCB0aGVuDQo+Pj4g aW1wbHkgdGhhdCBvdGhlciBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnRzIHdpbGwgaGF2ZSB0aGUg dHJlZSBkaWFncmFtDQo+Pj4gZG9jdW1lbnQgYXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlLg0K Pj4+DQo+Pj4gU2hvdWxkIHdlIG1ha2UgdGhpcyBjaGFuZ2U/DQo+Pj4NCj4+Pg0KPj4+IC9tYXJ0 aW4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJRGFRJmM9SEFrWXVoNjNyc3VocjZT Y2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJn c0JZYUdUdmpJU2xhSmRjWm8mbT0zQkNOcHZvdW1UQS00eWpENW4wNENTRlBVczJqTEFsTm9qNU9J b09YRGtVJnM9UGk2Rzl1enZGUnBVTmtnYVphMnRSUjA3c1A3YnlFc2tvbm9WRGV5WWNRRSZlPQ0K Pj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpC WGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZq SVNsYUpkY1pvJm09M0JDTnB2b3VtVEEtNHlqRDVuMDRDU0ZQVXMyakxBbE5vajVPSW9PWERrVSZz PVBpNkc5dXp2RlJwVU5rZ2FaYTJ0UlIwN3NQN2J5RXNrb25vVkRleVljUUUmZT0NCg0KDQoNCg== From nobody Thu Dec 7 17:04:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA7F12762F for ; Thu, 7 Dec 2017 17:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 bjtRKDlbpikF for ; Thu, 7 Dec 2017 17:04:42 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 76C43129469 for ; Thu, 7 Dec 2017 17:04:42 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id A034214055F for ; Thu, 7 Dec 2017 18:04:39 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id jD4b1w01C2SSUrH01D4eQW; Thu, 07 Dec 2017 18:04:39 -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=ocR9PWop10UA:10 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=RpNjiQI2AAAA:8 a=Pqp8BeiR7iknUlgWmr4A:9 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=CjuIK1q_8ugA:10 a=cAcMbU7R10T-QSRYIcO_:22 a=w1C3t2QeGrPiZgrLijVG:22 a=vJuR_VyAocOa-HWBgGQO: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=PsfdXHbjWtPzc6Q/MBPOtdCJLimfloTbndFDTUoN4/Y=; b=Qp18ZNrshaGtcdSVbDKqz94jYc 2pkZIRc18E1q+vOtGAv5YEV6swj1DwZsYFyz/bxGemEegFzkVWQ4ghVRdbtU17LGjbrwd9wEnuhDP 9Gu3nhS/fyyE5rTYLsi78mVvt; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:51101 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 1eN75f-002xiY-NX; Thu, 07 Dec 2017 18:04:35 -0700 From: Lou Berger To: Kent Watsen , , Benoit Claise , Juergen Schoenwaelder Date: Thu, 07 Dec 2017 20:04:33 -0500 Message-ID: <16033a708e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <296B481E-20A5-4362-AE5C-174481FEDFA4@juniper.net> References: <20171115.135818.591114714397486064.mbj@tail-f.com> <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net> <20171117065424.ccnx3dufs7e5abk3@elstar.local> <1e71a94a-d07a-0c0b-bc02-56aefdf19329@labn.net> <296B481E-20A5-4362-AE5C-174481FEDFA4@juniper.net> User-Agent: AquaMail/1.11.0-568 (build: 101100004) 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: 1eN75f-002xiY-NX 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]:51101 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] intended status of the tree diagram document X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 01:04:44 -0000 Umm, bcp covers process and consensus agreement while informational typically does not*. I also don't see how 6087bis would be a more suited to be a bcp than this document. Lou On December 7, 2017 7:06:35 PM Kent Watsen wrote: > > BCP for tree-diagrams? This doesn't seem like an appropriate application > of that designation. I don't view the format for tree diagrams to be a > "practice", whereas it definitely seems "informational". > > Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does > not represent an Internet community consensus or recommendation" could be > cause for objection, since this draft is obviously going through a WG > (NETMOD) and therefore does, in fact, represent some form of consensus, but > I'm willing to gloss over that line as, clearly, many Informational RFCs > are published by WGs, which wouldn't be possible if that line were taken > literally. Perhaps we should file Errata against it? > > Kent // co-chair > > > ===== original message ===== > > Hi Juergen, > > Sorry for the slow response, I missed this message. > > Circling back to this discussion made me go revisit RFC2026. Based on > all the factors/discussions I agree that standards track isn't quite > right for this document, but I also think informational isn't quite > right either. I do think BCP would as described in RFC2026 fits. This > said, I think it would be good to hear from at least Kent (as Chair) and > Benoit (as AD) if they agree/disagree with publishing as a BCP. > > Kent, Benoit? > > Thanks, > > Lou > > On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote: >> Lou, >> >> right now, the document says standards track, Martin's proposal was to >> move to informational. So how do I parse "I think you are correct. We >> should leave as is."? >> >> /js >> >> On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote: >>> Martin, >>> I think you are correct. We should leave as is. >>> >>> I'm sure Kent/the document Shepherd makes sure whatever we do is right >>> before publication in any case. >>> >>> Lou (as contributor) >>> >>> On 11/15/2017 8:58 PM, Martin Bjorklund wrote: >>>> Hi, >>>> >>>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status >>>> Standards Track. I think I heard during the meeting today that it >>>> ought to be Informational. I think this makes sense. It would then >>>> imply that other standards track documents will have the tree diagram >>>> document as an informative reference. >>>> >>>> Should we make this change? >>>> >>>> >>>> /martin >>>> >>>> _______________________________________________ >>>> 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=3BCNpvoumTA-4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVDeyYcQE&e= >>>> >>> _______________________________________________ >>> 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=3BCNpvoumTA-4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVDeyYcQE&e= > > > From nobody Thu Dec 7 17:05:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE71129501 for ; Thu, 7 Dec 2017 17:05: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 (1024-bit key) header.d=joelhalpern.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 XwDrlde42Qpa for ; Thu, 7 Dec 2017 17:04:53 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 DEB5A12762F for ; Thu, 7 Dec 2017 17:04:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C6EA734008E for ; Thu, 7 Dec 2017 17:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1512695093; bh=WBVu1oDegizaIu2xkT1BFcPF9d7wSIjO0WJGhifOIuQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Z8bLn4fIK7Kt5fQPD/fP0M94YtaadN3WOVTMNo4XCAMrGm5iw85Lo4MfKjZ0p0s6J 6MrU364qNgW9opwjLWSo/7jcylpwXDGR0LJL9/E1vziJg7EbeIjz2vjiogx0YjgSh2 Ut3JyjTlrU65n7Q1oGUN+gclF1XLLmsGiBlVPehk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1C986240C7A for ; Thu, 7 Dec 2017 17:04:52 -0800 (PST) To: netmod@ietf.org References: <20171115.101454.1576716701146734257.mbj@tail-f.com> <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net> <20171117070043.pm7rn25yj3hxum3q@elstar.local> <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> From: "Joel M. Halpern" Message-ID: <1cb63d28-4333-c36a-dbe7-6cc58eaa5a3a@joelhalpern.com> Date: Thu, 7 Dec 2017 20:04:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] tree diagram guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 01:05:01 -0000 I have been watching this discussion of referencing the wiki page from the RFC-to-be about tree diagrams. I must admit that I am confused as to why we would want to do so. For anyone writing a document with a YANG tree, what they are required to do is what is in this RFC. While the wiki page may be interesting, it is not normative. For anyone reading an RFC that uses a Tree diagram (a significantly larger number of people), what they need to know is in the RFC. Reading the wiki not only is not normative, it may well have content that was not even present when the RFC that they are reading was written. In fact, the content of the wiki may contradict what is in the RFC they are reading, without indicating any errors having been made. Which I fear may be confusing to the reader. I understand and support wanting to make it easy for readers to find the wiki of ongoing discussions of YANG tree diagrams (and other issues.) But it seems like this is the wrong way to achieve the goal. Yours, Joel On 12/7/17 6:38 PM, Lou Berger wrote: > Hi, > > Following up on this discussion (and hoping to wrap it up): > > I have created two  wikis off of > https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis > content and the other for section 3 of tree diagrams.  I also propose > the following changes to the tree-diagrams draft: > > To section 3 intro, add: >     For the most current quidelines being developed, please see the IETF > NetMod Working >    Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart > > Add : >   3.2.  Groupings > >    If the YANG module is comprised of groupings only, then the tree >    diagram should contain the groupings.  The 'pyang' compiler can be >    used to produce a tree diagram with groupings using the "-f tree -- >    tree-print-groupings" command line parameters. > > And to section 3.3, start with: > >    Tree diagrams can be split into sections to correspond to document >    structure. > > For 6087 bis, I think section 3.4 gets replaced with something like. > >     YANG tree diagrams provide a concise representation of a YANG module, >    and SHOULD be included to help readers understand YANG module >     structure.  Guidelines on tree diagrams can be found in Section 3 of >     [I-D.ietf-netmod-yang-tree-diagrams]. > > These changes can be found at: > https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c285758eb5aaaf02cf980269afff > > This leaves the intended status as the key open issue on the draft. > > Lou > > > On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote: >> I am confused. I think there was some consensus to >> >> - include all tree related guidelines in the tree document, remove all tree >> related guidelines from 6087bis and have 6087bis point to the tree document >> (which it already does) >> >> The rest is pointless since AFAIK there is no wiki guidelines pages to >> point to and there is AFAIK nobody in place to actually maintain such >> a wiki page. Perhaps a wiki is the future but until future has >> arrived, we should not point to it. >> >> The other proposal I heard was to have a landing page that points to >> the current guideline work which points to the relevant documents. A >> wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not >> affect the documents. >> >> /js >> >> PS: I am happy to add pointers to guidelines as a section to the >> wikipedia page. >> >> On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote: >>> To circle back to this. My sense of this discussion (as contributor) is >>> (a) the tree diagrams draft should be updated to point to a "guidelines" >>> wiki page for "the most current guidelines" >>> (b) the tree diagrams draft should be updated to include a full set of the >>> current tree related guidelines >>> (c) 6087bis should be updated to point to a "guidelines" wiki page for "the >>> most current guidelines" >>> (d) 6087bis should have it's tree guidelines point to the tree diagrams >>> document -- in addition to pointing to the wiki >>> >>> Does this sound right? >>> >>> Lou >>> (as tree co-author) >>> >>> On 11/16/2017 11:04 AM, Mehmet Ersue wrote: >>>> The Wiki is useful as a starting point providing a collection of pointers to guideline RFCs and the bis-revisions in development. >>>> >>>> Cheers, >>>> Mehmet >>>> >>>>> -----Original Message----- >>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh >>>>> Jethanandani >>>>> Sent: Thursday, November 16, 2017 7:39 AM >>>>> To: Robert Wilton >>>>> Cc: netmod@ietf.org >>>>> Subject: Re: [netmod] tree diagram guidelines >>>>> >>>>> Other SDOs can and follow the work in IETF through the RFCs we publish. >>>>> They do not follow wiki’s, unless the document itself says, “here are the >>>>> guidelines, but if you are looking for the latest, go to this wiki”. I therefore >>>>> would support the proposal outlined below. It gives the SDO a stable point of >>>>> reference with a document, which gets updated occasionally, but also allows >>>>> them to peak at what is coming down the pipeline. >>>>> >>>>> Thanks. >>>>> >>>>>> On Nov 15, 2017, at 6:53 PM, Robert Wilton wrote: >>>>>> >>>>>> I liked the suggestion from Chris Hopps: >>>>>> >>>>>> I think that it was along the lines of ... >>>>>> >>>>>> The RFC contains a reference at the top that states that updates to the >>>>> guidelines is available on a wiki at .... >>>>>> Every few years the guidelines on the wiki can be folded into a latest >>>>> version of the guidelines draft. >>>>>> 6087bis looks to be 3.5 years old. Should folks, e.g. at BBF,, IEEE, or MEF be >>>>> using the latest draft guidelines, or should then use the published RFC until >>>>> 6087bis is actually republshed? >>>>>> Thanks, >>>>>> Rob >>>>>> >>>>>> >>>>>> On 15/11/2017 10:14, Martin Bjorklund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> There was a proposal in the meeting today to have the guidelines for >>>>>>> tree diagrams in a wiki, instead of having them in 6087bis or in the >>>>>>> tree diagram document. >>>>>>> >>>>>>> Was the proposal really to have a wiki for just the tree guidelines, >>>>>>> or was the proposal to withdraw 6087bis from the process and instead >>>>>>> publish all guidelines as a wiki? >>>>>>> >>>>>>> If it is the former, is it really worth it? >>>>>>> >>>>>>> Advantages with a wiki: >>>>>>> >>>>>>> + It can be updated more easily >>>>>>> >>>>>>> Some drawbacks: >>>>>>> >>>>>>> - It can be updated more easily >>>>>>> (meaning they are less stable) >>>>>>> >>>>>>> - Wikis tend to not be alive after some time, and are not that >>>>>>> easy to find. Just try to find the various YANG-related wikis >>>>>>> we've tried to maintain over the years. >>>>>>> >>>>>>> - Links in RFCs also have problems. Sites are re-orginized etc. >>>>>>> As an example, the link to the security guidelines template in >>>>>>> RFC 6087 doesn't work anymore. >>>>>>> >>>>>>> - People that are looking for a stable reference will have problems >>>>>>> (I think Rob mentioned that IEEE still refer to RFC 6087 (which >>>>>>> is understandable; that's the published version). >>>>>>> >>>>>>> - Who maintains the Wiki, and what are the rules for updating it? >>>>>>> >>>>>>> >>>>>>> I suggest we have the tree-related guidelines (actually just a few >>>>>>> sentences) in the tree draft, and since 6087bis already refers to >>>>>>> this document it is not a big problem that guidelines are spread out >>>>>>> over several documents that are difficult to find. >>>>>>> >>>>>>> >>>>>>> >>>>>>> /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 >>>>> 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 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 Dec 7 17:07:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651DF128B38 for ; Thu, 7 Dec 2017 17:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 Gk19kPaD3MxN for ; Thu, 7 Dec 2017 17:07:09 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 99191127698 for ; Thu, 7 Dec 2017 17:07:09 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.58.28; From: "Susan Hares" To: "'Kent Watsen'" , "'Lou Berger'" , , "'Benoit Claise'" , "'Juergen Schoenwaelder'" References: <20171115.135818.591114714397486064.mbj@tail-f.com> <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net> <20171117065424.ccnx3dufs7e5abk3@elstar.local> <1e71a94a-d07a-0c0b-bc02-56aefdf19329@labn.net> <296B481E-20A5-4362-AE5C-174481FEDFA4@juniper.net> In-Reply-To: <296B481E-20A5-4362-AE5C-174481FEDFA4@juniper.net> Date: Thu, 7 Dec 2017 20:07:04 -0500 Message-ID: <002f01d36fc0$dd272350$977569f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIYiVulqF0NfmhUSOkO8xFRxfIw1gKEwmFWAVT6F7IBb2tBmwEVRqXTont67JA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] intended status of the tree diagram document X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 01:07:13 -0000 Kent: A common way to express tree-diagrams in Yang documents provides a common and clear to describe the models. This would be really helpful to those using these yang models. Seems like a standard or a BCP to me. Sue Hares -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Thursday, December 7, 2017 7:06 PM To: Lou Berger; netmod@ietf.org; Benoit Claise; Juergen Schoenwaelder Subject: Re: [netmod] intended status of the tree diagram document BCP for tree-diagrams? This doesn't seem like an appropriate application of that designation. I don't view the format for tree diagrams to be a "practice", whereas it definitely seems "informational". Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does not represent an Internet community consensus or recommendation" could be cause for objection, since this draft is obviously going through a WG (NETMOD) and therefore does, in fact, represent some form of consensus, but I'm willing to gloss over that line as, clearly, many Informational RFCs are published by WGs, which wouldn't be possible if that line were taken literally. Perhaps we should file Errata against it? Kent // co-chair ===== original message ===== Hi Juergen, Sorry for the slow response, I missed this message. Circling back to this discussion made me go revisit RFC2026. Based on all the factors/discussions I agree that standards track isn't quite right for this document, but I also think informational isn't quite right either. I do think BCP would as described in RFC2026 fits. This said, I think it would be good to hear from at least Kent (as Chair) and Benoit (as AD) if they agree/disagree with publishing as a BCP. Kent, Benoit? Thanks, Lou On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote: > Lou, > > right now, the document says standards track, Martin's proposal was to > move to informational. So how do I parse "I think you are correct. We > should leave as is."? > > /js > > On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote: >> Martin, >> I think you are correct. We should leave as is. >> >> I'm sure Kent/the document Shepherd makes sure whatever we do is >> right before publication in any case. >> >> Lou (as contributor) >> >> On 11/15/2017 8:58 PM, Martin Bjorklund wrote: >>> Hi, >>> >>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status >>> Standards Track. I think I heard during the meeting today that it >>> ought to be Informational. I think this makes sense. It would then >>> imply that other standards track documents will have the tree >>> diagram document as an informative reference. >>> >>> Should we make this change? >>> >>> >>> /martin >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma >>> ilman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voD >>> TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpvoumTA >>> -4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEsko >>> noVDeyYcQE&e= >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai >> lman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTX >> cWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpvoumTA-4y >> jD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEskonoVD >> eyYcQE&e= _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Dec 7 17:21:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADE3126C26 for ; Thu, 7 Dec 2017 17:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 OAqdhzIicNwI for ; Thu, 7 Dec 2017 17:21:42 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3A1AC120726 for ; Thu, 7 Dec 2017 17:21:42 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.58.28; From: "Susan Hares" To: "'Joel M. Halpern'" , References: <20171115.101454.1576716701146734257.mbj@tail-f.com> <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net> <20171117070043.pm7rn25yj3hxum3q@elstar.local> <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> <1cb63d28-4333-c36a-dbe7-6cc58eaa5a3a@joelhalpern.com> In-Reply-To: <1cb63d28-4333-c36a-dbe7-6cc58eaa5a3a@joelhalpern.com> Date: Thu, 7 Dec 2017 20:21:37 -0500 Message-ID: <004001d36fc2$e5193790$af4ba6b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxefq6yqyvOLF6jhxyeqpBlh8GFwHgxCcMAmPZNysCzQvFewIu7OMMAbmWURQBxIGsSgFV4Th1owvtEoA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] tree diagram guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 01:21:44 -0000 Joel: Agreed. If it is going to common usage, then a BCP is appropriate. = Otherwise, the reader and user gets confused.=20 Sue=20 -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Joel M. = Halpern Sent: Thursday, December 7, 2017 8:05 PM To: netmod@ietf.org Subject: Re: [netmod] tree diagram guidelines I have been watching this discussion of referencing the wiki page = from the RFC-to-be about tree diagrams. I must admit that I am confused = as to why we would want to do so. For anyone writing a document with a YANG tree, what they are = required to do is what is in this RFC. While the wiki page may be = interesting, it is not normative. For anyone reading an RFC that uses a Tree diagram (a significantly = larger number of people), what they need to know is in the RFC. Reading = the wiki not only is not normative, it may well have content that was = not even present when the RFC that they are reading was written. In = fact, the content of the wiki may contradict what is in the RFC they are = reading, without indicating any errors having been made. Which I fear = may be confusing to the reader. I understand and support wanting to make it easy for readers to = find the wiki of ongoing discussions of YANG tree diagrams (and other issues.) But it seems like this is the wrong way to achieve the goal. Yours, Joel On 12/7/17 6:38 PM, Lou Berger wrote: > Hi, >=20 > Following up on this discussion (and hoping to wrap it up): >=20 > I have created two wikis off of > https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis=20 > content and the other for section 3 of tree diagrams. I also propose=20 > the following changes to the tree-diagrams draft: >=20 > To section 3 intro, add: > For the most current quidelines being developed, please see the=20 > IETF NetMod Working > Group Wiki, see: https://trac.ietf.org/trac/netmod/wiki/WikiStart >=20 > Add : > 3.2. Groupings >=20 > If the YANG module is comprised of groupings only, then the tree > diagram should contain the groupings. The 'pyang' compiler can be > used to produce a tree diagram with groupings using the "-f tree=20 > -- > tree-print-groupings" command line parameters. >=20 > And to section 3.3, start with: >=20 > Tree diagrams can be split into sections to correspond to document > structure. >=20 > For 6087 bis, I think section 3.4 gets replaced with something like. >=20 > YANG tree diagrams provide a concise representation of a YANG=20 > module, > and SHOULD be included to help readers understand YANG module > structure. Guidelines on tree diagrams can be found in Section 3 = > of > [I-D.ietf-netmod-yang-tree-diagrams]. >=20 > These changes can be found at: > https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c28 > 5758eb5aaaf02cf980269afff >=20 > This leaves the intended status as the key open issue on the draft. >=20 > Lou >=20 >=20 > On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote: >> I am confused. I think there was some consensus to >> >> - include all tree related guidelines in the tree document, remove = all tree >> related guidelines from 6087bis and have 6087bis point to the tree = document >> (which it already does) >> >> The rest is pointless since AFAIK there is no wiki guidelines pages=20 >> to point to and there is AFAIK nobody in place to actually maintain=20 >> such a wiki page. Perhaps a wiki is the future but until future has=20 >> arrived, we should not point to it. >> >> The other proposal I heard was to have a landing page that points to=20 >> the current guideline work which points to the relevant documents. A=20 >> wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does = >> not affect the documents. >> >> /js >> >> PS: I am happy to add pointers to guidelines as a section to the >> wikipedia page. >> >> On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote: >>> To circle back to this. My sense of this discussion (as=20 >>> contributor) is >>> (a) the tree diagrams draft should be updated to point to a = "guidelines" >>> wiki page for "the most current guidelines" >>> (b) the tree diagrams draft should be updated to include a full set=20 >>> of the current tree related guidelines >>> (c) 6087bis should be updated to point to a "guidelines" wiki page=20 >>> for "the most current guidelines" >>> (d) 6087bis should have it's tree guidelines point to the tree=20 >>> diagrams document -- in addition to pointing to the wiki >>> >>> Does this sound right? >>> >>> Lou >>> (as tree co-author) >>> >>> On 11/16/2017 11:04 AM, Mehmet Ersue wrote: >>>> The Wiki is useful as a starting point providing a collection of = pointers to guideline RFCs and the bis-revisions in development. >>>> >>>> Cheers, >>>> Mehmet >>>> >>>>> -----Original Message----- >>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh=20 >>>>> Jethanandani >>>>> Sent: Thursday, November 16, 2017 7:39 AM >>>>> To: Robert Wilton >>>>> Cc: netmod@ietf.org >>>>> Subject: Re: [netmod] tree diagram guidelines >>>>> >>>>> Other SDOs can and follow the work in IETF through the RFCs we = publish. >>>>> They do not follow wiki=E2=80=99s, unless the document itself = says, =E2=80=9Chere=20 >>>>> are the guidelines, but if you are looking for the latest, go to=20 >>>>> this wiki=E2=80=9D. I therefore would support the proposal = outlined below.=20 >>>>> It gives the SDO a stable point of reference with a document,=20 >>>>> which gets updated occasionally, but also allows them to peak at = what is coming down the pipeline. >>>>> >>>>> Thanks. >>>>> >>>>>> On Nov 15, 2017, at 6:53 PM, Robert Wilton = wrote: >>>>>> >>>>>> I liked the suggestion from Chris Hopps: >>>>>> >>>>>> I think that it was along the lines of ... >>>>>> >>>>>> The RFC contains a reference at the top that states that updates=20 >>>>>> to the >>>>> guidelines is available on a wiki at .... >>>>>> Every few years the guidelines on the wiki can be folded into a=20 >>>>>> latest >>>>> version of the guidelines draft. >>>>>> 6087bis looks to be 3.5 years old. Should folks, e.g. at BBF,,=20 >>>>>> IEEE, or MEF be >>>>> using the latest draft guidelines, or should then use the=20 >>>>> published RFC until 6087bis is actually republshed? >>>>>> Thanks, >>>>>> Rob >>>>>> >>>>>> >>>>>> On 15/11/2017 10:14, Martin Bjorklund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> There was a proposal in the meeting today to have the guidelines = >>>>>>> for tree diagrams in a wiki, instead of having them in 6087bis=20 >>>>>>> or in the tree diagram document. >>>>>>> >>>>>>> Was the proposal really to have a wiki for just the tree=20 >>>>>>> guidelines, or was the proposal to withdraw 6087bis from the=20 >>>>>>> process and instead publish all guidelines as a wiki? >>>>>>> >>>>>>> If it is the former, is it really worth it? >>>>>>> >>>>>>> Advantages with a wiki: >>>>>>> >>>>>>> + It can be updated more easily >>>>>>> >>>>>>> Some drawbacks: >>>>>>> >>>>>>> - It can be updated more easily >>>>>>> (meaning they are less stable) >>>>>>> >>>>>>> - Wikis tend to not be alive after some time, and are not = that >>>>>>> easy to find. Just try to find the various YANG-related = wikis >>>>>>> we've tried to maintain over the years. >>>>>>> >>>>>>> - Links in RFCs also have problems. Sites are re-orginized = etc. >>>>>>> As an example, the link to the security guidelines = template in >>>>>>> RFC 6087 doesn't work anymore. >>>>>>> >>>>>>> - People that are looking for a stable reference will have = problems >>>>>>> (I think Rob mentioned that IEEE still refer to RFC 6087 = (which >>>>>>> is understandable; that's the published version). >>>>>>> >>>>>>> - Who maintains the Wiki, and what are the rules for = updating it? >>>>>>> >>>>>>> >>>>>>> I suggest we have the tree-related guidelines (actually just a=20 >>>>>>> few >>>>>>> sentences) in the tree draft, and since 6087bis already refers=20 >>>>>>> to this document it is not a big problem that guidelines are=20 >>>>>>> spread out over several documents that are difficult to find. >>>>>>> >>>>>>> >>>>>>> >>>>>>> /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 >>>>> 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 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Dec 7 23:22:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57E129516 for ; Thu, 7 Dec 2017 23:22:44 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC1R_HbtFG7s for ; Thu, 7 Dec 2017 23:22:42 -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 1EF0F120727 for ; Thu, 7 Dec 2017 23:22:41 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EE65F6AC; Fri, 8 Dec 2017 08:22: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 KMbn0ORX71-s; Fri, 8 Dec 2017 08:22: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; Fri, 8 Dec 2017 08:22:39 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA15E20129; Fri, 8 Dec 2017 08:22:39 +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 ppu_ka7eFack; Fri, 8 Dec 2017 08:22:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67B2F2012C; Fri, 8 Dec 2017 08:22:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 49A624190176; Fri, 8 Dec 2017 08:21:10 +0100 (CET) Date: Fri, 8 Dec 2017 08:21:10 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Mehmet Ersue , 'Mahesh Jethanandani' , 'Robert Wilton' , netmod@ietf.org, Andy Bierman Message-ID: <20171208072110.37qd5s57ccgqt5jt@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Mehmet Ersue , 'Mahesh Jethanandani' , 'Robert Wilton' , netmod@ietf.org, Andy Bierman References: <20171115.101454.1576716701146734257.mbj@tail-f.com> <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net> <20171117070043.pm7rn25yj3hxum3q@elstar.local> <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] tree diagram guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 07:22:44 -0000 On Thu, Dec 07, 2017 at 06:38:14PM -0500, Lou Berger wrote: > > This leaves the intended status as the key open issue on the draft. > Have the suggestions for including a collapsed view of uses been included? Related to the status, I do think that the reference to YANG [RFC7950] should be normative - other BCP documents also have normative references and frankly this document talks a lot about YANG constructs and hence it really has more than in informative dependency on YANG. Is someone tracking issues somewhere? /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 Dec 7 23:25:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB13129510 for ; Thu, 7 Dec 2017 23:25:37 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21mGY5rnjZBH for ; Thu, 7 Dec 2017 23:25:34 -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 41CDA120727 for ; Thu, 7 Dec 2017 23:25:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0A43160; Fri, 8 Dec 2017 08:25:33 +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 TTHuQWoRoNev; Fri, 8 Dec 2017 08:25:31 +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, 8 Dec 2017 08:25:32 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0A1E20129; Fri, 8 Dec 2017 08:25:32 +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 V0OWwN_CNs5T; Fri, 8 Dec 2017 08:25:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EB912012C; Fri, 8 Dec 2017 08:25:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C6A3F41901E3; Fri, 8 Dec 2017 08:24:00 +0100 (CET) Date: Fri, 8 Dec 2017 08:24:00 +0100 From: Juergen Schoenwaelder To: "Joel M. Halpern" Cc: netmod@ietf.org Message-ID: <20171208072400.ieuybzrm3kudfsya@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Joel M. Halpern" , netmod@ietf.org References: <20171115.101454.1576716701146734257.mbj@tail-f.com> <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net> <20171117070043.pm7rn25yj3hxum3q@elstar.local> <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> <1cb63d28-4333-c36a-dbe7-6cc58eaa5a3a@joelhalpern.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: <1cb63d28-4333-c36a-dbe7-6cc58eaa5a3a@joelhalpern.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] tree diagram guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 07:25:37 -0000 I agree. Fragile pointers to pages that can change anytime are problematic in static documents. /js On Thu, Dec 07, 2017 at 08:04:52PM -0500, Joel M. Halpern wrote: > I have been watching this discussion of referencing the wiki page from > the RFC-to-be about tree diagrams. I must admit that I am confused as to > why we would want to do so. > > For anyone writing a document with a YANG tree, what they are required > to do is what is in this RFC. While the wiki page may be interesting, it is > not normative. > For anyone reading an RFC that uses a Tree diagram (a significantly > larger number of people), what they need to know is in the RFC. Reading the > wiki not only is not normative, it may well have content that was not even > present when the RFC that they are reading was written. In fact, the > content of the wiki may contradict what is in the RFC they are reading, > without indicating any errors having been made. Which I fear may be > confusing to the reader. > > I understand and support wanting to make it easy for readers to find the > wiki of ongoing discussions of YANG tree diagrams (and other issues.) But > it seems like this is the wrong way to achieve the goal. > > Yours, > Joel > > On 12/7/17 6:38 PM, Lou Berger wrote: > > Hi, > > > > Following up on this discussion (and hoping to wrap it up): > > > > I have created two  wikis off of > > https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis > > content and the other for section 3 of tree diagrams.  I also propose > > the following changes to the tree-diagrams draft: > > > > To section 3 intro, add: > >     For the most current quidelines being developed, please see the IETF > > NetMod Working > >    Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart > > > > Add : > >   3.2.  Groupings > > > >    If the YANG module is comprised of groupings only, then the tree > >    diagram should contain the groupings.  The 'pyang' compiler can be > >    used to produce a tree diagram with groupings using the "-f tree -- > >    tree-print-groupings" command line parameters. > > > > And to section 3.3, start with: > > > >    Tree diagrams can be split into sections to correspond to document > >    structure. > > > > For 6087 bis, I think section 3.4 gets replaced with something like. > > > >     YANG tree diagrams provide a concise representation of a YANG module, > >    and SHOULD be included to help readers understand YANG module > >     structure.  Guidelines on tree diagrams can be found in Section 3 of > >     [I-D.ietf-netmod-yang-tree-diagrams]. > > > > These changes can be found at: > > https://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c285758eb5aaaf02cf980269afff > > > > This leaves the intended status as the key open issue on the draft. > > > > Lou > > > > > > On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote: > > > I am confused. I think there was some consensus to > > > > > > - include all tree related guidelines in the tree document, remove all tree > > > related guidelines from 6087bis and have 6087bis point to the tree document > > > (which it already does) > > > > > > The rest is pointless since AFAIK there is no wiki guidelines pages to > > > point to and there is AFAIK nobody in place to actually maintain such > > > a wiki page. Perhaps a wiki is the future but until future has > > > arrived, we should not point to it. > > > > > > The other proposal I heard was to have a landing page that points to > > > the current guideline work which points to the relevant documents. A > > > wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not > > > affect the documents. > > > > > > /js > > > > > > PS: I am happy to add pointers to guidelines as a section to the > > > wikipedia page. > > > > > > On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote: > > > > To circle back to this. My sense of this discussion (as contributor) is > > > > (a) the tree diagrams draft should be updated to point to a "guidelines" > > > > wiki page for "the most current guidelines" > > > > (b) the tree diagrams draft should be updated to include a full set of the > > > > current tree related guidelines > > > > (c) 6087bis should be updated to point to a "guidelines" wiki page for "the > > > > most current guidelines" > > > > (d) 6087bis should have it's tree guidelines point to the tree diagrams > > > > document -- in addition to pointing to the wiki > > > > > > > > Does this sound right? > > > > > > > > Lou > > > > (as tree co-author) > > > > > > > > On 11/16/2017 11:04 AM, Mehmet Ersue wrote: > > > > > The Wiki is useful as a starting point providing a collection of pointers to guideline RFCs and the bis-revisions in development. > > > > > > > > > > Cheers, > > > > > Mehmet > > > > > > > > > > > -----Original Message----- > > > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh > > > > > > Jethanandani > > > > > > Sent: Thursday, November 16, 2017 7:39 AM > > > > > > To: Robert Wilton > > > > > > Cc: netmod@ietf.org > > > > > > Subject: Re: [netmod] tree diagram guidelines > > > > > > > > > > > > Other SDOs can and follow the work in IETF through the RFCs we publish. > > > > > > They do not follow wiki’s, unless the document itself says, “here are the > > > > > > guidelines, but if you are looking for the latest, go to this wiki”. I therefore > > > > > > would support the proposal outlined below. It gives the SDO a stable point of > > > > > > reference with a document, which gets updated occasionally, but also allows > > > > > > them to peak at what is coming down the pipeline. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > On Nov 15, 2017, at 6:53 PM, Robert Wilton wrote: > > > > > > > > > > > > > > I liked the suggestion from Chris Hopps: > > > > > > > > > > > > > > I think that it was along the lines of ... > > > > > > > > > > > > > > The RFC contains a reference at the top that states that updates to the > > > > > > guidelines is available on a wiki at .... > > > > > > > Every few years the guidelines on the wiki can be folded into a latest > > > > > > version of the guidelines draft. > > > > > > > 6087bis looks to be 3.5 years old. Should folks, e.g. at BBF,, IEEE, or MEF be > > > > > > using the latest draft guidelines, or should then use the published RFC until > > > > > > 6087bis is actually republshed? > > > > > > > Thanks, > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > On 15/11/2017 10:14, Martin Bjorklund wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > There was a proposal in the meeting today to have the guidelines for > > > > > > > > tree diagrams in a wiki, instead of having them in 6087bis or in the > > > > > > > > tree diagram document. > > > > > > > > > > > > > > > > Was the proposal really to have a wiki for just the tree guidelines, > > > > > > > > or was the proposal to withdraw 6087bis from the process and instead > > > > > > > > publish all guidelines as a wiki? > > > > > > > > > > > > > > > > If it is the former, is it really worth it? > > > > > > > > > > > > > > > > Advantages with a wiki: > > > > > > > > > > > > > > > > + It can be updated more easily > > > > > > > > > > > > > > > > Some drawbacks: > > > > > > > > > > > > > > > > - It can be updated more easily > > > > > > > > (meaning they are less stable) > > > > > > > > > > > > > > > > - Wikis tend to not be alive after some time, and are not that > > > > > > > > easy to find. Just try to find the various YANG-related wikis > > > > > > > > we've tried to maintain over the years. > > > > > > > > > > > > > > > > - Links in RFCs also have problems. Sites are re-orginized etc. > > > > > > > > As an example, the link to the security guidelines template in > > > > > > > > RFC 6087 doesn't work anymore. > > > > > > > > > > > > > > > > - People that are looking for a stable reference will have problems > > > > > > > > (I think Rob mentioned that IEEE still refer to RFC 6087 (which > > > > > > > > is understandable; that's the published version). > > > > > > > > > > > > > > > > - Who maintains the Wiki, and what are the rules for updating it? > > > > > > > > > > > > > > > > > > > > > > > > I suggest we have the tree-related guidelines (actually just a few > > > > > > > > sentences) in the tree draft, and since 6087bis already refers to > > > > > > > > this document it is not a big problem that guidelines are spread out > > > > > > > > over several documents that are difficult to find. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /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 > > > > > > 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 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 -- 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 Dec 8 01:25:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26C6124D37 for ; Fri, 8 Dec 2017 01:25:34 -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 Zy88kEjBaIez for ; Fri, 8 Dec 2017 01:25:33 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 230561200CF for ; Fri, 8 Dec 2017 01:25:33 -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 0DFD31AE0398; Fri, 8 Dec 2017 10:25:32 +0100 (CET) Date: Fri, 08 Dec 2017 10:25:31 +0100 (CET) Message-Id: <20171208.102531.577590682418567643.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: lberger@labn.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20171208072110.37qd5s57ccgqt5jt@elstar.local> References: <20171117070043.pm7rn25yj3hxum3q@elstar.local> <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> <20171208072110.37qd5s57ccgqt5jt@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] tree diagram guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 09:25:34 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 07, 2017 at 06:38:14PM -0500, Lou Berger wrote: > > > > This leaves the intended status as the key open issue on the draft. > > > > Have the suggestions for including a collapsed view of uses been > included? No, not yet. > Related to the status, I do think that the reference to YANG [RFC7950] > should be normative - other BCP documents also have normative > references and frankly this document talks a lot about YANG constructs > and hence it really has more than in informative dependency on YANG. I agree. > Is someone tracking issues somewhere? Not in a tracker, no. Just manually. /martin From nobody Fri Dec 8 01:47:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312FF126CB6 for ; Fri, 8 Dec 2017 01:47: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, 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 iEjxZ200fIFq for ; Fri, 8 Dec 2017 01:47: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 479791200CF for ; Fri, 8 Dec 2017 01:47: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 370181AE0398 for ; Fri, 8 Dec 2017 10:47:41 +0100 (CET) Date: Fri, 08 Dec 2017 10:47:41 +0100 (CET) Message-Id: <20171208.104741.1957721911727198135.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 09:47:45 -0000 Hi, There has been quite a lot of discussion about the YANG library data model on the list. The authors of draft-ietf-netconf-rfc7895bis have tried to understand all arguments in the discussion, and provide a solution. Below are 3 solution proposals (we have discussed more, but they are basically just variations on the same themes). Absolute Requirements --------------------- o RFC 7950, Section 5.6.5 says: A server MUST NOT implement more than one revision of a module. o draft-ietf-netmod-revised-datastores says: The conventional configuration datastores [...] share exactly the same datastore schema o draft-ietf-netmod-revised-datastores says: The datastore schema for MUST be a superset of the combined datastore schema used in all configuration datastores except that YANG nodes supported in a configuration datastore MAY be omitted from if a server is not able to accurately report them. These requirements (of course) still hold, and we think that the YANG library document should explain what they imply for the data reported as part of the library. (For example, all conventional datastores MUST have a reference to the same "schema"). Objectives (in no particular order) ----------------------------------- 1. As efficient as possible for a client to consume. Since the size of the yang library can be quite large, it should be possible for clients to cache the yang library information. 2. A dynamic datastore must be able to implement a module or feature that is not implemented in the conventional datastores. 3. It must be possible to NOT implement a module or feature in operational, even if it is implemented in some other datastore. This is required for transition purposes; a server that wants to implement should not have to implement all modules at once. 4. A given module can only be implemented in one revision in all datastores. If a module is implemented in more than one datastores, the same revision is implemented in all these datastores. 5. Multiple revisions can be used for import, if import-by revision is used. 6. Nice to have: make it possible to be used by schema mount It should be noted that because of 2 and 3 (and 6), the original data model in RFC 7895 cannot be used. Use Cases --------- Here's a set of use cases that must be supported. C1. conventional + operational, all have the same schema C2. conventional + operational, ietf-hardware is not implemented in conventional C3. conventional + operational, some modules not yet implemented in operational, and some modules are partly implemented in operational. C4. conventional + operational + ephemeral, ephemeral has its own set of modules Alt. A. ------- Each datastore refers to a schema, and each schema contains a flat list of all modules, features, etc. +--ro yang-library +--ro schema* [name] | +--ro name string | +--ro checksum string | +--ro module* [name] | | +--ro name yang:yang-identifier | | +--ro revision? revision-identifier | | +--ro namespace inet:uri | | +--ro location* inet:uri | | +--ro submodule* [name] | | | +--ro name yang:yang-identifier | | | +--ro revision? revision-identifier | | | +--ro location* inet:uri | | +--ro feature* [name] | | | +--ro name yang:yang-identifier | | +--ro deviation* [module] | | +--ro module -> ../../name | +--ro import-only-module* [name revision] | +--ro name yang:yang-identifier | +--ro revision union | +--ro namespace inet:uri | +--ro location* inet:uri | +--ro submodule* [name] | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri +--ro datastore* [name] | +--ro name identityref | +--ro schema -> ../../schema/name +--ro checksum string How does this solution handle the use cases above? C1: One schema, all datastores refer to this schema. C2: Two schemas, "conventional" and "operational". They differ in just one element (ietf-hardware). All other module information is entirely duplicated in both. C3: Two schemas, "conventional" and "operational". They differ in the modules not implemented in operational, and operational also has some deviation modules with "not-implemented". C4: Three schemas, "conventional", "ephemeral", "operational". "operational" contains the union of all modules in the other two. Pro: simple on the client, simple on the server Con: verbose, since a single difference requires a complete, new, schema. Alt. B. ------- Each datastore refers to a schema, and each schema contains a list of references to module-sets, and each module-set contains a flat list of all modules, features, etc. When combining module-sets into a schema there MUST NOT be any duplicate module definitions in the module-sets. +--ro yang-library +--ro module-set* [name] | +--ro name string | +--ro checksum string | +--ro module* [name] | | +--ro name yang:yang-identifier | | +--ro revision? revision-identifier | | +--ro namespace inet:uri | | +--ro location* inet:uri | | +--ro submodule* [name] | | | +--ro name yang:yang-identifier | | | +--ro revision? revision-identifier | | | +--ro location* inet:uri | | +--ro feature* [name] | | | +--ro name yang:yang-identifier | | +--ro deviation* [module] | | +--ro module -> ../../name | +--ro import-only-module* [name revision] | +--ro name yang:yang-identifier | +--ro revision union | +--ro namespace inet:uri | +--ro location* inet:uri | +--ro submodule* [name] | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri +--ro schema* [name] | +--ro name string | +--ro checksum string | +--ro module-set* -> ../../module-set/name +--ro datastore* [name] | +--ro name identityref | +--ro schema -> ../../schema/name +--ro checksum string How does this solution handle the use cases above? C1: One module-set, one schema, all datastores refer to this schema, the schema refers to the single module-set. C2: Two schemas, "conventional" and "operational", and two module-sets. One module-set contains just "ietf-hardware" and the other everything else. The "operational" schema refers to both module-sets, and the "conventional" to just the one without "ietf-hardware". C3: Two schemas, "conventional" and "operational", and three module-sets. One module-set contains all modules fully implemented in both conventional and operational, one contains the modules implemented only in conventional, and one the modules and deviations for the partly implemented modules in operational. C4: Three schemas, "conventional", "ephemeral", "operational", but just two module-sets. "conventional" refers to one of the module-sets, and "ephemeral" to the other. "operational" refers to both. Pro: less verbose Con: the client has to follow extra references and must combine the result from the references into a single schema. Alt. C. ------- (This is the draft -02 version with just some name changes) Each datastore refers to a schema, and each schema contains a list of references to each module it includes. +--ro yang-library +--ro module* [id] | +--ro id string | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri | +--ro namespace inet:uri | +--ro feature* yang:yang-identifier | +--ro deviation* [module] | | +--ro module -> ../../id | +--ro conformance-type enumeration | +--ro submodule* [name] | +--ro name yang:yang-identifier | +--ro revision? revision-identifier | +--ro location* inet:uri +--ro schema* [name] | +--ro name string | +--ro module* -> ../../module/id +--ro datastore* [name] | +--ro name identityref | +--ro schema -> ../../schema/name +--ro checksum string How does this solution handle the use cases above? C1: One schema, all datastores refer to this schema, the schema refers to all modules. C2: Two schemas, "conventional" and "operational", and the module list contains all modules. The "operational" schema refers to all modules, and "conventional" to all modules except "ietf-hardware". C3: similar to C2, except there will be two entries in the module list for evenry module that is partly implemented in operational. C4: Three schemas, "conventional", "ephemeral", "operational", and the module list contains all modules. Each schema refers to the modules it supports. Pro: All modules available are listed in one place. Con: the client has to follow extra references and must combine the result from the references into a single schema. the least "direct" solution due to the module "id". probably a bit tricky to implement on the server. /martin From nobody Fri Dec 8 01:57:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B31127136 for ; Fri, 8 Dec 2017 01:57:23 -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 SA81xycLM_ku for ; Fri, 8 Dec 2017 01:57:20 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0117.outbound.protection.outlook.com [104.47.0.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D1E1200CF for ; Fri, 8 Dec 2017 01:57:19 -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=au82u5NmGOwpXu0fzhF1PlNOMhPerfwuw0nh5pDXkBA=; b=mkPLXIAU7B7RY4zhKdFSzbbnX6blwedLP9hPEOxTrr3m4hzXH5fAhro/Yu9UIiLYZ18vkzob2ACB7Bf9d5p4r4WV5kwPso7dtap1KgER6ZODfnldGkvpoIIPJBdNAxBNDT+0/N5p9iC/5C5L+50hKrjqIQUHZXu++EWcrdpNPg0= Received: from AM5PR0701MB2644.eurprd07.prod.outlook.com (10.173.92.151) by AM4PR07MB3058.eurprd07.prod.outlook.com (10.171.188.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Fri, 8 Dec 2017 09:57:17 +0000 Received: from AM5PR0701MB2644.eurprd07.prod.outlook.com ([fe80::846f:fdca:50fb:fe7f]) by AM5PR0701MB2644.eurprd07.prod.outlook.com ([fe80::846f:fdca:50fb:fe7f%18]) with mapi id 15.20.0302.011; Fri, 8 Dec 2017 09:57:16 +0000 From: "Carey, Timothy (Nokia - US)" To: Kent Watsen , Juergen Schoenwaelder , "Bogaert, Bart (Nokia - BE/Antwerp)" CC: NetMod WG Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-entity-05 Thread-Index: AQIKv3Fygx65CkgQXkSA/zVmDL0oYAIXr1dqAlwOu8kB1Wf0gaKYTBNw Date: Fri, 8 Dec 2017 09:57:16 +0000 Message-ID: References: <20171205144509.q2fktqg3u7knk2yv@elstar.local> <25A8BF74-A6F2-4F0B-AD73-AA992FF28E05@juniper.net> In-Reply-To: <25A8BF74-A6F2-4F0B-AD73-AA992FF28E05@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.228.32.191] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3058; 6:X6lSiiXLYWh4nzONYSk6fpfuAuixZMU8PpSatij+cxQL230EqCxrGpzuL60fJt3zFHeiAGL8L4vr6u0jOscJGYNFVs/48Pg6rDZLGe5lRUTnP5ZKPv2pQZd+Mh54rTgkoxvhgCkaCdutm0YNW6nMQst0NYCBBHrjjJuZ0J1ihE1HL6jYF05xMBl1JeGxrkKDKp3LqDu3/13Vz1qEujTiE+cn53S0RqtkWR0wK8mWeTPI6WBLQ2gGzPPI3GOxQzUL7bXkbJzhnbMr5CzaN+xIqTjXehG4lfKt5FfbVJywPbEDusGWcyIbyAMlqbAgeESc1SKAOobcJHaCYfNTcnpKP96kDbzdVYJRgjTJ4QXNC4w=; 5:buSJuBoriV/8vZSidIbh4vF+7omHi+cUWKGS/mdwY1/rucit2R3b8a38PdjAKaNv5jwp3AVBHXhD8wVOcnH2skQ4/0cbJ/PAsxaJ0vUsPClaFyhcrFa/Ja65gw4auNu1y/G3P5pdxiMMLfggXm8lBpuIhmG6fodhsgBrPSEOPoQ=; 24:Dl0dVi0KV6fgFDP7LPaROcqEgUxJqoc6GpITbzi+vGctbbfbKG4Kbcc0s8yRNtwa50f38Byx1Ndjsn2PBB2YJO4AGWl9Gq2c6yF6EBdkSus=; 7:jA/RL98GzLmXLl9QkPYh0IzydEJI0eJGZ9FHhT2SDA1y8kmHDbAvgrpAlu0QLPr4vF/cJ9fp17tdXXz/OxuiCmHCH+DvmbrukGSissS2b1jdTEQ+js5iVGZQIlscGN+xHeFKScbFG1i/e5Mcg14N2KhdZAVvXHmcQem4EY/yTiG2bbby+bmYQdbJcLcDnupCValqrb7xZZCD9zS7K0MEwWrrxx4deNO5s4FLKuQHHPEqnFipUNd7TuKczmSv4k2M x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(366004)(39860400002)(346002)(24454002)(189003)(199004)(13464003)(53936002)(3280700002)(2950100002)(86362001)(3660700001)(5660300001)(575784001)(6636002)(2906002)(8936002)(1941001)(93886005)(33656002)(105586002)(74316002)(7736002)(305945005)(8676002)(230783001)(106356001)(81166006)(66066001)(81156014)(53546010)(7696005)(55016002)(2900100001)(4326008)(76176011)(102836003)(6116002)(316002)(6436002)(229853002)(3846002)(99286004)(5250100002)(8666007)(9686003)(6306002)(68736007)(97736004)(966005)(6246003)(478600001)(110136005)(14454004)(6506006)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3058; H:AM5PR0701MB2644.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e517c761-a87e-48f7-f8d9-08d53e221073 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:AM4PR07MB3058; x-ms-traffictypediagnostic: AM4PR07MB3058: authentication-results: spf=none (sender IP is ) smtp.mailfrom=timothy.carey@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:AM4PR07MB3058; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3058; x-forefront-prvs: 0515208626 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) 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: e517c761-a87e-48f7-f8d9-08d53e221073 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 09:57:16.7701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3058 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-entity-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, 08 Dec 2017 09:57:23 -0000 S2VudCwNCg0KWWVzIGl0IHdvdWxkIGJlIGdvb2Qgc2V0IGEgdGFyZ2V0IGRhdGUgc28gaXQgY29t bXVuaWNhdGVzIHRvIHRoZSBpbmR1c3RyeSB0aGUgaW50ZW50LCBhbGxvd2luZyB0aGVtIHRvIHBs YW4gdGhlaXIgbWlncmF0aW9uLg0KSXQgYWxzbyBhbGxvd3MgdGhlIGluZHVzdHJ5IHRvIHByb3Zp ZGUgZmVlZGJhY2sgcmVnYXJkaW5nIHRoZSBtaWdyYXRpb24gcGVyaW9kLg0KDQpJIHdhbnRlZCB0 byByZWl0ZXJhdGUgQmFydHMgcmVxdWVzdCBmb3IgdGhlIGhhcmR3YXJlIG1vZHVsZSB0byBoYXZl IHN0YXRlIG1vZHVsZSBpbiBhbiBBcHBlbmRpeC4gV2hhdCB5b3UgZG9uJ3Qgd2FudCBpcyBoYXZl IHRoZSBpbmR1c3RyeSBvcmdhbml6YXRpb25zIHRoYXQgdXNlIHRoZSBtb2R1bGVzIHRvIGNyZWF0 ZSB0aGVpciBvd24gc3RhdGUgbW9kdWxlcyAtIHRoaXMgd2lsbCBjYXVzZSB1bmR1ZSBmcmFnbWVu dGF0aW9uIHRoYXQgd2lsbCBoYXJtIHRoZSBhZHZhbmNlbWVudCBvZiBZQU5HLg0KDQpCUiwNClRp bQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2VudCBXYXRzZW4gW21haWx0 bzprd2F0c2VuQGp1bmlwZXIubmV0XSANClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNywgMjAx NyAyOjAzIFBNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU+OyBCb2dhZXJ0LCBCYXJ0IChOb2tpYSAtIEJFL0FudHdlcnApIDxi YXJ0LmJvZ2FlcnRAbm9raWEuY29tPg0KQ2M6IE5ldE1vZCBXRyA8bmV0bW9kQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtZW50 aXR5LTA1DQoNCkFsbCwNCg0KUGlja2luZyB1cCBvbiBKdWVyZ2VuJ3MgY29tbWVudDoNCg0KPiBJ ZiB0aGVzZSBkZXByZWNhdGVkIG9iamVjdHMgYXJlIGVzc2VudGlhbCBmb3IgQkJGIChwbGVhc2Ug Y29uZmlybSksIA0KPiB0aGVuIGl0IG1pZ2h0IGJlIGJldHRlciB0byBkZWZpbmUgdGhlbSBpbiBh IHNlcGFyYXRlIG1vZHVsZS4uLg0KDQpJIGFncmVlIHRoYXQgdGhlIG9iamVjdHMgc2hvdWxkIGJl IGRlZmluZWQgaW4gYSBzZXBhcmF0ZSBtb2R1bGUuICBUaGUgcmVxdWVzdCwgYXMgSSB1bmRlcnN0 YW5kIGl0LCBpcyBmb3IgdGhlcmUgYmUgYW4gImlldGYtaGFyZHdhcmUtc3RhdGUiDQptb2R1bGUg ZGVmaW5lZCBpbiB0aGUgQXBwZW5kaXggb2YgdGhpcyBkcmFmdC4gIEkgYmVsaWV2ZSB0aGF0IGRv aW5nIHNvIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgTk1EQSBndWlkZWxpbmVzOg0KDQogICAoYikg TW9kZWxzIHRoYXQgcmVxdWlyZSBpbW1lZGlhdGUgc3VwcG9ydCBmb3IgImluIHVzZSIgYW5kICJz eXN0ZW0NCiAgIGNyZWF0ZWQiIGluZm9ybWF0aW9uIFNIT1VMRCBiZSBzdHJ1Y3R1cmVkIGZvciBO TURBLiAgQSBub24tTk1EQQ0KICAgdmVyc2lvbiBvZiB0aGVzZSBtb2RlbHMgU0hPVUxEIGV4aXN0 LCBlaXRoZXIgYW4gZXhpc3RpbmcgbW9kZWwgb3IgYQ0KICAgbW9kZWwgY3JlYXRlZCBlaXRoZXIg YnkgaGFuZCBvciB3aXRoIHN1aXRhYmxlIHRvb2xzIHRoYXQgbWlycm9yIHRoZQ0KICAgY3VycmVu dCBtb2RlbGluZyBzdHJhdGVnaWVzLiAgQm90aCB0aGUgTk1EQSBhbmQgdGhlIG5vbi1OTURBIG1v ZHVsZXMNCiAgIFNIT1VMRCBiZSBwdWJsaXNoZWQgaW4gdGhlIHNhbWUgZG9jdW1lbnQsIHdpdGgg Tk1EQSBtb2R1bGVzIGluIHRoZQ0KICAgZG9jdW1lbnQgbWFpbiBib2R5IGFuZCB0aGUgbm9uLU5N REEgbW9kdWxlcyBpbiBhIG5vbi1ub3JtYXRpdmUNCiAgIGFwcGVuZGl4LiAgVGhlIHVzZSBvZiB0 aGUgbm9uLU5NREEgbW9kZWwgd2lsbCBhbGxvdyB0ZW1wb3JhcnkNCiAgIGJyaWRnaW5nIG9mIHRo ZSB0aW1lIHBlcmlvZCB1bnRpbCBOTURBIGltcGxlbWVudGF0aW9ucyBhcmUgYXZhaWxhYmxlLg0K DQpPZiBjb3Vyc2UsIHdlIHNob3VsZCBhc2ssIGZvciBob3cgbG9uZyBpcyBpdCB0aGF0IHRoZSBJ RVRGIChTRE9zIGluDQpnZW5lcmFsKSBzaG91bGQgcHVibGlzaCB0aGVzZSAtc3RhdGUgbW9kdWxl cz8gICBEdXJpbmcgdGhlIGRpc2N1c3Npb24NCmF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGZpcnN0 IHNlc3Npb24gaW4gU2luZ2Fwb3JlLCBJIHNhaWQgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBv ZiAic28gbG9uZyBhcyB0aGVyZSBpcyBtYXJrZXQgZGVtYW5kIGZvciBpdCIsIHdoaWNoDQpzZWVt cyBhIGJpdCB0b28gb3Blbi1lbmRlZCBmb3IgbXkgdGFzdGUuICAgSSByZWNvbW1lbmQgdGhhdCB3 ZSBzZXQgYQ0KZGF0ZSwgcGVyaGFwcyBhIGNvdXBsZSB5ZWFycyBvdXQsIGFmdGVyIHdoaWNoIHdl ICh0aGUgSUVURikgd2lsbCBubyBsb25nZXIgcHVibGlzaCBvciBtYWludGFpbiBzdWNoIGZvby1z dGF0ZSBtb2R1bGVzLg0KDQpUaG91Z2h0cz8NCg0KS2VudCAgLy8gYXMgY28tY2hhaXINCg0KDQo9 PT09PSBvcmlnaW5hbCBtZXNzYWdlID09PT09PQ0KDQpCYXJ0LA0KDQpJIHRoaW5rIHRoZSByZWFz b24gZm9yIHRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIGludGVyZmFjZXMgbW9kZWwgd2FzIHB1 Ymxpc2hlZCBhcyBhbiBSRkMgYmVmb3JlIHdoaWxlIHRoZSBoYXJkd2FyZSBtb2RlbCBpcyBuZXcg YW5kIGhlbmNlIGl0IHNlZW1zIHRvIGxvb2sgYSBiaXQgb2RkIHRvIGRlZmluZSBuZXcgZGVwcmVj YXRlZCBvYmplY3RzLg0KDQpJZiB0aGVzZSBkZXByZWNhdGVkIG9iamVjdHMgYXJlIGVzc2VudGlh bCBmb3IgQkJGIChwbGVhc2UgY29uZmlybSksIHRoZW4gaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGRl ZmluZSB0aGVtIGluIGEgc2VwYXJhdGUgbW9kdWxlIHRoYXQgdGhlbiBjYW4gc2lsZW50bHkgZGll IHdoaWxlIHN5c3RlbXMgbW92ZSB0byBOTURBIChhbmQgc28gd2UgZG8gbm90IGhhdmUgdGhlIGRl cHJlY2F0ZWQgb2JqZWN0cyB3aXRoIHVzIGluIHRoZSBoYXJkd2FyZSBtb2R1bGUgZm9yZXZlciAt IG9yIGF0IGxlYXN0IGFzIGxvbmcgYXMgd2UgdXNlIFlBTkcgMS4xKS4NCg0KL2pzDQoNCk9uIFR1 ZSwgRGVjIDA1LCAyMDE3IGF0IDAyOjM1OjI5UE0gKzAwMDAsIEJvZ2FlcnQsIEJhcnQgKE5va2lh IC0gQkUvQW50d2VycCkNCndyb3RlOg0KPiBIZWxsbywNCj4NCj4gVGhlIGxhdGVzdCBkcmFmdCBk b2VzIG5vdCBjb250YWluIGFuIGFwcGVuZGl4IHdpdGggdGhlIGRlcHJlY2F0ZWQgDQo+IHN0YXRl IHRyZWUgKHRvIHN1cHBvcnQgdGhlIG5vbi1OTURBIG1vZGVsIGFzIHNwZWNpZmllZCBpbiBSRkM2 MDg3YmlzIA0KPiBzZWN0aW9uIDQuMjMuMyksIHNvIGlmIGl0IGlzIHB1Ymxpc2hlZCBpbiB0aGlz IHdheSwgdGhlcmUgaXMgYW4gaXNzdWUgDQo+IGF0IHRoZSBsZXZlbCBvZiBCQkYgVFItMzgzLg0K Pg0KPiBOb3RlIHRoYXQgdGhlIGRyYWZ0LWlldGZuZXRtb2QtcmZjNzIyM2JpcyBkb2VzIGluY2x1 ZGUgdGhlIGRlcHJlY2F0ZWQgDQo+IGNvbnRhaW5lciBpbnRlcmZhY2VzLXN0YXRlLg0KPg0KPiBC ZXN0IHJlZ2FyZHMsDQo+IEJhcnQgQm9nYWVydA0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIExvdSBCZXJnZXINCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAx NyA2OjM2IFBNDQo+IFRvOiBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NCj4gQ2M6IE5ldE1v ZCBXRyBDaGFpcnMgPG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtuZXRtb2Rd IFdHIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5LTA1DQo+DQo+IEFsbCwNCj4N Cj4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiANCj4g ZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5LTA1Lg0KPg0KPiBUaGUgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgZW5kcyBvbiBEZWNlbWJlciAxMy4NCj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0 byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCj4NCj4gUG9zaXRpdmUgY29tbWVudHMsIGUuZy4s ICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgDQo+IGlzIHJlYWR5 IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KPiBUaGlzIGlzIHVzZWZ1bCBhbmQgaW1w b3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCj4NCj4gVGhhbmsgeW91LA0KPiBOZXRtb2QgQ2hh aXJzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWwNCj4gbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgw VWpCWGVNSy1uZGIzdm9EVFhjVw0KPiB6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdz QllhR1R2aklTbGFKZGNabyZtPWNoTFZLd2FBY2RDNkxsa284DQo+IFNhZ0dUZHRhTFZUTUpSVnVG eHgtTWJYdlFVJnM9MXN4R2NWVTlPTWJwalRNTmtlX3I4Q2tMR25Tbk5ocndYbDFhcUFpcWQNCj4g SXMmZT0NCg0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbA0KPiBtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZT Y2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXDQo+IHpvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Y2hMVkt3YUFjZEM2TGxrbzgNCj4gU2FnR1RkdGFMVlRN SlJWdUZ4eC1NYlh2UVUmcz0xc3hHY1ZVOU9NYnBqVE1Oa2VfcjhDa0xHblNuTmhyd1hsMWFxQWlx ZA0KPiBJcyZlPQ0KDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAg ICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIx IDIwMCAzMTAzIA0KPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX193d3cuamFjb2JzLTJEdW5pdmVyc2l0eS5kZV8mZD1Ed0lDQWcmYz1IQWtZdWg2M3Jz dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWNoTFZLd2FBY2RDNkxsa284U2FnR1RkdGFMVlRNSlJW dUZ4eC1NYlh2UVUmcz00Q0I3YkQ1dXR5WDZjNHlBRXlIWmJwMWg3bkhyeEZBUWRyUzJjLXFsbDZN JmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz dm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pv Jm09Y2hMVkt3YUFjZEM2TGxrbzhTYWdHVGR0YUxWVE1KUlZ1Rnh4LU1iWHZRVSZzPTFzeEdjVlU5 T01icGpUTU5rZV9yOENrTEduU25OaHJ3WGwxYXFBaXFkSXMmZT0NCg0KDQo= From nobody Fri Dec 8 02:36:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF3126CB6 for ; Fri, 8 Dec 2017 02:36:54 -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 20vqKblqQewv for ; Fri, 8 Dec 2017 02:36:52 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 970D6120724 for ; Fri, 8 Dec 2017 02:36:51 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id o2so10371059wro.5 for ; Fri, 08 Dec 2017 02:36:51 -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=1A7tl/3I86M+fyPKUI83mYWGul/qUSDi7MGUbzO+1NI=; b=ERcDLjne5ZzoCdKuKdhlpKZYxj6QJ+740H7bjCTfLx+I/aYmPaaWN9Z656JdOlSR0l gMTidoScQZ5quA6hugQRKkaNQQREwhWS0IvnbP+w77QdcYRGhdtaKCDn31wPIk7lWegi spxLY+UhGeGu5GFXMlMN7m9mfZlZvbo9uoQJnRAnAHbboX45ww2xDiNSQ/df8WnAfBgr KSOyENSC9cY98cWCqhAgT/D1TjzNRTPFTweBlb6j1RWSSYpnG1pXuQhUUXULEr9g4IAA M5Q681SYNkiQOydEOn97kiCrfd0xk16N8DIz5SmS17zlktEJWN2KqyggHpP90w1udLXw 4Osw== 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=1A7tl/3I86M+fyPKUI83mYWGul/qUSDi7MGUbzO+1NI=; b=h7Fmuaidg5DRHysNY32VDH6dU7i6PT+4fBh7uhgo6eS/6IRTR7mhbOUx7/1VL/CeLn Sm2v15aawvvEAo/51MjtosLfh+YM1yL4mLLERZDLSV9GDGvB8QSMm2A+X+sA7ojSBTF3 Lar5IrnF5Xqsmc6k/OiN3aPPXwdvm4Qgb/koIObRLK2MikMGa9JLPaiGQIjr9t6zs4C6 kn+CrEx/D5eu//L2cxinhBryuLnd6rEwWla4/xSOdxgho/IIGQ5CZqoWn2LiFM1tL8O+ vvZgIxsVTwq4lKaE/USK1n/Ga5x9DEGLovAJP1fpOkPWG3jByQXK3ijG+OJEui/Mp+DD s2Lg== X-Gm-Message-State: AJaThX4rJiC6pyBMgOUfgdEhZpIp06NMsmMBsWwxrWMbFmvADn7vZRbn zeLUrbucH34kBI0z6fyahXw= X-Google-Smtp-Source: AGs4zMazs8KSsicwNj5vIeb2WNITGBKlVcNjvZUud3xYcJXmGuA8iYK4sz5AKNPr25OWnGEVuTRVww== X-Received: by 10.223.148.69 with SMTP id 63mr27867861wrq.89.1512729410094; Fri, 08 Dec 2017 02:36:50 -0800 (PST) Received: from DESKTOPFLHJVQJ ([2001:16b8:2d7e:3500:e46b:add3:60ca:3d60]) by smtp.gmail.com with ESMTPSA id b78sm1288725wmi.18.2017.12.08.02.36.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 02:36:48 -0800 (PST) From: "Mehmet Ersue" To: "'Susan Hares'" , "'Kent Watsen'" , "'Lou Berger'" , , "'Benoit Claise'" , "'Juergen Schoenwaelder'" References: <20171115.135818.591114714397486064.mbj@tail-f.com> <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net> <20171117065424.ccnx3dufs7e5abk3@elstar.local> <1e71a94a-d07a-0c0b-bc02-56aefdf19329@labn.net> <296B481E-20A5-4362-AE5C-174481FEDFA4@juniper.net> <002f01d36fc0$dd272350$977569f0$@ndzh.com> In-Reply-To: <002f01d36fc0$dd272350$977569f0$@ndzh.com> Date: Fri, 8 Dec 2017 11:36:49 +0100 Message-ID: <01e601d37010$750eacc0$5f2c0640$@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: AQIYiVulqF0NfmhUSOkO8xFRxfIw1gKEwmFWAVT6F7IBb2tBmwEVRqXTAiopNK+iasfYIA== Content-Language: de Archived-At: Subject: Re: [netmod] intended status of the tree diagram document X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 10:36:54 -0000 I think the rules and recommendations in this document should be used, once agreed and published, by all YANG module drafts within and outside of IETF. As such its content is BCP. IETF consensus will be achieved during IETF LC. Cheers, Mehmet > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Friday, December 8, 2017 2:07 AM > To: 'Kent Watsen' ; 'Lou Berger' ; > netmod@ietf.org; 'Benoit Claise' ; 'Juergen > Schoenwaelder' > Subject: Re: [netmod] intended status of the tree diagram document > > Kent: > > A common way to express tree-diagrams in Yang documents provides a > common and clear to describe the models. This would be really helpful to > those using these yang models. Seems like a standard or a BCP to me. > > Sue Hares > > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Thursday, December 7, 2017 7:06 PM > To: Lou Berger; netmod@ietf.org; Benoit Claise; Juergen Schoenwaelder > Subject: Re: [netmod] intended status of the tree diagram document > > > BCP for tree-diagrams? This doesn't seem like an appropriate application > of that designation. I don't view the format for tree diagrams to be a > "practice", whereas it definitely seems "informational". > > Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does not > represent an Internet community consensus or recommendation" could be > cause for objection, since this draft is obviously going through a WG > (NETMOD) and therefore does, in fact, represent some form of consensus, > but I'm willing to gloss over that line as, clearly, many Informational RFCs are > published by WGs, which wouldn't be possible if that line were taken literally. > Perhaps we should file Errata against it? > > Kent // co-chair > > > ===== original message ===== > > Hi Juergen, > > Sorry for the slow response, I missed this message. > > Circling back to this discussion made me go revisit RFC2026. Based on all the > factors/discussions I agree that standards track isn't quite right for this > document, but I also think informational isn't quite right either. I do think > BCP would as described in RFC2026 fits. This said, I think it would be good to > hear from at least Kent (as Chair) and Benoit (as AD) if they agree/disagree > with publishing as a BCP. > > Kent, Benoit? > > Thanks, > > Lou > > On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote: > > Lou, > > > > right now, the document says standards track, Martin's proposal was to > > move to informational. So how do I parse "I think you are correct. We > > should leave as is."? > > > > /js > > > > On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote: > >> Martin, > >> I think you are correct. We should leave as is. > >> > >> I'm sure Kent/the document Shepherd makes sure whatever we do is > >> right before publication in any case. > >> > >> Lou (as contributor) > >> > >> On 11/15/2017 8:58 PM, Martin Bjorklund wrote: > >>> Hi, > >>> > >>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status > >>> Standards Track. I think I heard during the meeting today that it > >>> ought to be Informational. I think this makes sense. It would then > >>> imply that other standards track documents will have the tree > >>> diagram document as an informative reference. > >>> > >>> Should we make this change? > >>> > >>> > >>> /martin > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_ma > >>> > ilman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voD > >>> > TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpv > oumTA > >>> - > 4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byE > sko > >>> noVDeyYcQE&e= > >>> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mai > >> lman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTX > >> > cWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpvou > mTA-4y > >> > jD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEsk > onoVD > >> eyYcQE&e= > > > > _______________________________________________ > 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 Dec 8 03:11:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BF6127010 for ; Fri, 8 Dec 2017 03:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 BnVdvD9U16v7 for ; Fri, 8 Dec 2017 03:10:56 -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 9F3421200C1 for ; Fri, 8 Dec 2017 03:10:56 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 30CF11AB245 for ; Fri, 8 Dec 2017 04:10:55 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id jPAr1w0092SSUrH01PAu9w; Fri, 08 Dec 2017 04:10:55 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=ocR9PWop10UA:10 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=L0RXs2Xe9Y4Ek8hgSpIA:9 a=CjuIK1q_8ugA:10 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: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=pFLttOZSGF1XQiuxSvUTyvVUOTJGUHgzebVLjJato8w=; b=ai5WqD3mBU+24uScI+qZ+QFOqL laZue30jLscogfGq0L9TOJMTVo7imwfWrl2cKVC/kjnHc3ISVOzrj6YQUWRUOqUR+or3jhlmC2Y74 bDs5epNFsxAsBdZJZcz3lHPfo; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52605 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 1eNGYN-001AcW-35; Fri, 08 Dec 2017 04:10:51 -0700 From: Lou Berger To: Martin Bjorklund , Date: Fri, 08 Dec 2017 06:10:49 -0500 Message-ID: <16035d216a8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20171208.104741.1957721911727198135.mbj@tail-f.com> References: <20171208.104741.1957721911727198135.mbj@tail-f.com> User-Agent: AquaMail/1.11.0-568 (build: 101100004) 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: 1eNGYN-001AcW-35 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]:52605 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 11:10:59 -0000 Martin, Thanks for raising this, there's definitely some open issues as well as confusion on this topic. In the different options listed below you say that each datastore refers to a schema, correct? What is the mechanism you would use to do this? In talking to some others on this topic, they suggested using a library per datastore. I haven't look into this enough to know if that is a good or bad idea, but it seems functionally equivalent to your first option but realized in a different way. Just something to add to the mix. Lou On December 8, 2017 4:48:15 AM Martin Bjorklund wrote: > Hi, > > There has been quite a lot of discussion about the YANG library > data model on the list. The authors of draft-ietf-netconf-rfc7895bis > have tried to understand all arguments in the discussion, and provide > a solution. Below are 3 solution proposals (we have discussed more, > but they are basically just variations on the same themes). > > Absolute Requirements > --------------------- > > o RFC 7950, Section 5.6.5 says: > > A server MUST NOT implement more than one revision of a module. > > o draft-ietf-netmod-revised-datastores says: > > The conventional configuration datastores [...] share exactly > the same datastore schema > > o draft-ietf-netmod-revised-datastores says: > > The datastore schema for MUST be a superset of the > combined datastore schema used in all configuration datastores > except that YANG nodes supported in a configuration datastore MAY > be omitted from if a server is not able to > accurately report them. > > > These requirements (of course) still hold, and we think that the YANG > library document should explain what they imply for the data reported > as part of the library. (For example, all conventional datastores > MUST have a reference to the same "schema"). > > > Objectives (in no particular order) > ----------------------------------- > > 1. As efficient as possible for a client to consume. > > Since the size of the yang library can be quite large, it should > be possible for clients to cache the yang library information. > > 2. A dynamic datastore must be able to implement a module or feature > that is not implemented in the conventional datastores. > > 3. It must be possible to NOT implement a module or feature in > operational, even if it is implemented in some other datastore. > > This is required for transition purposes; a server that wants to > implement should not have to implement all modules at > once. > > 4. A given module can only be implemented in one revision in all > datastores. If a module is implemented in more than one > datastores, the same revision is implemented in all these > datastores. > > 5. Multiple revisions can be used for import, if import-by revision > is used. > > 6. Nice to have: make it possible to be used by schema mount > > > It should be noted that because of 2 and 3 (and 6), the original data > model in RFC 7895 cannot be used. > > > Use Cases > --------- > > Here's a set of use cases that must be supported. > > C1. conventional + operational, all have the same schema > > C2. conventional + operational, ietf-hardware is not implemented in > conventional > > C3. conventional + operational, some modules not yet implemented in > operational, and some modules are partly implemented in > operational. > > C4. conventional + operational + ephemeral, ephemeral has its own > set of modules > > > > Alt. A. > ------- > > Each datastore refers to a schema, and each schema contains a flat > list of all modules, features, etc. > > +--ro yang-library > +--ro schema* [name] > | +--ro name string > | +--ro checksum string > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? revision-identifier > | | +--ro namespace inet:uri > | | +--ro location* inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? revision-identifier > | | | +--ro location* inet:uri > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | +--ro deviation* [module] > | | +--ro module -> ../../name > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro namespace inet:uri > | +--ro location* inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > > How does this solution handle the use cases above? > > C1: One schema, all datastores refer to this schema. > > C2: Two schemas, "conventional" and "operational". They differ in > just one element (ietf-hardware). All other module information > is entirely duplicated in both. > > C3: Two schemas, "conventional" and "operational". They differ in > the modules not implemented in operational, and operational also > has some deviation modules with "not-implemented". > > C4: Three schemas, "conventional", "ephemeral", "operational". > "operational" contains the union of all modules in the other > two. > > > Pro: simple on the client, simple on the server > > Con: verbose, since a single difference requires a complete, new, > schema. > > > Alt. B. > ------- > > Each datastore refers to a schema, and each schema contains a list > of references to module-sets, and each module-set contains a flat > list of all modules, features, etc. > > When combining module-sets into a schema there MUST NOT be any > duplicate module definitions in the module-sets. > > > +--ro yang-library > +--ro module-set* [name] > | +--ro name string > | +--ro checksum string > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? revision-identifier > | | +--ro namespace inet:uri > | | +--ro location* inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? revision-identifier > | | | +--ro location* inet:uri > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | +--ro deviation* [module] > | | +--ro module -> ../../name > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro namespace inet:uri > | +--ro location* inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro schema* [name] > | +--ro name string > | +--ro checksum string > | +--ro module-set* -> ../../module-set/name > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > How does this solution handle the use cases above? > > C1: One module-set, one schema, all datastores refer to this schema, > the schema refers to the single module-set. > > C2: Two schemas, "conventional" and "operational", and two > module-sets. One module-set contains just "ietf-hardware" and > the other everything else. The "operational" schema refers to > both module-sets, and the "conventional" to just the one without > "ietf-hardware". > > C3: Two schemas, "conventional" and "operational", and three > module-sets. One module-set contains all modules fully > implemented in both conventional and operational, one contains > the modules implemented only in conventional, and one the > modules and deviations for the partly implemented modules in > operational. > > C4: Three schemas, "conventional", "ephemeral", "operational", but > just two module-sets. "conventional" refers to one of the > module-sets, and "ephemeral" to the other. "operational" refers > to both. > > Pro: less verbose > > Con: the client has to follow extra references and must combine the > result from the references into a single schema. > > > Alt. C. > ------- > > (This is the draft -02 version with just some name changes) > > Each datastore refers to a schema, and each schema contains a list > of references to each module it includes. > > +--ro yang-library > +--ro module* [id] > | +--ro id string > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > | +--ro namespace inet:uri > | +--ro feature* yang:yang-identifier > | +--ro deviation* [module] > | | +--ro module -> ../../id > | +--ro conformance-type enumeration > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro schema* [name] > | +--ro name string > | +--ro module* -> ../../module/id > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > How does this solution handle the use cases above? > > C1: One schema, all datastores refer to this schema, > the schema refers to all modules. > > C2: Two schemas, "conventional" and "operational", and the module > list contains all modules. The "operational" schema refers to > all modules, and "conventional" to all modules except > "ietf-hardware". > > C3: similar to C2, except there will be two entries in the module > list for evenry module that is partly implemented in > operational. > > C4: Three schemas, "conventional", "ephemeral", "operational", and > the module list contains all modules. > Each schema refers to the modules it supports. > > Pro: All modules available are listed in one place. > > Con: the client has to follow extra references and must combine the > result from the references into a single schema. > > the least "direct" solution due to the module "id". > > probably a bit tricky to implement on the server. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Dec 8 03:16:38 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5647E127010 for ; Fri, 8 Dec 2017 03:16:37 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0Ab9ZDgzQCR for ; Fri, 8 Dec 2017 03:16:36 -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 C41631200C1 for ; Fri, 8 Dec 2017 03:16: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 8BF3F9A; Fri, 8 Dec 2017 12:16: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 ARuCkeriahX5; Fri, 8 Dec 2017 12:16:32 +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, 8 Dec 2017 12:16:34 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 785A12012E; Fri, 8 Dec 2017 12:16:34 +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 P_aiD2uEQ1uZ; Fri, 8 Dec 2017 12:16:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C1722012C; Fri, 8 Dec 2017 12:16:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E685C4190D8A; Fri, 8 Dec 2017 12:15:04 +0100 (CET) Date: Fri, 8 Dec 2017 12:15:04 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Martin Bjorklund , netmod@ietf.org Message-ID: <20171208111504.iwpcck3hkbboryeo@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org References: <20171208.104741.1957721911727198135.mbj@tail-f.com> <16035d216a8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16035d216a8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 11:16:37 -0000 On Fri, Dec 08, 2017 at 06:10:49AM -0500, Lou Berger wrote: > Martin, > > Thanks for raising this, there's definitely some open issues as well as > confusion on this topic. In the different options listed below you say that > each datastore refers to a schema, correct? What is the mechanism you would > use to do this? This is in the tree diagrams, e.g. > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > In talking to some others on this topic, they suggested using a library per > datastore. I haven't look into this enough to know if that is a good or bad > idea, but it seems functionally equivalent to your first option but realized > in a different way. Just something to add to the mix. If people want to put additional options on the table, they should work out the details and write down a tree diagram and send the result to the list. /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 Dec 8 04:08:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0296127010 for ; Fri, 8 Dec 2017 04:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 jizh0SkAPyjc for ; Fri, 8 Dec 2017 04:08:41 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 75EB8124B17 for ; Fri, 8 Dec 2017 04:08:41 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id EB038215CF8 for ; Fri, 8 Dec 2017 05:08:36 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id jQ8Z1w00A2SSUrH01Q8cxU; Fri, 08 Dec 2017 05:08:36 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=ocR9PWop10UA:10 a=-11gt19lUDhhv_iUSl8A: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=U5W6kFooZdJ7tiMjAwy2RWWqGSDO9l2xqjyG7wbGofw=; b=C/vziAC2tdxuUBbcAOhg4dRk+8 xruKVL4n8wQjtfrrYge1S2fnUf7I8ay1yBqEwb4Cstp4M852gP1gN1IzKo5HZrBK2G+JjuBHe2aRk SNToq7l6V75gUY2UWIfsxTvl6; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47314 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 1eNHSD-001S7W-4a; Fri, 08 Dec 2017 05:08:33 -0700 To: Martin Bjorklund , netmod@ietf.org References: <20171208.104741.1957721911727198135.mbj@tail-f.com> <16035d216a8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171208111504.iwpcck3hkbboryeo@elstar.local> From: Lou Berger Message-ID: Date: Fri, 8 Dec 2017 07:08:32 -0500 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: <20171208111504.iwpcck3hkbboryeo@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: 1eNHSD-001S7W-4a 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]:47314 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 12:08:43 -0000 On 12/08/2017 06:15 AM, Juergen Schoenwaelder wrote: > >> In talking to some others on this topic, they suggested using a library per >> datastore. I haven't look into this enough to know if that is a good or bad >> idea, but it seems functionally equivalent to your first option but realized >> in a different way. Just something to add to the mix. > If people want to put additional options on the table, they should > work out the details and write down a tree diagram and send the result > to the list. I guess we have a different philosophical approach here. I'd prefer to hear about fresh ideas, even if half baked or asked as a "stupid question". Sometimes, if not dismissed out of hand, these lead to something that is a better result than others that have been immersed in the issue have thought of. Lou From nobody Fri Dec 8 04:10:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9191200C1 for ; Fri, 8 Dec 2017 04:10:11 -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 uvdVTNgmNdkn for ; Fri, 8 Dec 2017 04:10:09 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3E092124D68 for ; Fri, 8 Dec 2017 04:10:09 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 7301D18215DC; Fri, 8 Dec 2017 13:10:05 +0100 (CET) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 777991820E6E; Fri, 8 Dec 2017 13:09:57 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20171208.104741.1957721911727198135.mbj@tail-f.com> References: <20171208.104741.1957721911727198135.mbj@tail-f.com> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Fri, 08 Dec 2017 13:09:58 +0100 Message-ID: <874lp1a0a1.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 12:10:12 -0000 Martin Bjorklund writes: > Hi, > > There has been quite a lot of discussion about the YANG library > data model on the list. The authors of draft-ietf-netconf-rfc7895bis > have tried to understand all arguments in the discussion, and provide > a solution. Below are 3 solution proposals (we have discussed more, > but they are basically just variations on the same themes). > > Absolute Requirements > --------------------- > > o RFC 7950, Section 5.6.5 says: > > A server MUST NOT implement more than one revision of a module. I believe YANG library should be liberated from the dependence on servers and protocols and become part of a formal data model specification. It is not just some state data but rather metadata, and it is also perfectly conceivable that a server does not publish its YANG library at all (e.g. for security reasons or constrained devices). And then, I would suggest to consider dropping the above requirement for the *general* YANG library, i.e. design it so that it can in principle support multiple revisions of the same module. This is important because - it allows for supporting multiple revisions of some hardware (e.g. line cards) in the same device - the server needn't represent just a single device but may be used for configuring a network of devices, and then the above restriction could be severely limiting. This said, it would still be possible for a specific protocol to impose such a restriction. ... > > Alt. B. > ------- > > Each datastore refers to a schema, and each schema contains a list > of references to module-sets, and each module-set contains a flat > list of all modules, features, etc. I like this one because different schemas will often need to reuse the same module sets, and it will also be quite easy to add schema mount specification to this. Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Dec 8 04:16:08 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5008F120454 for ; Fri, 8 Dec 2017 04:16:07 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9-IZQiq7LzG for ; Fri, 8 Dec 2017 04:16: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 5F15B1200C1 for ; Fri, 8 Dec 2017 04:16:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2C5D56AC; Fri, 8 Dec 2017 13:16:04 +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 2LSTTdtHxP3q; Fri, 8 Dec 2017 13:16: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, 8 Dec 2017 13:16:04 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18AF42012C; Fri, 8 Dec 2017 13:16:04 +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 7ucP9zPig2X3; Fri, 8 Dec 2017 13:16:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6638420129; Fri, 8 Dec 2017 13:16:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 53D0A4190FE4; Fri, 8 Dec 2017 13:14:34 +0100 (CET) Date: Fri, 8 Dec 2017 13:14:34 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Martin Bjorklund , netmod@ietf.org Message-ID: <20171208121434.2vfbrc5pdbwnx3ig@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org References: <20171208.104741.1957721911727198135.mbj@tail-f.com> <16035d216a8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171208111504.iwpcck3hkbboryeo@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 12:16:07 -0000 On Fri, Dec 08, 2017 at 07:08:32AM -0500, Lou Berger wrote: > On 12/08/2017 06:15 AM, Juergen Schoenwaelder wrote: > > > >> In talking to some others on this topic, they suggested using a library per > >> datastore. I haven't look into this enough to know if that is a good or bad > >> idea, but it seems functionally equivalent to your first option but realized > >> in a different way. Just something to add to the mix. > > If people want to put additional options on the table, they should > > work out the details and write down a tree diagram and send the result > > to the list. > > I guess we have a different philosophical approach here. I'd prefer to > hear about fresh ideas, even if half baked or asked as a "stupid > question". Sometimes, if not dismissed out of hand, these lead to > something that is a better result than others that have been immersed in > the issue have thought of. > The devil is usally in the details and 'using a library per datastore' is for my taste a bit too little to understand what is actually being proposed. I am not dismissing proposals, but I like to be able to understand what is being proposed. And for that I need a proposal that is a bit more than 'using a library per 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 Fri Dec 8 06:08:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F537124D68 for ; Fri, 8 Dec 2017 06:08: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 r55F94xx61bR for ; Fri, 8 Dec 2017 06:08:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C33B1124D37 for ; Fri, 8 Dec 2017 06:08:34 -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 7C1F41AE0398; Fri, 8 Dec 2017 15:08:31 +0100 (CET) Date: Fri, 08 Dec 2017 15:08:31 +0100 (CET) Message-Id: <20171208.150831.2068512524982133442.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: lberger@labn.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20171208121434.2vfbrc5pdbwnx3ig@elstar.local> References: <20171208111504.iwpcck3hkbboryeo@elstar.local> <20171208121434.2vfbrc5pdbwnx3ig@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] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 14:08:36 -0000 Juergen Schoenwaelder wrote: > On Fri, Dec 08, 2017 at 07:08:32AM -0500, Lou Berger wrote: > > On 12/08/2017 06:15 AM, Juergen Schoenwaelder wrote: > > > > > >> In talking to some others on this topic, they suggested using a library per > > >> datastore. I haven't look into this enough to know if that is a good or bad > > >> idea, but it seems functionally equivalent to your first option but realized > > >> in a different way. Just something to add to the mix. > > > If people want to put additional options on the table, they should > > > work out the details and write down a tree diagram and send the result > > > to the list. > > > > I guess we have a different philosophical approach here. I'd prefer to > > hear about fresh ideas, even if half baked or asked as a "stupid > > question". Sometimes, if not dismissed out of hand, these lead to > > something that is a better result than others that have been immersed in > > the issue have thought of. > > > > The devil is usally in the details and 'using a library per datastore' > is for my taste a bit too little to understand what is actually being > proposed. I am not dismissing proposals, but I like to be able to > understand what is being proposed. And for that I need a proposal that > is a bit more than 'using a library per datastore'. I agree. In this case, I can't understand how it would work at all. The library is config false, so a client can never get it via get-config from . Maybe the proposal is a new operation with the datastore as a parameter? Or maybe the idea is to somehow return meta data together with ? I can guess, and dismiss the proposal based on my guesses ;-) Or someone can write up a concrete proposal. /martin From nobody Fri Dec 8 06:36:27 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA75124D37 for ; Fri, 8 Dec 2017 06:36:25 -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 iv86Yz3O58iS for ; Fri, 8 Dec 2017 06:36:22 -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 6695A1243FE for ; Fri, 8 Dec 2017 06:36:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id A61E51540892; Fri, 8 Dec 2017 15:36:20 +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 wDMKGCuadGUC; Fri, 8 Dec 2017 15:36:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7ADC71540898; Fri, 8 Dec 2017 15:36:20 +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 OPJ6-2eeHT8l; Fri, 8 Dec 2017 15:36:20 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 560941540892; Fri, 8 Dec 2017 15:36:20 +0100 (CET) To: Robert Wilton , "netmod@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> From: Vladimir Vassilev Message-ID: <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> Date: Fri, 8 Dec 2017 15:36:20 +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: <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 14:36:26 -0000 On 11/15/2017 06:29 PM, Robert Wilton wrote: > I don't think that this is really a good idea.=C2=A0 You would end up=20 > returning server metadata in addition to the configuration. Obviously RFC 7895 defines only config false; data and I was not=20 proposing a change to that. But I agree something has to be added to=20 complete the solution. Special purpose datastore identities can be=20 defined that return instance of yang-library data when read with=20 . (Datastores with yang-library config false; only data not=20 represented in 'operational') Adding this special yang-library-datastore to the proposed=20 ietf-datastores container e.g. module: ietf-datastores +--ro datastores |=C2=A0 +--ro datastore* [name] |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 identityref |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref Notifications can indicate which yang-library-datastore is their origin=20 (adding optional parameter in ietf-datastores through augmentation to=20 the notifications in ietf-yang-library). > > I still think that the YANG library proposal is the best solution. The solution I propose has an obvious advantage for all designing=20 systems that use single model for operational and the configuration=20 datastores in terms of keeping the already implemented model and full=20 backward compatibility without maintaining the obsolete /modules-state=20 container in addition to any of the 3 proposals with additional=20 indirection layers added. I am not sure if there are any disadvantages=20 for the rest but I would like to read some arguments. Vladimir > > Thanks, > Rob > > > On 16/11/2017 01:21, Vladimir Vassilev wrote: >> Hello, >> >> I have a proposal based on that provides an elegant=20 >> solution to consider as a 3rd option.=C2=A0 It is based on keeping exa= ctly=20 >> the same model as in RFC 7895 and using RPC to retrieve=20 >> datastore specific yang-library instance data in a similar way one=20 >> would use to retrieve the datastore contents. In addition=20 >> a top level config=3Dfalse container e.g. /datastores with list of=20 >> supported datastores that does not need to be part of the=20 >> yang-library module: >> >> module: ietf-datastores >> +--ro datastores >> |=C2=A0 +--ro datastore* [name] >> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 identityref >> >> Vladimir >> >> On 11/09/2017 05:51 PM, Robert Wilton wrote: >>> >>> Hi, >>> >>> Given some of the feedback related to the complexity of the YANG=20 >>> library bis structure, we have come up with two other possible=20 >>> structures for the YANG library data: >>> >>> (1) A simplified structure to make YANG library meet the NMDA=20 >>> requirements, but that is closer to the existing YANG library=20 >>> structure, and arguably simpler. >>> (2) An enhanced version of the structure (1) above, that is also=20 >>> extended to allow the structure to be reused for schema-mount via an=20 >>> augmentation. >>> >>> For reference, at the end of this email, I have also included the=20 >>> tree diagram of the existing YANG library, and the current YANG=20 >>> library bis draft (draft-ietf-netconf-rfc7895bis-02) version. >>> >>> Considering the two new YANG library structures: >>> >>> ------------------------ >>> >>> *(1) A simplified structure to make YANG library meet the NMDA=20 >>> requirements, but that is closer to the existing YANG library=20 >>> structure.* >>> >>> The main changes are: >>> (i) Split "implemented modules" and "import-only-modules" into two=20 >>> separate lists, making the most important list (i.e. implemented=20 >>> modules) keyed by module name only and hence easier to reference. >>> (ii) Assume modules are implemented in all datastores by default=20 >>> (with a "not-implemented-in" leaflist of datastores that a module is=20 >>> not implemented in). >>> (iii) Assume that features are implemented in all datastores by=20 >>> default (with a "not-implemented-in" leaflist of datastores that a=20 >>> feature is not implemented in). >>> (iv) Deleted module-sets. >>> (v) Datastores are now just a list of supported datastores (that=20 >>> could potentially be extended with further per datastore properties=20 >>> in future). >>> >>> Manually generated tree output for proposed YANG library: >>> >>> module: ietf-yang-library >>> =C2=A0+--ro yang-library >>> =C2=A0=C2=A0=C2=A0 +--ro modules >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name] >>> =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=C2=A0=C2=A0=C2=A0 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 revision-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name] >>> =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 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0= yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2= =A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in* >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/= name >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name] >>> =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 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in* >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/= name >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation* >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 | >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name revision] >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-ide= ntifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [name] >>> =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 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro = revision yang:revision-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro = schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future per datas= tore properties. >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 identityref >>> =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= string >>> >>> ------------------------------ >>> >>> *(2) An enhanced version of the structure (1) above, that is=20 >>> extended to allow the structure to be reused for schema-mount via an=20 >>> augmentation.* >>> >>> This is similar to the structure above, except that the "the set of=20 >>> modules" is contained in a list of named schema (e.g. similar to the=20 >>> schema mount draft), allowing this structure to be re-used for=20 >>> schema mount. >>> >>> Schema mount would be expected to augment yang-library to add in the=20 >>> additional schema mount information.=C2=A0 In the tree diagram, I hav= e=20 >>> shown the schema-mount mount-point augmentation, but not including=20 >>> namespaces yet. >>> >>> Every server would be required to provide at least one schema in the=20 >>> schema list, and the primary schema for the device would always be=20 >>> given the name "primary". >>> >>> module: ietf-yang-library >>> =C2=A0+--ro yang-library >>> =C2=A0=C2=A0=C2=A0 +--ro schema* [name] >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 string >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 string >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name] >>> =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=C2=A0=C2=A0=C2=A0 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision? yang:revision-iden= tifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name] >>> =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 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0= yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2= =A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in* >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/= name >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name] >>> =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 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in* >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/= name >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation* >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount-point* [labe= l] >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro label yang= :yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro config?=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (schema-re= f) >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--:(inline) >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--:(use-schema) >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--ro use-schema* [name] >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -> /yang-library/schema/name >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro parent-reference* yang:xpath1.= 0 >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 | >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name revision] >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-ide= ntifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [name] >>> =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 yang:yang-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro = revision yang:revision-identifier >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro = schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri >>> =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future per datas= tore properties. >>> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 identityref >>> =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= string >>> >>> Please can you provide comments on these structures, in particular: >>> >>> Is this version better (i.e. simpler) that the version currently in=20 >>> draft-ietf-netconf-rfc7895bis-02 (below)? >>> >>> Should we try and make the structure extensible for schema-mount via=20 >>> augmentation (i.e. version (2)), or is it better that schema-mount=20 >>> has its own separate subtree? >>> >>> For reference only I have included the existing YANG library and=20 >>> YANG library bis draft tree diagrams. >>> >>> Thanks, >>> Rob >>> >>> >>> ----------------------------- >>> >>> *** FOR REFERENCE ONLY *** >>> >>> (3)=C2=A0 The current YANG library structure in YANG library bis=20 >>> (draft-ietf-netconf-rfc7895bis-02) >>> >>> module: ietf-yang-library >>> +--ro yang-library >>> +--ro modules >>> | +--ro module* [id] >>> | +--ro id string >>> | +--ro name yang:yang-identifier >>> | +--ro revision? revision-identifier >>> | +--ro schema? inet:uri >>> | +--ro namespace inet:uri >>> | +--ro feature* yang:yang-identifier >>> | +--ro deviation* [module] >>> | | +--ro module -> ../../id >>> | +--ro conformance-type enumeration >>> | +--ro submodule* [name] >>> | +--ro name yang:yang-identifier >>> | +--ro revision? revision-identifier >>> | +--ro schema? inet:uri >>> +--ro module-sets >>> | +--ro module-set* [id] >>> | +--ro id string >>> | +--ro module* -> ../../../modules/module/id >>> +--ro datastores >>> | +--ro datastore* [name] >>> | +--ro name identityref >>> | +--ro module-set >>> | -> ../../../module-sets/module-set/id >>> +--ro checksum string >>> >>> ----------------------------- >>> >>> *** FOR REFERENCE ONLY *** >>> >>> (4)=C2=A0 The current YANG library structure (RFC 7895) >>> >>> +--ro modules-state >>> +--ro module-set-id string >>> +--ro module* [name revision] >>> +--ro name yang:yang-identifier >>> +--ro revision union >>> +--ro schema? inet:uri >>> +--ro namespace inet:uri >>> +--ro feature* yang:yang-identifier >>> +--ro deviation* [name revision] >>> | +--ro name yang:yang-identifier >>> | +--ro revision union >>> +--ro conformance-type enumeration >>> +--ro submodule* [name revision] >>> +--ro name yang:yang-identifier >>> +--ro revision union >>> +--ro schema? inet:uri >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> > From nobody Fri Dec 8 06:52:04 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64971243FE for ; Fri, 8 Dec 2017 06:52: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 UBqv6C__MrM9 for ; Fri, 8 Dec 2017 06:52:01 -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 40778126E64 for ; Fri, 8 Dec 2017 06:52:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7E1AE154089A; Fri, 8 Dec 2017 15:51:43 +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 om5NneavN0XH; Fri, 8 Dec 2017 15:51:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 54600154089E; Fri, 8 Dec 2017 15:51:43 +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 gSDmLh43B8G4; Fri, 8 Dec 2017 15:51:43 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 2E19F154089A; Fri, 8 Dec 2017 15:51:43 +0100 (CET) To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org References: <20171208111504.iwpcck3hkbboryeo@elstar.local> <20171208121434.2vfbrc5pdbwnx3ig@elstar.local> <20171208.150831.2068512524982133442.mbj@tail-f.com> From: Vladimir Vassilev Message-ID: Date: Fri, 8 Dec 2017 15:51:42 +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: <20171208.150831.2068512524982133442.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nb Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 14:52:03 -0000 On 12/08/2017 03:08 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Fri, Dec 08, 2017 at 07:08:32AM -0500, Lou Berger wrote: >>> On 12/08/2017 06:15 AM, Juergen Schoenwaelder wrote: >>>> >>>>> In talking to some others on this topic, they suggested using a library per >>>>> datastore. I haven't look into this enough to know if that is a good or bad >>>>> idea, but it seems functionally equivalent to your first option but realized >>>>> in a different way. Just something to add to the mix. >>>> If people want to put additional options on the table, they should >>>> work out the details and write down a tree diagram and send the result >>>> to the list. >>> I guess we have a different philosophical approach here. I'd prefer to >>> hear about fresh ideas, even if half baked or asked as a "stupid >>> question". Sometimes, if not dismissed out of hand, these lead to >>> something that is a better result than others that have been immersed in >>> the issue have thought of. >>> >> The devil is usally in the details and 'using a library per datastore' >> is for my taste a bit too little to understand what is actually being >> proposed. I am not dismissing proposals, but I like to be able to >> understand what is being proposed. And for that I need a proposal that >> is a bit more than 'using a library per datastore'. > I agree. In this case, I can't understand how it would work at all. > The library is config false, so a client can never get it via > get-config from . Maybe the proposal is a new operation > with the datastore as a parameter? Or maybe the > idea is to somehow return meta data together with ? I can > guess, and dismiss the proposal based on my guesses ;-) Or someone > can write up a concrete proposal. I just posted a followup on a relevant proposal in a thread "[netmod] [Netconf] Alternative YANG library structure for 7895bis". Vladimir > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 8 07:03:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D74124D68 for ; Fri, 8 Dec 2017 07:03:20 -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 fK3xBuqJM-IB for ; Fri, 8 Dec 2017 07:03:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B834F1243FE for ; Fri, 8 Dec 2017 07:03: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 7DC8E1AE0398; Fri, 8 Dec 2017 16:03:06 +0100 (CET) Date: Fri, 08 Dec 2017 16:03:06 +0100 (CET) Message-Id: <20171208.160306.109290175567894287.mbj@tail-f.com> To: vladimir@transpacket.com Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.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] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 15:03:21 -0000 Vladimir Vassilev wrote: > On 11/15/2017 06:29 PM, Robert Wilton wrote: > = > > I don't think that this is really a good idea.=A0 You would end up > > returning server metadata in addition to the configuration. > Obviously RFC 7895 defines only config false; data and I was not > proposing a change to that. But I agree something has to be added to > complete the solution. Special purpose datastore identities can be > defined that return instance of yang-library data when read with > . (Datastores with yang-library config false; only data not= > represented in 'operational') > = > Adding this special yang-library-datastore to the proposed > ietf-datastores container e.g. > = > module: ietf-datastores > +--ro datastores > |=A0 +--ro datastore* [name] > |=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityref > |=A0=A0=A0=A0 +--ro yang-library-datastore =A0=A0=A0=A0=A0=A0=A0=A0 i= dentityref > = I don't understand this proposal. How would a client learn the library for ? For ? /martin > Notifications can indicate which yang-library-datastore is their > origin (adding optional parameter in ietf-datastores through > augmentation to the notifications in ietf-yang-library). > = > > > > I still think that the YANG library proposal is the best solution. > The solution I propose has an obvious advantage for all designing > systems that use single model for operational and the configuration > datastores in terms of keeping the already implemented model and full= > backward compatibility without maintaining the obsolete /modules-stat= e > container in addition to any of the 3 proposals with additional > indirection layers added. I am not sure if there are any disadvantage= s > for the rest but I would like to read some arguments. > = > Vladimir > > > > Thanks, > > Rob > > > > > > On 16/11/2017 01:21, Vladimir Vassilev wrote: > >> Hello, > >> > >> I have a proposal based on that provides an elegant > >> solution to consider as a 3rd option.=A0 It is based on keeping ex= actly > >> the same model as in RFC 7895 and using RPC to retrieve= > >> datastore specific yang-library instance data in a similar way one= > >> would use to retrieve the datastore contents. In additi= on a > >> top level config=3Dfalse container e.g. /datastores with list of > >> supported datastores that does not need to be part of the yang-lib= rary > >> module: > >> > >> module: ietf-datastores > >> +--ro datastores > >> |=A0 +--ro datastore* [name] > >> |=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityref > >> > >> Vladimir > >> > >> On 11/09/2017 05:51 PM, Robert Wilton wrote: > >>> > >>> Hi, > >>> > >>> Given some of the feedback related to the complexity of the YANG > >>> library bis structure, we have come up with two other possible > >>> structures for the YANG library data: > >>> > >>> (1) A simplified structure to make YANG library meet the NMDA > >>> requirements, but that is closer to the existing YANG library > >>> structure, and arguably simpler. > >>> (2) An enhanced version of the structure (1) above, that is also > >>> extended to allow the structure to be reused for schema-mount via= an > >>> augmentation. > >>> > >>> For reference, at the end of this email, I have also included the= tree > >>> diagram of the existing YANG library, and the current YANG librar= y bis > >>> draft (draft-ietf-netconf-rfc7895bis-02) version. > >>> > >>> Considering the two new YANG library structures: > >>> > >>> ------------------------ > >>> > >>> *(1) A simplified structure to make YANG library meet the NMDA > >>> *requirements, but that is closer to the existing YANG library > >>> *structure.* > >>> > >>> The main changes are: > >>> (i) Split "implemented modules" and "import-only-modules" into tw= o > >>> separate lists, making the most important list (i.e. implemented > >>> modules) keyed by module name only and hence easier to reference.= > >>> (ii) Assume modules are implemented in all datastores by default = (with > >>> a "not-implemented-in" leaflist of datastores that a module is no= t > >>> implemented in). > >>> (iii) Assume that features are implemented in all datastores by > >>> default (with a "not-implemented-in" leaflist of datastores that = a > >>> feature is not implemented in). > >>> (iv) Deleted module-sets. > >>> (v) Datastores are now just a list of supported datastores (that = could > >>> potentially be extended with further per datastore properties in > >>> future). > >>> > >>> Manually generated tree output for proposed YANG library: > >>> > >>> module: ietf-yang-library > >>> =A0+--ro yang-library > >>> =A0=A0=A0 +--ro modules > >>> =A0=A0=A0 |=A0 +--ro module* [name] > >>> =A0=A0=A0 |=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 yang= :yang-identifier > >>> =A0=A0=A0 |=A0 |=A0 +--ro revision?=A0=A0=A0=A0=A0 revision-ident= ifier > >>> =A0=A0=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0=A0=A0=A0 inet:uri > >>> =A0=A0=A0 |=A0 |=A0 +--ro namespace=A0=A0=A0=A0=A0 inet:uri > >>> =A0=A0=A0 |=A0 |=A0 +--ro submodule* [name] > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0 yang:yan= g-identifier > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro revision?=A0=A0 yang:yang-identifi= er > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0 inet:uri > >>> =A0=A0=A0 |=A0 |=A0 +--ro not-implemented-in* > >>> =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -> /= yang-library/datastore/name > >>> =A0=A0=A0 |=A0 |=A0 +--ro feature* [name] > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0 yang:yan= g-identifier > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro not-implemented-in* > >>> =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -> /= yang-library/datastore/name > >>> =A0=A0=A0 |=A0 |=A0 +--ro deviation* > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = -> ../name > >>> =A0=A0=A0 |=A0 | > >>> =A0=A0=A0 |=A0 +--ro import-only-module* [name revision] > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro name yang:yang-identifier > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro revision=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 union > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro schema?=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 inet:uri > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro namespace=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 inet:uri > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro submodule* [name] > >>> =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0 = yang:yang-identifier > >>> =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro revision yang:revision-ide= ntifier > >>> =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro schema?=A0=A0=A0=A0 inet:u= ri > >>> =A0=A0=A0 +--ro datastore* [name] // Allows future per datastore = properties. > >>> =A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityref > >>> =A0=A0=A0 +--ro checksum=A0=A0=A0=A0=A0=A0 string > >>> > >>> ------------------------------ > >>> > >>> *(2) An enhanced version of the structure (1) above, that is exte= nded > >>> *to allow the structure to be reused for schema-mount via an > >>> *augmentation.* > >>> > >>> This is similar to the structure above, except that the "the set = of > >>> modules" is contained in a list of named schema (e.g. similar to = the > >>> schema mount draft), allowing this structure to be re-used for sc= hema > >>> mount. > >>> > >>> Schema mount would be expected to augment yang-library to add in = the > >>> additional schema mount information.=A0 In the tree diagram, I ha= ve > >>> shown the schema-mount mount-point augmentation, but not includin= g > >>> namespaces yet. > >>> > >>> Every server would be required to provide at least one schema in = the > >>> schema list, and the primary schema for the device would always b= e > >>> given the name "primary". > >>> > >>> module: ietf-yang-library > >>> =A0+--ro yang-library > >>> =A0=A0=A0 +--ro schema* [name] > >>> =A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 string > >>> =A0=A0=A0 |=A0 +--ro checksum=A0=A0=A0=A0=A0=A0 string > >>> =A0=A0=A0 |=A0 +--ro module* [name] > >>> =A0=A0=A0 |=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 yang= :yang-identifier > >>> =A0=A0=A0 |=A0 |=A0 +--ro revision? yang:revision-identifier > >>> =A0=A0=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0=A0=A0=A0 inet:uri > >>> =A0=A0=A0 |=A0 |=A0 +--ro namespace=A0=A0=A0=A0=A0 inet:uri > >>> =A0=A0=A0 |=A0 |=A0 +--ro submodule* [name] > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0 yang:yan= g-identifier > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro revision?=A0=A0 yang:yang-identifi= er > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0 inet:uri > >>> =A0=A0=A0 |=A0 |=A0 +--ro not-implemented-in* > >>> =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -> /= yang-library/datastore/name > >>> =A0=A0=A0 |=A0 |=A0 +--ro feature* [name] > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0 yang:yan= g-identifier > >>> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro not-implemented-in* > >>> =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -> /= yang-library/datastore/name > >>> =A0=A0=A0 |=A0 |=A0 +--ro deviation* > >>> =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -> .= ./name > >>> =A0=A0=A0 |=A0 |=A0 +- schema-mount:mount-point* [label] > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0 +--ro label yang:yang-identifier > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0 +--ro config?=A0=A0=A0=A0=A0=A0 bool= ean > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0 +--ro (schema-ref) > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0 +--:(inline) > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro inline?=A0=A0=A0= =A0=A0=A0 empty > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0 +--:(use-schema) > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro use-schema* = [name] > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro nam= e > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0= =A0=A0=A0 -> /yang-library/schema/name > >>> =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro par= ent-reference* yang:xpath1.0 > >>> =A0=A0=A0 |=A0 | > >>> =A0=A0=A0 |=A0 +--ro import-only-module* [name revision] > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro name yang:yang-identifier > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro revision=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 union > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro schema?=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 inet:uri > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro namespace=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 inet:uri > >>> =A0=A0=A0 |=A0=A0=A0=A0 +--ro submodule* [name] > >>> =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0 = yang:yang-identifier > >>> =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro revision yang:revision-ide= ntifier > >>> =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro schema?=A0=A0=A0=A0 inet:u= ri > >>> =A0=A0=A0 +--ro datastore* [name] // Allows future per datastore = properties. > >>> =A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityref > >>> =A0=A0=A0 +--ro checksum=A0=A0=A0=A0=A0=A0 string > >>> > >>> Please can you provide comments on these structures, in particula= r: > >>> > >>> Is this version better (i.e. simpler) that the version currently = in > >>> draft-ietf-netconf-rfc7895bis-02 (below)? > >>> > >>> Should we try and make the structure extensible for schema-mount = via > >>> augmentation (i.e. version (2)), or is it better that schema-moun= t has > >>> its own separate subtree? > >>> > >>> For reference only I have included the existing YANG library and = YANG > >>> library bis draft tree diagrams. > >>> > >>> Thanks, > >>> Rob > >>> > >>> > >>> ----------------------------- > >>> > >>> *** FOR REFERENCE ONLY *** > >>> > >>> (3)=A0 The current YANG library structure in YANG library bis > >>> (draft-ietf-netconf-rfc7895bis-02) > >>> > >>> module: ietf-yang-library > >>> +--ro yang-library > >>> +--ro modules > >>> | +--ro module* [id] > >>> | +--ro id string > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision? revision-identifier > >>> | +--ro schema? inet:uri > >>> | +--ro namespace inet:uri > >>> | +--ro feature* yang:yang-identifier > >>> | +--ro deviation* [module] > >>> | | +--ro module -> ../../id > >>> | +--ro conformance-type enumeration > >>> | +--ro submodule* [name] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision? revision-identifier > >>> | +--ro schema? inet:uri > >>> +--ro module-sets > >>> | +--ro module-set* [id] > >>> | +--ro id string > >>> | +--ro module* -> ../../../modules/module/id > >>> +--ro datastores > >>> | +--ro datastore* [name] > >>> | +--ro name identityref > >>> | +--ro module-set > >>> | -> ../../../module-sets/module-set/id > >>> +--ro checksum string > >>> > >>> ----------------------------- > >>> > >>> *** FOR REFERENCE ONLY *** > >>> > >>> (4)=A0 The current YANG library structure (RFC 7895) > >>> > >>> +--ro modules-state > >>> +--ro module-set-id string > >>> +--ro module* [name revision] > >>> +--ro name yang:yang-identifier > >>> +--ro revision union > >>> +--ro schema? inet:uri > >>> +--ro namespace inet:uri > >>> +--ro feature* yang:yang-identifier > >>> +--ro deviation* [name revision] > >>> | +--ro name yang:yang-identifier > >>> | +--ro revision union > >>> +--ro conformance-type enumeration > >>> +--ro submodule* [name revision] > >>> +--ro name yang:yang-identifier > >>> +--ro revision union > >>> +--ro schema? inet:uri > >>> > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > > > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 8 07:07:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42A71243FE for ; Fri, 8 Dec 2017 07:07:55 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9cL0a7v-Gpz for ; Fri, 8 Dec 2017 07:07:52 -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 773E91200C1 for ; Fri, 8 Dec 2017 07:07:52 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7895DFBE; Fri, 8 Dec 2017 16:07:44 +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 u0HNARn6DytE; Fri, 8 Dec 2017 16:07:42 +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, 8 Dec 2017 16:07:44 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 657522012C; Fri, 8 Dec 2017 16:07:44 +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 IGI-MrhDCfUj; Fri, 8 Dec 2017 16:07:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E574420129; Fri, 8 Dec 2017 16:07:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D5D8F419135D; Fri, 8 Dec 2017 16:06:14 +0100 (CET) Date: Fri, 8 Dec 2017 16:06:14 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: vladimir@transpacket.com, netmod@ietf.org Message-ID: <20171208150614.axuynu4atpg7aaj2@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , vladimir@transpacket.com, netmod@ietf.org References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.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: <20171208.160306.109290175567894287.mbj@tail-f.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 15:07:56 -0000 On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: > Vladimir Vassilev wrote: > > On 11/15/2017 06:29 PM, Robert Wilton wrote: > > > > > I don't think that this is really a good idea. You would end up > > > returning server metadata in addition to the configuration. > > Obviously RFC 7895 defines only config false; data and I was not > > proposing a change to that. But I agree something has to be added to > > complete the solution. Special purpose datastore identities can be > > defined that return instance of yang-library data when read with > > . (Datastores with yang-library config false; only data not > > represented in 'operational') > > > > Adding this special yang-library-datastore to the proposed > > ietf-datastores container e.g. > > > > module: ietf-datastores > > +--ro datastores > > | +--ro datastore* [name] > > | +--ro name identityref > > | +--ro yang-library-datastore identityref > > > > I don't understand this proposal. How would a client learn the > library for ? For ? My interpretation is that the client reads the datastores list from and the list entries give you the identity of a separate datastore that gives you the content of the yang library for that datastore. (For each datastore, you have a separate datastore to report its yang library.) /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 Dec 8 07:19:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A165126B7F for ; Fri, 8 Dec 2017 07:19:33 -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 x51HgMbxUXWU for ; Fri, 8 Dec 2017 07:19:32 -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 D56611200C1 for ; Fri, 8 Dec 2017 07:19:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 93C3A1540909; Fri, 8 Dec 2017 16:19:29 +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 UMkfFC-YwEqv; Fri, 8 Dec 2017 16:19:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 642FD154090C; Fri, 8 Dec 2017 16:19:29 +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 9tf1-urcIt1c; Fri, 8 Dec 2017 16:19:29 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 3FB0E1540909; Fri, 8 Dec 2017 16:19:29 +0100 (CET) To: Martin Bjorklund , netmod@ietf.org References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> From: Vladimir Vassilev Message-ID: Date: Fri, 8 Dec 2017 16:19:28 +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: <20171208150614.axuynu4atpg7aaj2@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 15:19:33 -0000 On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: > On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: >> Vladimir Vassilev wrote: >>> On 11/15/2017 06:29 PM, Robert Wilton wrote: >>> >>>> I don't think that this is really a good idea.=C2=A0 You would end u= p >>>> returning server metadata in addition to the configuration. >>> Obviously RFC 7895 defines only config false; data and I was not >>> proposing a change to that. But I agree something has to be added to >>> complete the solution. Special purpose datastore identities can be >>> defined that return instance of yang-library data when read with >>> . (Datastores with yang-library config false; only data not >>> represented in 'operational') >>> >>> Adding this special yang-library-datastore to the proposed >>> ietf-datastores container e.g. >>> >>> module: ietf-datastores >>> +--ro datastores >>> |=C2=A0 +--ro datastore* [name] >>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 identityref >>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref >>> >> I don't understand this proposal. How would a client learn the >> library for ? For ? > My interpretation is that the client reads the datastores list from > and the list entries give you the identity of a separate > datastore that gives you the content of the yang library for that > datastore. (For each datastore, you have a separate datastore to > report its yang library.) Yes. The default value for yang-library-datastore leaf is ds:operational=20 (the only possible one for the ds:operational datastore). This is=20 backward compatible. If one needs different model for 'running', etc.=20 then a new datastore identity has to be defined=C2=A0 and set in place of= the=20 default value. Then this identity can be used to read the yang-library=20 data with . Vladimir > > /js > From nobody Fri Dec 8 07:32:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDC0126E64 for ; Fri, 8 Dec 2017 07:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZUtyfad19VO for ; Fri, 8 Dec 2017 07:32:20 -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 D996A120721 for ; Fri, 8 Dec 2017 07:32:19 -0800 (PST) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 3F2E363E4D for ; Fri, 8 Dec 2017 16:32:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512747138; bh=t+N+VNTwotIfiJyINTjR/j3+AzjT1npbRE9imHr7CO0=; h=From:To:Date; b=lgjnpk2TNO0zFxEXU8jNEXVeRo9qQaIZijHjuNZQSUmR+N6vsr7QLklykTgywNujW qsehkitWHaboXHApEDaZXeh3ZpGRZ3Nv53QY0WoHIW4mFkjjFOubH17Y/g73mVr6rX QVA2Yl2wnSo5Pq51CxQ1/R44O8zeB5LIVm1XMm4Q= Message-ID: <1512747137.3467.71.camel@nic.cz> From: Ladislav Lhotka To: NETMOD WG Date: Fri, 08 Dec 2017 16:32:17 +0100 Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] 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, 08 Dec 2017 15:32:22 -0000 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 From nobody Fri Dec 8 07:36:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC501243F6 for ; Fri, 8 Dec 2017 07:36:15 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGUtqHC43PMW for ; Fri, 8 Dec 2017 07:36:14 -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 03AF91200C1 for ; Fri, 8 Dec 2017 07:36: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 BD9D569; Fri, 8 Dec 2017 16:36:12 +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 osnlh0Nh_Auv; Fri, 8 Dec 2017 16:36:10 +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, 8 Dec 2017 16:36:12 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA76A2012C; Fri, 8 Dec 2017 16:36:12 +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 cMgYV7QXZpSS; Fri, 8 Dec 2017 16:36:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2B2420129; Fri, 8 Dec 2017 16:36:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B61DB4191482; Fri, 8 Dec 2017 16:34:42 +0100 (CET) Date: Fri, 8 Dec 2017 16:34:42 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Cc: Martin Bjorklund , netmod@ietf.org Message-ID: <20171208153442.roomf7rhixtckrfk@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Vladimir Vassilev , Martin Bjorklund , netmod@ietf.org References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@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/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 15:36:15 -0000 On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: > > Yes. The default value for yang-library-datastore leaf is ds:operational > (the only possible one for the ds:operational datastore). This is backward > compatible. If one needs different model for 'running', etc. then a new > datastore identity has to be defined and set in place of the default value. > Then this identity can be used to read the yang-library data with > . > Sorry, but I have to ask this: How do I obtain the schema for the datastore (lets call it ) that reports the schema for ? Is there another datastore? Will the recursion end? Perhaps it does since might have itself listed as the schema defining datastore. I guess Lada will like these kind of meta and meta-meta datastores. /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 Dec 8 08:11:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7184F127005 for ; Fri, 8 Dec 2017 08:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 NRP1acHEuFwZ for ; Fri, 8 Dec 2017 08:11:44 -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 805BE126B6D for ; Fri, 8 Dec 2017 08:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5111; q=dns/txt; s=iport; t=1512749503; x=1513959103; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=6YCPX/03VqIadVtRq+gW2kVyO+6abyb8PGETpJ42f1Q=; b=igJVcupjkljpZCq2WJyGSXLc7UJvedPu89BPcLpnugFKn5fkLaRFVTbv MsX7cv9LC7/2Xk7o0LoHgvKZc8huA40YSaK9Qtl4/y7NGOh2n/z8N4N90 TUpFwuFGnbrMQNFSv/YrRsGA1DlqjBYPn5DHtl+mEX+Ysx6NrL1cUY0Hs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADtuCpa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCeEAoohdJAJlwwUggEKGAuESU8ChR4YAQEBAQEBAQEBayi?= =?us-ascii?q?FIgEBAQEDAQEhFTYXBAsOAgEEAQEBAgIjAwICJx8JCAYBDAYCAQEQihQQp3aCJ?= =?us-ascii?q?4QWAYZMAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JMg2GCEoMCg0mBHjiDFYJ?= =?us-ascii?q?DIAWjCId5jSeMD4dSjQiBVYd/gTsfOYFPMhoIGxU6gimCUhyBLAE7QDeKNgEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.45,378,1508803200"; d="scan'208";a="774101" 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; 08 Dec 2017 16:11:41 +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 vB8GBfDx027178; Fri, 8 Dec 2017 16:11:41 GMT To: Mehmet Ersue , "'Susan Hares'" , "'Kent Watsen'" , "'Lou Berger'" , netmod@ietf.org, "'Juergen Schoenwaelder'" References: <20171115.135818.591114714397486064.mbj@tail-f.com> <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net> <20171117065424.ccnx3dufs7e5abk3@elstar.local> <1e71a94a-d07a-0c0b-bc02-56aefdf19329@labn.net> <296B481E-20A5-4362-AE5C-174481FEDFA4@juniper.net> <002f01d36fc0$dd272350$977569f0$@ndzh.com> <01e601d37010$750eacc0$5f2c0640$@gmail.com> From: Benoit Claise Message-ID: <47fb5a83-4a9d-defc-e069-c699d004753f@cisco.com> Date: Fri, 8 Dec 2017 17:11:41 +0100 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: <01e601d37010$750eacc0$5f2c0640$@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] intended status of the tree diagram document X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 16:11:46 -0000 Dear all, I believe BCP is correct for the tree diagram document. Exactly as this is the right status for RFC6087bis, as discussed on the list. Regards, Benoit. > I think the rules and recommendations in this document should be used, once > agreed and published, by all YANG module drafts within and outside of IETF. > As such its content is BCP. > IETF consensus will be achieved during IETF LC. > > Cheers, > Mehmet > >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Susan Hares >> Sent: Friday, December 8, 2017 2:07 AM >> To: 'Kent Watsen' ; 'Lou Berger' ; >> netmod@ietf.org; 'Benoit Claise' ; 'Juergen >> Schoenwaelder' >> Subject: Re: [netmod] intended status of the tree diagram document >> >> Kent: >> >> A common way to express tree-diagrams in Yang documents provides a >> common and clear to describe the models. This would be really helpful to >> those using these yang models. Seems like a standard or a BCP to me. >> >> Sue Hares >> >> >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen >> Sent: Thursday, December 7, 2017 7:06 PM >> To: Lou Berger; netmod@ietf.org; Benoit Claise; Juergen Schoenwaelder >> Subject: Re: [netmod] intended status of the tree diagram document >> >> >> BCP for tree-diagrams? This doesn't seem like an appropriate application >> of that designation. I don't view the format for tree diagrams to be a >> "practice", whereas it definitely seems "informational". >> >> Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does > not >> represent an Internet community consensus or recommendation" could be >> cause for objection, since this draft is obviously going through a WG >> (NETMOD) and therefore does, in fact, represent some form of consensus, >> but I'm willing to gloss over that line as, clearly, many Informational > RFCs are >> published by WGs, which wouldn't be possible if that line were taken > literally. >> Perhaps we should file Errata against it? >> >> Kent // co-chair >> >> >> ===== original message ===== >> >> Hi Juergen, >> >> Sorry for the slow response, I missed this message. >> >> Circling back to this discussion made me go revisit RFC2026. Based on all > the >> factors/discussions I agree that standards track isn't quite right for > this >> document, but I also think informational isn't quite right either. I do > think >> BCP would as described in RFC2026 fits. This said, I think it would be > good to >> hear from at least Kent (as Chair) and Benoit (as AD) if they > agree/disagree >> with publishing as a BCP. >> >> Kent, Benoit? >> >> Thanks, >> >> Lou >> >> On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote: >>> Lou, >>> >>> right now, the document says standards track, Martin's proposal was to >>> move to informational. So how do I parse "I think you are correct. We >>> should leave as is."? >>> >>> /js >>> >>> On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote: >>>> Martin, >>>> I think you are correct. We should leave as is. >>>> >>>> I'm sure Kent/the document Shepherd makes sure whatever we do is >>>> right before publication in any case. >>>> >>>> Lou (as contributor) >>>> >>>> On 11/15/2017 8:58 PM, Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status >>>>> Standards Track. I think I heard during the meeting today that it >>>>> ought to be Informational. I think this makes sense. It would then >>>>> imply that other standards track documents will have the tree >>>>> diagram document as an informative reference. >>>>> >>>>> Should we make this change? >>>>> >>>>> >>>>> /martin >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_ma >> ilman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- >> ndb3voD >> TXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpv >> oumTA >>>>> - >> 4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byE >> sko >>>>> noVDeyYcQE&e= >>>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mai >>>> lman_listinfo_netmod&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- >> ndb3voDTX >> cWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3BCNpvou >> mTA-4y >> jD5n04CSFPUs2jLAlNoj5OIoOXDkU&s=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEsk >> onoVD >>>> eyYcQE&e= >> >> >> _______________________________________________ >> 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 Dec 8 08:24:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37053127843 for ; Fri, 8 Dec 2017 08:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHcyF6mH13Oe for ; Fri, 8 Dec 2017 08:24:53 -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 CE479127005 for ; Fri, 8 Dec 2017 08:24:52 -0800 (PST) Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id B4D526392D for ; Fri, 8 Dec 2017 17:24:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512750289; bh=mXhesLrSH1OJ7ysTu89gyeZJFjBqugGxOlvJLWZgBAY=; h=From:To:Date; b=XAiEh27QsqGZCGs0QqPbgMmRhnZGujp7oRTh1EZerEQDt9nIzjKgwY5jM0nL/eAIA 4qY4Z77G0cYPj8A1a86isnvMzoxuAghWbbgZvOSA1v4jIGaaqgnuk5lMeI1ez+zbIv qoJjOdDn+hwZajL6wx0EBNskvIk/rfsx6/vC5Bg4= Message-ID: <1512750289.11843.3.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Fri, 08 Dec 2017 17:24:49 +0100 In-Reply-To: <20171208153442.roomf7rhixtckrfk@elstar.local> References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 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] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 16:24:55 -0000 On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: > > > > Yes. The default value for yang-library-datastore leaf is ds:operational > > (the only possible one for the ds:operational datastore). This is backward > > compatible. If one needs different model for 'running', etc. then a new > > datastore identity has to be defined and set in place of the default value. > > Then this identity can be used to read the yang-library data with > > . > > > > Sorry, but I have to ask this: How do I obtain the schema for the > datastore (lets call it ) that reports the schema for > ? Is there another datastore? Will > the recursion end? Perhaps it does since > might have itself listed as the schema defining datastore. I guess > Lada will like these kind of meta and meta-meta datastores. Not really. Metadata needn't be in datastores. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Dec 8 09:21:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4EB126DFB; Fri, 8 Dec 2017 09:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 jm3Gs_U8o8iO; Fri, 8 Dec 2017 09:21:50 -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 242E0120713; Fri, 8 Dec 2017 09:21:50 -0800 (PST) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB8HJil8017674; Fri, 8 Dec 2017 09:21:49 -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=lDf6y5241xP2QJdb1nFcEhiLmicPxdsGpFN3OBymNTY=; b=Cc0ojMOn8azDliO+oyhHAa2rg00yu+Qn4a+K1/W5K06JJTJjJrCljupgZkTj09kmwpmb ZmQX5YDkthldcZz2jAmbz5ZA168SxyAUEGPAVDIDiIuQrVRKrr6sCaHoYAO+E1hgdSLx ZkyLSfonsR7tv3zP7GmJQbu9EsoXTxGeUVzuB+65RaKMS5R4BLiyrXStaJgwpureJeXX vMcAh9Pq2BUtgX9joCY/G16bsBWHUKqlAQi5VpCw29hSsc3XRjYksp46RQCCB3omPCCB xVXFublhKv+hHq+GMKVYTndAf1wkjHdLE2qo8UY0rjxNok35MZWksW+fZ+HV9NuFy1rM 4A== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0022.outbound.protection.outlook.com [216.32.180.22]) by mx0b-00273201.pphosted.com with ESMTP id 2eqvs0ge9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 09:21:49 -0800 Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Fri, 8 Dec 2017 17:21:47 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0323.004; Fri, 8 Dec 2017 17:21:47 +0000 From: Kent Watsen To: Ladislav Lhotka CC: "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] [Netconf] Alternative YANG library structure for 7895bis Thread-Index: AQHTWXr4QzV6rQAfmUKbAB+TvqMKD6MVuWCAgAACOoCAI/VDAIAAB3oAgAAA4QCAAAOyAIAABEIAgAAOAID//7wZgA== Date: Fri, 8 Dec 2017 17:21:47 +0000 Message-ID: References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> In-Reply-To: <1512750289.11843.3.camel@nic.cz> 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; BLUPR05MB273; 6:BWkAYdFYw5sG6+DveqkMK0TyHzF2tbku6w0ZON/WrXXCglAF+E9rpIt1+urfSlgzUM7ATzWqc+/Zocz66eD/6tv+yeAo0ZceoZ9ZRvtCkKRYiWVXWZNi1M5Njc2pX37zuS/FzYYSQncRT8R/+lV15iPwgDntz8DfMSkeq7GQutZqjvE2cfr5b1tfmeaTfauHtqDW1cSpQsSWUTR33Z3L8MsCHZGFfuh142HoD4zdtffoK676hA1Ssn81wkveS1+KGvUmoay9/TkUF6WIQI7Wl0nY38cf/oklECP6CnvzYTeeg64srOLqgCyHZ6iis9B3ItI38GNgyHKFWe91MHDhPHkOvZ3kH+5QnHPDf4QGWiM=; 5:J0kCOOCPzxarqkKchAbQpWq5SoNtp7ysHSNKzKW74nvl3AqaJ9DuAuAcAgi6hCL2iQtY2P+wkUXujH/t4/StvTrWRT1hmaGq2yAF9uz03XRIXRv59XcGhRH5TeOi+bOaDdUO5/iaSqsYEDWOPj+OIGSBCu5rfwsvvzxdEfuSbvY=; 24:M4VgdivN98xZ4Y1D1YJMTqkSIIQnFlzr2wNK5fGavriq1MvAsuvW8Z2x13hvdTvfz/shg2vO0v785PngE5GzkjPL4kdFMxMlT3PQ5+HdXHE=; 7:TXsBKuNznGyMwvqQt5C3ICHLFXGumbFjbGujBYl9GO/eMNcMO9s0TX3E+IhT3LgVGKVHEAh9RocIlo5uiSCSVDOHk7//dSnNMkm8E9SqS1T+uVxDhyHh4ee3L6F1rHtHwkGT/UDVPM/kBTw7l15E/gt1x3m1mAshxOYOvD+lUuE91AAD/Jc/zjfC01WkNJbs1Vy/hC/vYfUqCbVVZ0HVz8zwDSfNcd6YdTNcMAbre+ska5QIR1jD7EFgRaVMo3qp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 897fb496-db54-4d64-ae27-08d53e602998 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:BLUPR05MB273; x-ms-traffictypediagnostic: BLUPR05MB273: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB273; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(24454002)(377424004)(189003)(199004)(97736004)(53936002)(114624004)(7736002)(82746002)(6116002)(4326008)(3846002)(25786009)(102836003)(6246003)(66066001)(316002)(58126008)(93886005)(54906003)(33656002)(3280700002)(106356001)(3660700001)(105586002)(2950100002)(68736007)(81166006)(8936002)(575784001)(8676002)(81156014)(305945005)(229853002)(6916009)(83716003)(2906002)(83506002)(6512007)(36756003)(2900100001)(5660300001)(6506006)(86362001)(6436002)(77096006)(99286004)(76176011)(6306002)(14454004)(478600001)(966005)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.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) 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: 897fb496-db54-4d64-ae27-08d53e602998 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 17:21:47.7510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_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-1712080238 Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 17:21:52 -0000 Q0MtaW5nIE5FVENPTkYsIHdoZXJlIHRoZSBkcmFmdCBpcyBiZWluZyB3b3JrZWQgb24uDQoNCktl bnQNCg0KDQpPbiBGcmksIDIwMTctMTItMDggYXQgMTY6MzQgKzAxMDAsIEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciB3cm90ZToNCj4gT24gRnJpLCBEZWMgMDgsIDIwMTcgYXQgMDQ6MTk6MjhQTSArMDEw MCwgVmxhZGltaXIgVmFzc2lsZXYgd3JvdGU6DQo+ID4gDQo+ID4gWWVzLiBUaGUgZGVmYXVsdCB2 YWx1ZSBmb3IgeWFuZy1saWJyYXJ5LWRhdGFzdG9yZSBsZWFmIGlzIGRzOm9wZXJhdGlvbmFsDQo+ ID4gKHRoZSBvbmx5IHBvc3NpYmxlIG9uZSBmb3IgdGhlIGRzOm9wZXJhdGlvbmFsIGRhdGFzdG9y ZSkuIFRoaXMgaXMgYmFja3dhcmQNCj4gPiBjb21wYXRpYmxlLiBJZiBvbmUgbmVlZHMgZGlmZmVy ZW50IG1vZGVsIGZvciAncnVubmluZycsIGV0Yy4gdGhlbiBhIG5ldw0KPiA+IGRhdGFzdG9yZSBp ZGVudGl0eSBoYXMgdG8gYmUgZGVmaW5lZCAgYW5kIHNldCBpbiBwbGFjZSBvZiB0aGUgZGVmYXVs dCB2YWx1ZS4NCj4gPiBUaGVuIHRoaXMgaWRlbnRpdHkgY2FuIGJlIHVzZWQgdG8gcmVhZCB0aGUg eWFuZy1saWJyYXJ5IGRhdGEgd2l0aA0KPiA+IDxnZXQtZGF0YT4uDQo+ID4gDQo+IA0KPiBTb3Jy eSwgYnV0IEkgaGF2ZSB0byBhc2sgdGhpczogSG93IGRvIEkgb2J0YWluIHRoZSBzY2hlbWEgZm9y IHRoZQ0KPiBkYXRhc3RvcmUgKGxldHMgY2FsbCBpdCA8cnVubmluZy1saWJyYXJ5PikgdGhhdCBy ZXBvcnRzIHRoZSBzY2hlbWEgZm9yDQo+IDxydW5uaW5nPj8gSXMgdGhlcmUgYW5vdGhlciA8cnVu bmluZy1saWJyYXJ5LWxpYnJhcnk+IGRhdGFzdG9yZT8gV2lsbA0KPiB0aGUgcmVjdXJzaW9uIGVu ZD8gUGVyaGFwcyBpdCBkb2VzIHNpbmNlIDxydW5uaW5nLWxpYnJhcnktbGlicmFyeT4NCj4gbWln aHQgaGF2ZSBpdHNlbGYgbGlzdGVkIGFzIHRoZSBzY2hlbWEgZGVmaW5pbmcgZGF0YXN0b3JlLiBJ IGd1ZXNzDQo+IExhZGEgd2lsbCBsaWtlIHRoZXNlIGtpbmQgb2YgbWV0YSBhbmQgbWV0YS1tZXRh IGRhdGFzdG9yZXMuDQoNCk5vdCByZWFsbHkuIE1ldGFkYXRhIG5lZWRuJ3QgYmUgaW4gZGF0YXN0 b3Jlcy4NCg0KTGFkYQ0KDQo+IA0KPiAvanMNCj4gDQotLSANCkxhZGlzbGF2IExob3RrYQ0KSGVh ZCwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcg bGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZk PUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05 emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09NXFqNkJRVVN3cVlt a0FWZUt6NWF4RlY4azNneFlFUFNKNUNwMFJTbnhyRSZzPUk3ZlIxR1k1bE4yaFZNa0R1dnJ5cmhE ZVJ5cGlrZTN3UGVGUnJ2UUk1bDgmZT0NCg0KDQo= From nobody Fri Dec 8 09:22:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BCE120713; Fri, 8 Dec 2017 09:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1W_9LmtBIF8g; Fri, 8 Dec 2017 09:21:50 -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 0AA3C1201FA; Fri, 8 Dec 2017 09:21:49 -0800 (PST) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB8HJjca017679; Fri, 8 Dec 2017 09:21:48 -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=gP5lWcV9oGpRMdljWOXJZHcK5p5R3p9d1F70aBTuF8k=; b=S/GjiDoTPtGT7hRQw3rmfT+h1RTw/UuIMHvQhsVqR00uXw3tdx6adJQ+4N3yORpoZJs9 iqXQjDwwznMNigO6DnjTmstmmY1Pl6Jzwx3NUK3yxLK58jeEYDepefuZ3mvJEm9fO2T/ rjoZjUkiKP05QxAXYSCeCZqZ9jI857fj4n1W1PjJZc2pqkM6aJLYwUN40y8hbuBabvKb DRHKPA/uJ+xZ5wqNhHlNznLIoNYFzF99tlS9Lh+CmxsFSy0VVU/0D+peWcqQpJ/WEfxJ u5Al3xYsVgdX36KXVSdXGSnbgzYdg5OZNdevFxNYnkkiybk+HH9bagIaV3oCXHU7SCPY 3Q== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) by mx0b-00273201.pphosted.com with ESMTP id 2eqvs0ge9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 09:21:47 -0800 Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Fri, 8 Dec 2017 17:21:45 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0323.004; Fri, 8 Dec 2017 17:21:45 +0000 From: Kent Watsen To: Vladimir Vassilev , Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" CC: "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] YANG library structure Thread-Index: AQHTcAmh7On8if5A/Ee2i3mIHQ1NsKM5SlSAgAABMACAAA7wAIAAAbAAgAAf1oCAAAwRAP//1hqA Date: Fri, 8 Dec 2017 17:21:45 +0000 Message-ID: <43C2E52C-08E1-4100-B948-F40B43038D97@juniper.net> References: <20171208111504.iwpcck3hkbboryeo@elstar.local> <20171208121434.2vfbrc5pdbwnx3ig@elstar.local> <20171208.150831.2068512524982133442.mbj@tail-f.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.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:ODePrTeuGFIRjlYT1bpcDU5CxvoZGCtLRIJo9iheafGpTeIhwwiabfQulf7qvVRvowwhl977Yv346JsuuPKLbcMt32GDgVUEY2QVKQCic6SIlKKbUx5txUg/UygAhac9k5lTsaxvxtAIdRwVsqNk7nDsyMcPg5PaaB/syTb4zpmZDkxXk3wP5EjOtD2FZW6UIIVKDCNXyar14gTRZFqWZZu3Li86o17j1743IpPaFPiCM0x6ms9oJ740JlVaNMZo8H7pxnlmMnLAkIi3IF10KDcxax3J/cQKVPJfNIlt7Op+6xGcfdBlAKbjy911vmNwnEVv12XfEk3zeVSCRIerb0NDuLJnaOT52KzquPwbiFE=; 5:26sHjufYtpbfMJ/fu6t+9vZubHEkfSb/+2Iz3UWXmZPXte06mF3Ue2/wg26uk5nw15kCdZZjQ+Wips4kDSD1NO8RG8oGf5ECN2FxTBIVo5a8BPZ3BJrp/TwMDXZIHmVk6LLD3czHhf8r0aQJBcb/dS/DDDoY7Qe6mGZaKskyTns=; 24:eYVuGJIfekTurGKxZDRpGBxfpEia6ATXPL7/Ests9U2ifEfV4lVQnM1X3sV4yYidBY+cPuMKsqMLDkuSsh+a4rRm7ra12wNAnuq5GX/sfbY=; 7:oRTmycoihax0+rNPTbFEP1EFefZiiwdINDHJ+qTAwsUscmE/luC1p8e17/Dg3gBFZaym6gh+pLhOjJu+3rdu+1IzuiOxfZX8yy+3Ra8d4LKWIF38Gvzslm65HFbhSJ+VW92Y8R2MoIyLxWvYj98bD2AacpRyeyZZdRR3r/Ob7edzmGCVz6RQQePhhszE5zYt0ONCRb5cz3GTjXnkcaWzzD9S5+WAc3b2052QX9H8WxdwAHDA7+ZHOeDDynNO9bSY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f63016e5-6f1c-4af4-a95e-08d53e60286e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:BLUPR05MB273; x-ms-traffictypediagnostic: BLUPR05MB273: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB273; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(24454002)(189003)(199004)(97736004)(53936002)(53546010)(7736002)(82746002)(6116002)(4326008)(3846002)(25786009)(102836003)(6246003)(66066001)(316002)(110136005)(58126008)(93886005)(54906003)(561944003)(33656002)(3280700002)(106356001)(3660700001)(105586002)(2950100002)(68736007)(81166006)(8936002)(575784001)(8676002)(81156014)(305945005)(229853002)(83716003)(2906002)(83506002)(6512007)(36756003)(2900100001)(5660300001)(6506006)(86362001)(6436002)(77096006)(2501003)(99286004)(76176011)(6306002)(14454004)(478600001)(966005)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <35DC6E912A6E924B97C8C414DE72DE9E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f63016e5-6f1c-4af4-a95e-08d53e60286e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 17:21:45.8291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_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-1712080238 Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 17:21:53 -0000 DQpDQy1pbmcgTkVUQ09ORiwgd2hlcmUgdGhlIGRyYWZ0IGlzIGJlaW5nIHdvcmtlZCBvbi4NCg0K S2VudA0KDQoNCk9uIDEyLzA4LzIwMTcgMDM6MDggUE0sIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6 DQoNCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU+IHdyb3RlOg0KPj4gT24gRnJpLCBEZWMgMDgsIDIwMTcgYXQgMDc6MDg6MzJBTSAt MDUwMCwgTG91IEJlcmdlciB3cm90ZToNCj4+PiBPbiAxMi8wOC8yMDE3IDA2OjE1IEFNLCBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+Pj4+ICAgDQo+Pj4+PiBJbiB0YWxraW5nIHRvIHNv bWUgb3RoZXJzIG9uIHRoaXMgdG9waWMsIHRoZXkgc3VnZ2VzdGVkIHVzaW5nIGEgbGlicmFyeSBw ZXINCj4+Pj4+IGRhdGFzdG9yZS4gSSBoYXZlbid0IGxvb2sgaW50byB0aGlzIGVub3VnaCB0byBr bm93IGlmIHRoYXQgaXMgYSBnb29kIG9yIGJhZA0KPj4+Pj4gaWRlYSwgYnV0IGl0IHNlZW1zIGZ1 bmN0aW9uYWxseSBlcXVpdmFsZW50IHRvIHlvdXIgZmlyc3Qgb3B0aW9uIGJ1dCByZWFsaXplZA0K Pj4+Pj4gaW4gYSBkaWZmZXJlbnQgd2F5LiBKdXN0IHNvbWV0aGluZyB0byBhZGQgdG8gdGhlIG1p eC4NCj4+Pj4gSWYgcGVvcGxlIHdhbnQgdG8gcHV0IGFkZGl0aW9uYWwgb3B0aW9ucyBvbiB0aGUg dGFibGUsIHRoZXkgc2hvdWxkDQo+Pj4+IHdvcmsgb3V0IHRoZSBkZXRhaWxzIGFuZCB3cml0ZSBk b3duIGEgdHJlZSBkaWFncmFtIGFuZCBzZW5kIHRoZSByZXN1bHQNCj4+Pj4gdG8gdGhlIGxpc3Qu DQo+Pj4gSSBndWVzcyB3ZSBoYXZlIGEgZGlmZmVyZW50IHBoaWxvc29waGljYWwgYXBwcm9hY2gg aGVyZS4gIEknZCBwcmVmZXIgdG8NCj4+PiBoZWFyIGFib3V0IGZyZXNoIGlkZWFzLCBldmVuIGlm IGhhbGYgYmFrZWQgb3IgYXNrZWQgYXMgYSAic3R1cGlkDQo+Pj4gcXVlc3Rpb24iLiBTb21ldGlt ZXMsIGlmIG5vdCBkaXNtaXNzZWQgb3V0IG9mIGhhbmQsIHRoZXNlIGxlYWQgdG8NCj4+PiBzb21l dGhpbmcgdGhhdCBpcyBhIGJldHRlciByZXN1bHQgdGhhbiBvdGhlcnMgdGhhdCBoYXZlIGJlZW4g aW1tZXJzZWQgaW4NCj4+PiB0aGUgaXNzdWUgaGF2ZSB0aG91Z2h0IG9mLg0KPj4+DQo+PiBUaGUg ZGV2aWwgaXMgdXNhbGx5IGluIHRoZSBkZXRhaWxzIGFuZCAndXNpbmcgYSBsaWJyYXJ5IHBlciBk YXRhc3RvcmUnDQo+PiBpcyBmb3IgbXkgdGFzdGUgYSBiaXQgdG9vIGxpdHRsZSB0byB1bmRlcnN0 YW5kIHdoYXQgaXMgYWN0dWFsbHkgYmVpbmcNCj4+IHByb3Bvc2VkLiBJIGFtIG5vdCBkaXNtaXNz aW5nIHByb3Bvc2FscywgYnV0IEkgbGlrZSB0byBiZSBhYmxlIHRvDQo+PiB1bmRlcnN0YW5kIHdo YXQgaXMgYmVpbmcgcHJvcG9zZWQuIEFuZCBmb3IgdGhhdCBJIG5lZWQgYSBwcm9wb3NhbCB0aGF0 DQo+PiBpcyBhIGJpdCBtb3JlIHRoYW4gJ3VzaW5nIGEgbGlicmFyeSBwZXIgZGF0YXN0b3JlJy4N Cj4gSSBhZ3JlZS4gIEluIHRoaXMgY2FzZSwgSSBjYW4ndCB1bmRlcnN0YW5kIGhvdyBpdCB3b3Vs ZCB3b3JrIGF0IGFsbC4NCj4gVGhlIGxpYnJhcnkgaXMgY29uZmlnIGZhbHNlLCBzbyBhIGNsaWVu dCBjYW4gbmV2ZXIgZ2V0IGl0IHZpYQ0KPiBnZXQtY29uZmlnIGZyb20gPHJ1bm5pbmc+LiAgTWF5 YmUgdGhlIHByb3Bvc2FsIGlzIGEgbmV3IG9wZXJhdGlvbg0KPiA8Z2V0LXlhbmctbGlicmFyeT4g d2l0aCB0aGUgZGF0YXN0b3JlIGFzIGEgcGFyYW1ldGVyPyAgT3IgbWF5YmUgdGhlDQo+IGlkZWEg aXMgdG8gc29tZWhvdyByZXR1cm4gbWV0YSBkYXRhIHRvZ2V0aGVyIHdpdGggPGdldC1jb25maWc+ PyAgSSBjYW4NCj4gZ3Vlc3MsIGFuZCBkaXNtaXNzIHRoZSBwcm9wb3NhbCBiYXNlZCBvbiBteSBn dWVzc2VzIDstKSAgT3Igc29tZW9uZQ0KPiBjYW4gd3JpdGUgdXAgYSBjb25jcmV0ZSBwcm9wb3Nh bC4NCkkganVzdCBwb3N0ZWQgYSBmb2xsb3d1cCBvbiBhIHJlbGV2YW50IHByb3Bvc2FsIGluIGEg dGhyZWFkICJbbmV0bW9kXSANCltOZXRjb25mXSBBbHRlcm5hdGl2ZSBZQU5HIGxpYnJhcnkgc3Ry dWN0dXJlIGZvciA3ODk1YmlzIi4NCg0KVmxhZGltaXINCj4NCj4gL21hcnRpbg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj V3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RVA2 NEdJWDVYUzJ6TzhLMUc3QTZ2WG1UbGNIVjBXQlpadzVyNUdhQlFaVSZzPXdKVzFfMWxmZUdSMUYw WlVpWm1mbWFLTnpFLUVwRTREUXVMd0tZaXlSaWcmZT0NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBp ZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZ dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUVQNjRHSVg1WFMyek84SzFHN0E2dlhtVGxj SFYwV0JaWnc1cjVHYUJRWlUmcz13SlcxXzFsZmVHUjFGMFpVaVptZm1hS056RS1FcEU0RFF1THdL WWl5UmlnJmU9DQoNCg0K From nobody Fri Dec 8 10:01:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9049212708C for ; Fri, 8 Dec 2017 10:01: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 cC7PLUoUbewI for ; Fri, 8 Dec 2017 10:01:25 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 C2335126BFD for ; Fri, 8 Dec 2017 10:01:24 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id i2so12697668lfe.9 for ; Fri, 08 Dec 2017 10:01: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 :cc; bh=3dwhztOLwvXmXXoxMK4N7GPHlDOnZjto3w65anNtocY=; b=we2UGomCbHRqKj8cBbXJRtY+AcXkKS7RlrJ/GUtCZg3H4cpk8OgU9P5vE6gxRBjFHl /G22I4sBxuSWDwuxkhm0ghqgm9hen6MY/LJsnPvAwzP3yUf5D13/Dw22I8ZGFJnsY3xb 1UwWNMGn63YA2ow9g0er0dDI3B4fNHLk10P1FVTLtdFbbh5tduPhxy6UN/EG/zBMbDlr cvGgeD9PBhAQ6Lm2yc/lPA9uowN+rj1KpOGTIaXSYFUkrvYS4yAzhICxNc5Rxts4aZSB 1V4Uj42ngJKIX3e6jLjm97KhrMsmEDiWhic3mIWR3BqWeofEWPxj7wbRDzykNyaBUlDe 3JBA== 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=3dwhztOLwvXmXXoxMK4N7GPHlDOnZjto3w65anNtocY=; b=boEwn+Ajkl7z4Z6JPdU3eitIUXy6k8uTC0qzzwU2/6JUB4aQ9sxzVg24wdWxdP37Yt cSzuO1paUaLXrdl2VRBg+roaCWt6+N/op9ufX2kGktUmo/WaUOpTGCrWSiAsG0kLyz8+ 92Vt5iy20ma5Dn+gscUqo1ONQjX0edBnx9wwRaphwEjBIfGQA1o14beHmxHIMEsczqfL L19R4TR6Yykx3uIhWkD8uNBiCYSm2B9jwuxtLp9Sy6Xid57iebDRnaHtHyvDjrsyeL4A oyU7PKlCey+Dp9ALUn8vUYEMxsvoPL71nbq+6S/vn1e3CrjYW4U7W2IWREbaBh2FJIkV 3vfw== X-Gm-Message-State: AJaThX6asFIavZGGYj70q5gI3ywVt7gufbnOWL1rGz3pxC31E5HQJ6wX vy5DkLqNpekHusBgGq5uXQaPAR2SyAZxGKFOjmruMw== X-Google-Smtp-Source: AGs4zMZNcOpx5rSGKQA0fvXh3PrJH2r2JyMFDV4YBhboW4DM8GFDzu6+oklGNp/M9HCT7sQLk0VLPPm7F5msIN8IvQ4= X-Received: by 10.46.93.2 with SMTP id r2mr16162376ljb.182.1512756083041; Fri, 08 Dec 2017 10:01:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 8 Dec 2017 10:01:20 -0800 (PST) In-Reply-To: References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> From: Andy Bierman Date: Fri, 8 Dec 2017 10:01:20 -0800 Message-ID: To: Kent Watsen Cc: Ladislav Lhotka , "netconf@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114b8c24f63bfb055fd7f84e" Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 18:01:27 -0000 --001a114b8c24f63bfb055fd7f84e Content-Type: text/plain; charset="UTF-8" Hi, A library per datastore sounds too complicated. I prefer the proposal that was made at the IETF meeting that had a 'not-implemented-in' leaf-list and a single module list. Why is it interesting to have a separate module list for regular modules and imported modules? I prefer to keep the conformance leaf and not change the module list. NMDA needs to be possible to implement with a single schema tree such that a module is implemented in all datastores, or a subset of all datastores. Otherwise it probably won't get supported in clients. Andy On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen wrote: > CC-ing NETCONF, where the draft is being worked on. > > Kent > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: > > > > > > Yes. The default value for yang-library-datastore leaf is > ds:operational > > > (the only possible one for the ds:operational datastore). This is > backward > > > compatible. If one needs different model for 'running', etc. then a new > > > datastore identity has to be defined and set in place of the default > value. > > > Then this identity can be used to read the yang-library data with > > > . > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > datastore (lets call it ) that reports the schema for > > ? Is there another datastore? Will > > the recursion end? Perhaps it does since > > might have itself listed as the schema defining datastore. I guess > > Lada will like these kind of meta and meta-meta datastores. > > Not really. Metadata needn't be in datastores. > > Lada > > > > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m= > 5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s= > I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114b8c24f63bfb055fd7f84e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A library per datastore sounds too = complicated.
I prefer the proposal that was made at the IETF meet= ing that had
a 'not-implemented-in' leaf-list and a singl= e module list.

Why is it interesting to have a sep= arate module list for regular modules and imported modules?
I pre= fer to keep the conformance leaf and not change the module list.
=
NMDA needs to be possible to implement with a single schema = tree such that a module
is implemented in all datastores, or a su= bset of all datastores.=C2=A0 Otherwise it probably won't
get= supported in clients.


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@ju= niper.net> wrote:
CC-ing N= ETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:oper= ational
> > (the only possible one for the ds:operational datastore). This is= backward
> > compatible. If one needs different model for 'running', e= tc. then a new
> > datastore identity has to be defined=C2=A0 and set in place of th= e default value.
> > Then this identity can be used to read the yang-library data with=
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the sche= ma for
> <running>? Is there another <running-library-library> data= store? Will
> the recursion end? Perhaps it does since <running-library-library&g= t;
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
ht= tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scb= fh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa= GTvjISlaJdcZo&m=3D5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0R= SnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= =3D


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

--001a114b8c24f63bfb055fd7f84e-- From nobody Fri Dec 8 10:28:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9D712896F; Fri, 8 Dec 2017 10:27:59 -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_H4=-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 YJs7UyajMJkt; Fri, 8 Dec 2017 10:27:56 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C6D126E3A; Fri, 8 Dec 2017 10:27:56 -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=hThKCfcscOXZWXEBuxSV4DrTqxcd0rVsGnAlCyIPZBA=; b=LuASa173gF/VbEU5sflhXqvUCGjaYG8pjld/BNdToWDkPELLxtMMFaz+4y4ZTSip5bADbxHK3hZO9CtK1H3pvQKqEA2dFOKTBr7zx+Xq+R4ebTyI8sMf37JfeoZ6+xCZgGH9yhiBN7R0iAZtGNIylda5rIySNSlu8pN/jPl0Ecc= Received: from pc6 (86.169.153.236) by HE1PR0701MB3001.eurprd07.prod.outlook.com (2603:10a6:3:4d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Fri, 8 Dec 2017 18:27:53 +0000 Message-ID: <005a01d37051$be87a960$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Jiangyuanlong" , , References: <151185035711.13451.15517049816245497403@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB65C509@dggeml507-mbx.china.huawei.com> Date: Fri, 8 Dec 2017 18:23:48 -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: DB6PR0202CA0041.eurprd02.prod.outlook.com (2603:10a6:4:a5::27) To HE1PR0701MB3001.eurprd07.prod.outlook.com (2603:10a6:3:4d::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cd279c2c-27ea-46ff-1ab0-08d53e696585 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307); SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 3:A4oR78f1XDtDbwmWp7fiS0E5z6UcDf40gJ/ArRMC2NGOCcJgwItcCn2RGLyxg4DeNWS54EQean4dk2VeEAgzBQJGRloUHOaCHqUz1JIAXDG6uJmVkerk8lglesCZ8myNJ3rCrTVOjpHAazIO1wbdJN5dxecpPdWfQgJZ6I/ijpFjjuwOed/68IA7Ct/35kzQu4opjKaZ+KJ4tYs3aKc4YkIgGuM8t521mQq3bjXFCqbuos6Zp13FGf6CgXZbJXqb; 25:8PzvBq8J5p5oVNo5fTAdAFlr4yWvOys7EsX/95ZmWBDHXJ79Pzn0Uzv+TwEudliUMB4IEMxfKzrJo+msl9lc+0IpQYhRVoPvyNHBFWt80wl8atIufB1LycWVZAcHGipqgF5r21truub3zFgiXxNP87z0elBZ3Jkxkz9GG0WZiO0B3B0FErXNEK6nzztNz1EFvyI+2bfUgLLq7cZis3JZLAcX5b4A5Fu3A25T/66WBeJsazCCLGzPtchGYNp+d1KmwOGQCA0wyG2WpkurOxwwkNE8fU2jhGL04I3LKvzz7iaX/7MxK1v3pXQseayk/zlNeVPeCoSctnprmR4FjsJoZw==; 31:0Q5osuHq7OE25SbiPjaC6fZH7FigGI68tyPWmI1NTsH6pfQq3rp67VrvcAGaLFL2Y6RWsrzSFyEz13KWHB69Yc37sTeSbmLMlTJZyd/pPvmLRk49k5fjfGxMjgOhjM5cJjI5+RkzeCIjSIHsuFsCklduaecLcgsV+YV5WSHKE5cGAnEnlwqBoWkJ651NrOC+sPvHbO05I9XJX7xhMCLUZPevFEGAmEHLlnHl31oKkvI= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3001: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(50582790962513); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0701MB3001; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 4:MG3OIPWqNwfqw9lBi55LTfIwhW4c+s3sfubu8ools2oT+/OgS2UP5l9GOufTvhsO7lJbRhHVAk4LM7/Tgdc7eDLbCUhiCxzn9fFNVDNgIJ63QsSTSNa2iN4yGBKHfqrSlAn7KTnd3YCIfeSUHkXStd32od4kiNWOOL22NdRGkvueS6Q5vG1G4CdElktxO/2rnVWyYxluQdBZBB/5cP91QEFb0zNbN73igh3ViHhdvpkdNR2VvMwhwzhpKxaThVAld0SZ6T4x5WfnQLGlxVUhSodfQZ0V9vYBrrxT73IIpBRalLGZGFBn0ydPPOYonkIq7yl3p5osOOpGIMZT1p1wt8pGCsg0tTX4yBegKDti648= X-Forefront-PRVS: 0515208626 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(376002)(377424004)(199004)(189003)(13464003)(53754006)(230783001)(316002)(6666003)(106356001)(2201001)(1556002)(23756003)(81816011)(76176011)(44716002)(4720700003)(33896004)(66066001)(50226002)(62236002)(52116002)(105586002)(84392002)(6496006)(6486002)(9686003)(6306002)(229853002)(110136005)(50466002)(44736005)(16526018)(33646002)(86362001)(1456003)(25786009)(68736007)(81166006)(53546010)(5660300001)(81156014)(8676002)(230700001)(7736002)(305945005)(97736004)(4001150100001)(53936002)(8936002)(966005)(6246003)(2906002)(81686011)(47776003)(478600001)(116806002)(6116002)(61296003)(14496001)(3846002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3001; 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: =?iso-8859-1?Q?1; HE1PR0701MB3001; 23:FIGN6XCIaMBeXrf9rl8vPR1QBOBwWVj4E3Rzt?= =?iso-8859-1?Q?1Uu8sNPxNGG4L86rW8nwW3FbrwNsl1/8e0uNvw1CDh2eDALWGaXH47aS8/?= =?iso-8859-1?Q?A//465LJ6fhCknxVDB/+/YpNkKmpbVBjN2k2nwTstC30q/1MIfatasYMz9?= =?iso-8859-1?Q?2Coz9NDnM87sajQ9Sym18PBMiyFSlHvpUeGS6TBoFM4DQI+JyxBZwqHfZT?= =?iso-8859-1?Q?DkkNnXdAq2rGWEexDnXgJKTWe50c0H3RLYX/hc3OTmGQwz2AKYJZ5vzN+S?= =?iso-8859-1?Q?NaL4hiSs9wiIc09XE40DR2G3m8lMngZLMqvzQA+NhZTmFaVZ0SkA1Qvlfy?= =?iso-8859-1?Q?2fdcgt+7YYiZn0DjEhYyuzg+h1P5+xWo//8Pryg9t9LmJx80V+2pHId1qI?= =?iso-8859-1?Q?e/Hy/k+5vlbZkmiE5V7am9V589DSP3FE/Gy/oZCbrM36o2K6RzixqmksRv?= =?iso-8859-1?Q?nzlWtUKRPakp2hEkMLl2LFBclozMZX/yrr3EjW7/9X69QDhRhpe0A0es+n?= =?iso-8859-1?Q?TSZCCORMgYQ1Gu2yfilMutqzFQgOfxWdtEPn8odPMrM3AyueDypCizW+yr?= =?iso-8859-1?Q?VWIb9H5v1omiuv1INj8Q18Mg/0tDAJToBFwJLvuCXCqzM8sg0VoOFwno4H?= =?iso-8859-1?Q?fIXsyPx2gh7cJwSMQHSAVMWYMdXbA4PA5nYIoHnxYms4sLilf+XjHpjsZ8?= =?iso-8859-1?Q?DSS+khwfBUrcihV204LkprvE3gkxsrl4KSNNeezL6Y0jQ1v93VUEZ5DPsu?= =?iso-8859-1?Q?E7ZXJ+hzxd2lEv1Ghk+yg1oPAs4bmWAErioHC5a2oPGSKQ4DEC57Jb4lul?= =?iso-8859-1?Q?P1kmSeSaaIWb7KdN4T70Us4EHs55INatYJq4UdLcbm2ZOJymgm55G+P20j?= =?iso-8859-1?Q?dBvp/PcaDBgcnz29mjY+Kv+MzVIwHekq5K6b1USywXRoQNsE/A5IrwWPmG?= =?iso-8859-1?Q?oNqVvHuGkZDaWBlZd/xdvRvY7b0KItk92mUS+WrNjE+L+rK0c/HIE4jb09?= =?iso-8859-1?Q?gFlD3dN8upQuUTDbSOni5O6wuy5BsNxhVYTMyZSmSjxgwknntdPbF3VDv5?= =?iso-8859-1?Q?PmFVBimTJzHigsMi/QNwNNe4t31eEL65jy3DnEuA3MTCQphO/Lcb9TDQrk?= =?iso-8859-1?Q?bWJCjcliGxwRaGodGqPK8OyWqYdbaACGV8ySdZxf+hEXzAF0WgevVmscDK?= =?iso-8859-1?Q?dIvU4IWOzRnOghHr5bhP5deQK8m/gQ+Zf74q0hSGrVu/a6bvyzpKqrddgG?= =?iso-8859-1?Q?VCvuruiyNol1aFkqfbUwDDAP3p5wDtIbF1KBzjxLhi8GFvZEgdEhLuozV3?= =?iso-8859-1?Q?9fYOgQiqJg7Kx9XEHj+/eJZ2DupUpzVUVHjQlOaJewLNDtcA81krKgbBKU?= =?iso-8859-1?Q?T46eyT7n2SC4drOp0cGja1gGAW5JDviLX6PuwdcPbtKqeeF5FXrK/364R7?= =?iso-8859-1?Q?6XZCEZBhrerO/6c+1HToO8xMPTkGYEh2Y6rsQrOoRzQILrRLlxxM/33CN0?= =?iso-8859-1?Q?4yz6KjI2R9au+zK6KpkAR7e26OoQ7meQcTlDkhNKoANtP6BZ/nBQVSInBQ?= =?iso-8859-1?Q?lIA9yj/ua9nmuT/d8hV+Py/LxNtM=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 6:BcpILwvA3PW96UU4rICdp0ngxKFRR5HqIGnGsJS1yiNdKGiXaStcG+Qz0ooapHyI2hQCB9ARgFUOGacPaa4S97k0gGUde4EJ3avB9H8SV1fcWAWTgw5e4u7A1EV+BVS03KGTT9PyivqQm3tsk9tMrlGGgBXTte5Nzt4GMyZfdf95FyYGzRHXNvyZzaGipqeoQ+5rru5T9WFmdMADjFWW9HjD/hsFn0hq0lyyiAtuuraFwykDAWTzXhYT8NrIdOu/po8bi0ogZKNK2e0PccpnKApvztFkuLkAeFgGFcPcGb/wP3WnK/KRVxK5gbESlaNDEZFOKcqVSMbNm+khE3X4FemVTTJA53TaTIlU7/QnSr0=; 5:J8vZCAFR9M1XQ3AKUFIC8VPCOGhT7aUI4S3bqTgIrruKw9Zxbq10Rn+323KnnGqYdX2p+7nzIPeJKBea/q7b56OZGoe1O5QAlHc5gJGIbZmbgbDEdKsMSNv7PGKXrzZQlMgAaIXgEbUsn9ieu1IMQcUowstfHALPatlLBu0QGQk=; 24:Ml+kfGg27KDjtt3hrGd0AWg89lH++0qQW2x1cvvNMcjQyO14iyFCmfTTTDdbqDJfpeP41Vkub9ZZ0KrAW7uZiMAarCWYKe17p4lHziivoqs=; 7:TEoDahEjfTQ2IFZC+oRbKSg0jq0jJ1MAo/pqrJ/Ylq0NtQHiiCCPRjUIcc+mjbNV0PP49FzDy0n6O7MzGx2vyvy0us0PHh3ku1pzsPEzLO3upyoUEVM5hJGbvECV2u+LCXDccVW1gM29Tb7Ui4rmI+XLLPJzeeMjnMcrBFRrsyDZpbxLeyR5z0l69bL8rusGuZ/cYgSu3A7cciGmDOSI9dlVfRIKk1NJodz2DWnrm4K8mpi6xlRrfPjFrSNglIXi SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2017 18:27:53.3190 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cd279c2c-27ea-46ff-1ab0-08d53e696585 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3001 Archived-At: Subject: Re: [netmod] FWD: I-D Action: draft-ietf-tictoc-1588v2-yang-07.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, 08 Dec 2017 18:27:59 -0000 Yuanlong I belatedly read appendix A and I am impressed. A few minor thoughts. 1. I was confused by the Title Transferring YANG Work to IEEE 1588 WG (Informational) thinking you meant that the IEEE 1588 WG work would be Informational, like an Informational RFC. What I am more used to is to start the Appendix with the statement 'This Appendix is Informational' which I would have found clearer! 2. The start of A.1 is hard to write. It is the IESG that approves publication, rather than an IETF WG, and I would assume that it has happened, in wording this, so perhaps start with " For the purposes of this appendix, assume that the IESG has approved the publication of an RFC containing a YANG module for a published IEEE 1588 standard. " and you could ask the RFC Editor to insert the number of the RFC as and when it is published; bit presumptuous perhaps, but think positive! 3. OLD YANG for subsequent 1588 revisions NEW a YANG module for subsequent 1588 revisions 4. A.2 I was around at the time of the MIB Module transfer and the problem was that the then current standard, RFC3978, did not acquire sufficient rights; hence the need to track down Contributors. I had thought that RFC5377/RFC5378 had fixed this but what you are proposing sounds like a good plan. 6 A.3 I don't think that the chosen prefix matters. The namespace does since that is what gives names their uniqueness but different YANG modules can use different prefixes to refer to and import from the same namespace; and there are bound to be different modules using the same prefix within the module, if not now then in time; prefixes are not registered in any way. (When someone says 'PTP' to me, I think RFC2637, not RFC8173:-) So an IEEE YANG Module could use the same prefix as the IETF one, could use a different one; this is something of a live issue now, with NMDA modules replacing the initial ones; same or different namespace, same or different prefix? hard to know what is best, or what will be at the time of the transfer. Tom Petch ----- Original Message ----- From: "Jiangyuanlong" To: ; Sent: Tuesday, November 28, 2017 6:37 AM Subject: [netmod] FWD: I-D Action: draft-ietf-tictoc-1588v2-yang-07.txt > Hi all, > > Based on all the comments we received after the WG Last Call, another revision of this draft is uploaded. > Thanks a lot for all those discussions. > > Regards, > Yuanlong > > -----Original Message----- > From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, November 28, 2017 2:26 PM > To: i-d-announce@ietf.org > Cc: tictoc@ietf.org > Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Timing over IP Connection and Transfer of Clock WG of the IETF. > > Title : YANG Data Model for IEEE 1588-2008 > Authors : Yuanlong Jiang > Xian Liu > Jinchun Xu > Rodney Cummings > Filename : draft-ietf-tictoc-1588v2-yang-07.txt > Pages : 29 > Date : 2017-11-27 > > Abstract: > This document defines a YANG data model for the configuration of > IEEE 1588-2008 devices and clocks, and also retrieval of the > configuration information, data set and running states of IEEE > 1588-2008 clocks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07 > https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588v2-yang-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/ > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 8 12:35:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6107126C83 for ; Fri, 8 Dec 2017 12:35: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 a0JB4zNqT3P7 for ; Fri, 8 Dec 2017 12:35:54 -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 AAA841272E1 for ; Fri, 8 Dec 2017 12:35:53 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id x20so13139086lff.1 for ; Fri, 08 Dec 2017 12:35: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=gVbFIzor8oZMXGEUuG8uBZ/l4ow9RCUX4E9kVef/Kok=; b=sujzk7WQ7ItD0bmS+oKo+kGOkrdXzaT59mUwmKHLN5ZZLLADFkICZapxywmUBJaXln Xv0ZFuIvy8f4q4mRQ1SxMMt0S07QreqTGmFmzP1Cqnb8AyP7LWVHg5o83ipZjs32Wtt7 XZMP0vr2oUdRVYZ5TfN1bqb25rvzKpsiJFeKxnHI2o+f1+GM3MlmhrRtQ3fHWDqvXXp7 ZMt+VjdUD/M1ByrnmsVI8gGVofBUvVMcNniVQ5S+Y+mf5YYZ1T6h4YBzhxh1nl2V9dRk cxzMNCTVkxZFQJj31qUykhEu3Iwrt4n9I5AzClRbV55XAVkpg4aA5jJFrbiuqI6Gwce1 plsw== 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=gVbFIzor8oZMXGEUuG8uBZ/l4ow9RCUX4E9kVef/Kok=; b=nC+UotBFLhYs1LKgOlGULsewAlyCVWiWkAkjAzwrFGaaNq36ts6wO7NG/lTllQMrci yrljWnkTkoJvZPA1o2ZVPqagheIJ8mqlIoYBAyewilCf8Og6i5vDA9urXSioButQwv8i mxigwSs2tNhTyQNbgDBar1H6wF/2RqInIHLrfgofuoYo2WvnmitycS/x5CEsKfMwm/4x YQK0nvVKXVV+Ga4uOd2RObn0iT9wB3RnmZxbiE6KagPL34u9TnNAgnCGpO9Gs+uWGnXt pjdQnQeEJCsL6ZryH3bHdOVScf59l4wn6Uua53177PEf2T9Ce5gB6TC2dbH8dgv1Lf4h Tahg== X-Gm-Message-State: AJaThX7RtdP1KCWpaas7SjyVuCQz1ZO642pewAkO4eHFF7NI+MJV2AaB kxDvXKlyr11culJ2/m/Rp5fsVfxVA9y/JapqPv8e0A== X-Google-Smtp-Source: AGs4zMYkd+SDlw/+U0v8NhLIXxU58RQbfNQWQu7rFAF5UR642BLq2APYynhoS1oaYOb1kvD//u8oxPyFA+B0Kucd9B0= X-Received: by 10.25.23.207 with SMTP id 76mr14161690lfx.123.1512765351691; Fri, 08 Dec 2017 12:35:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 8 Dec 2017 12:35:50 -0800 (PST) In-Reply-To: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> From: Andy Bierman Date: Fri, 8 Dec 2017 12:35:50 -0800 Message-ID: To: Lou Berger Cc: NetMod WG , NetMod WG Chairs Content-Type: multipart/alternative; boundary="001a1141128a6aa533055fda21ea" Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Fri, 08 Dec 2017 20:35:56 -0000 --001a1141128a6aa533055fda21ea Content-Type: text/plain; charset="UTF-8" Hi, I have reviewed draft-07 and my previous comments about NMDA have been addressed. This might be the most important sentence in the draft: sec. 5.3 The datastore schema for MUST be a superset of the combined datastore schema used in all configuration datastores except that YANG nodes supported in a configuration datastore MAY be omitted from if a server is not able to accurately report them. The MUST implies that there is no need to design a YANG library that can support an implementation that violates this MUST (i.e., 1 schema tree for the super-set) The MAY is troublesome because it completely contradicts the conformance expressed in each YANG module supported by the server. Any data node without any if-feature-stmts is mandatory to implement. What about config=false subtrees within a config=true subtree? Can they be omitted from as well, or does the draft just intend to omit the operational value of config=true nodes? Should be specific. Perhaps this draft does not need the MAY half of the sentence at all. The YANG library can specify that it is for conformance-reporting, not conformance-defining. Andy On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger wrote: > All, > > This starts a second working group last call on > draft-ietf-netmod-revised-datastores. > > As this is a 2nd LC that is focused on changes since the last LC, it > closes in *one* week. The working group last call ends on December 11. > Please send your comments to the netmod mailing list. > > At this point, we're most interested in verifying that previous comments > are addressed since the last call on the -04 rev of the draft was held. > > A summary of changes can be found at > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4 > > A diff can be found at > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod- > revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt > > Comments along the of: I have reviewed this version of the document and it > addresses my previous comments would be particularly helpful. > > Thank you, > Netmod Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1141128a6aa533055fda21ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have reviewed = draft-07 and my previous comments about NMDA have been addressed.

This = might be the most important sentence in the draft:

sec. 5.3
   The datastore schema for <operational> MU=
ST be a superset of the
   combined datastore schema used in all configuration datastores except
   that YANG nodes supported in a configuration datastore MAY be omitted
   from <operational> if a server is not able to accurately report th=
em.
The MUST implies that there = is no need to design a YANG library that can support
an implementation that violates this MUST (i.e., 1 schema tr= ee for the super-set)

The MAY is troublesome because it completely cont= radicts the conformance expressed
in e= ach YANG module supported by the server.=C2=A0 Any data node without any
if-feature-stmts is mandatory to impleme= nt.

What about config=3Dfalse subtrees within a config=3Dtrue subtree?<= /div>
Can they be omitted from <operation= al> as well, or does the draft just intend to
omit the operational value of config=3Dtrue nodes?=C2=A0 Should = be specific.

Perhaps this draft does not need the MAY half of the sente= nce at all.
The YANG library can speci= fy that it is for conformance-reporting, not conformance-defining.


=


Andy


On Mon, Dec 4,= 2017 at 6:35 AM, Lou Berger <lberger@labn.net> wrote:
All,

This starts a second working group last call on
draft-ietf-netmod-revised-datastores.

As this is a 2nd LC that is focused on changes since the last LC, it closes= in *one* week. The working group last call ends on December 11. Please sen= d your comments to the netmod mailing list.

At this point, we're most interested in verifying that previous comment= s are addressed since the last call on the -04 rev of the draft was held.
A summary of changes can be found at
https://mailarchive.ietf.org= /arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4

A diff can be found at
https://tools.i= etf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ietf-netmod-= revised-datastores-04.txt&url2=3Ddraft-ietf-netmod-revis= ed-datastores-07.txt

Comments along the of: I have reviewed this version of the document and it = addresses my previous comments would be particularly helpful.

Thank you,
Netmod Chairs

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

--001a1141128a6aa533055fda21ea-- From nobody Fri Dec 8 14:21:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F011270AE for ; Fri, 8 Dec 2017 14:21:03 -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 5H4Q4VJqRM-T for ; Fri, 8 Dec 2017 14:21:00 -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 4998312426E for ; Fri, 8 Dec 2017 14:21:00 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x204so13297032lfa.11 for ; Fri, 08 Dec 2017 14:21:00 -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=Sfgp9WbO42Dd+nX2JnE5+DYFWMqfg/tFbmPz8iu0PQo=; b=cvJ3Ze8g9eU3C3MNjIC1b9vdMg115etPf3Dbf2zzfGLnkiAzLPDCv5tw9xTDdcCO1x moViGQ4/bBhm3mTeDddVtAiv5mog9eQnsH0vkafnSAm+dGhTUiwVCVK+asT9hsInHrTI IQUvTzgOMnzWJIxfpwX9RVxdx4fFljYp0nBWEWmoaI0jfZG4M/kP3p7G2q9DhIBtGBuB 4Nv1lf1V4V7fPs4wD11hLEuw5R8k+TppLSpC3pmZkCUDffgfYj2Z+CfxOlHuhaC+37f6 bG7lSuzaO62xND99VqIIIqgPZuQv4mCHqpUVsWj5Yj9wuRPA3MLwMC2z39gXR+eO3wpo ZY+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:cc; bh=Sfgp9WbO42Dd+nX2JnE5+DYFWMqfg/tFbmPz8iu0PQo=; b=gby6LAVtnEpJgMBrZwbPJZRX/rcnRg18is5BBjn2R480J6W7pVzwYIJqkAgnPA+574 xsDwSlxCDWl/bTA66LmGU1i5NcLJRlxPLGi5N1UltUziwthgofPOzIjrnLka5nW8mPoi LQyYoa56AHqCd8ZxFYSe+tlgNLTl9/n2XkcNpUfHIJlaJIT2unjYbsCNrXBU0qc7fH6r 803rZJgpk+MKjyPkPcP6ite5ar7l5UdRRVk6zWfbNYypU3O4Phshh1CXGbamHiVKZWoH PtB9Fg4gNQ3m7dUYGtHaFWEN7dS6jiE+aYsMH/lClH+eXpiIX35gcbt65VdaVLaFKzqs TXxA== X-Gm-Message-State: AKGB3mKy7AQ8EUTlO1Nkngv+mUQoVJKHJ4NRYe+jnT94Sj4nmeBvEHr+ 1q80PPIW3wLdRMB7dnYbB+Ir/7GCT3TSeVFJz4INDw== X-Google-Smtp-Source: AGs4zMbSZ7w9NIEkzWDOG38WjxnpE80e/K8kCVlThdRL/5r40JoxCcLeBFQbTdLJJ+0jwE7lTPOr8k8YP+jN/td8vMs= X-Received: by 10.46.57.10 with SMTP id g10mr7463130lja.77.1512771658502; Fri, 08 Dec 2017 14:20:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 8 Dec 2017 14:20:57 -0800 (PST) In-Reply-To: <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> References: <20171115.101454.1576716701146734257.mbj@tail-f.com> <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net> <20171117070043.pm7rn25yj3hxum3q@elstar.local> <4df13805-f4c8-89da-f986-64da816bea0b@labn.net> From: Andy Bierman Date: Fri, 8 Dec 2017 14:20:57 -0800 Message-ID: To: Lou Berger Cc: Mehmet Ersue , Mahesh Jethanandani , Robert Wilton , NetMod WG Content-Type: multipart/alternative; boundary="089e082f5ce454ef1f055fdb99d2" Archived-At: Subject: Re: [netmod] tree diagram guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Dec 2017 22:21:04 -0000 --089e082f5ce454ef1f055fdb99d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, These changes are OK with me. Andy On Thu, Dec 7, 2017 at 3:38 PM, Lou Berger wrote: > Hi, > > Following up on this discussion (and hoping to wrap it up): > > I have created two wikis off of > https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis > content and the other for section 3 of tree diagrams. I also propose > the following changes to the tree-diagrams draft: > > To section 3 intro, add: > For the most current quidelines being developed, please see the IETF > NetMod Working > Group Wiki, see: https://trac.ietf.org/trac/netmod/wiki/WikiStart > > Add : > 3.2. Groupings > > If the YANG module is comprised of groupings only, then the tree > diagram should contain the groupings. The 'pyang' compiler can be > used to produce a tree diagram with groupings using the "-f tree -- > tree-print-groupings" command line parameters. > > And to section 3.3, start with: > > Tree diagrams can be split into sections to correspond to document > structure. > > For 6087 bis, I think section 3.4 gets replaced with something like. > > YANG tree diagrams provide a concise representation of a YANG module, > and SHOULD be included to help readers understand YANG module > structure. Guidelines on tree diagrams can be found in Section 3 of > [I-D.ietf-netmod-yang-tree-diagrams]. > > These changes can be found at: > https://github.com/netmod-wg/yang-tree-diagrams/commit/ > 53919e0a4549c285758eb5aaaf02cf980269afff > > This leaves the intended status as the key open issue on the draft. > > Lou > > > On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote: > > I am confused. I think there was some consensus to > > > > - include all tree related guidelines in the tree document, remove all > tree > > related guidelines from 6087bis and have 6087bis point to the tree > document > > (which it already does) > > > > The rest is pointless since AFAIK there is no wiki guidelines pages to > > point to and there is AFAIK nobody in place to actually maintain such > > a wiki page. Perhaps a wiki is the future but until future has > > arrived, we should not point to it. > > > > The other proposal I heard was to have a landing page that points to > > the current guideline work which points to the relevant documents. A > > wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does n= ot > > affect the documents. > > > > /js > > > > PS: I am happy to add pointers to guidelines as a section to the > > wikipedia page. > > > > On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote: > >> To circle back to this. My sense of this discussion (as contributor) = is > >> (a) the tree diagrams draft should be updated to point to a "guideline= s" > >> wiki page for "the most current guidelines" > >> (b) the tree diagrams draft should be updated to include a full set of > the > >> current tree related guidelines > >> (c) 6087bis should be updated to point to a "guidelines" wiki page for > "the > >> most current guidelines" > >> (d) 6087bis should have it's tree guidelines point to the tree diagram= s > >> document -- in addition to pointing to the wiki > >> > >> Does this sound right? > >> > >> Lou > >> (as tree co-author) > >> > >> On 11/16/2017 11:04 AM, Mehmet Ersue wrote: > >>> The Wiki is useful as a starting point providing a collection of > pointers to guideline RFCs and the bis-revisions in development. > >>> > >>> Cheers, > >>> Mehmet > >>> > >>>> -----Original Message----- > >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh > >>>> Jethanandani > >>>> Sent: Thursday, November 16, 2017 7:39 AM > >>>> To: Robert Wilton > >>>> Cc: netmod@ietf.org > >>>> Subject: Re: [netmod] tree diagram guidelines > >>>> > >>>> Other SDOs can and follow the work in IETF through the RFCs we > publish. > >>>> They do not follow wiki=E2=80=99s, unless the document itself says, = =E2=80=9Chere are > the > >>>> guidelines, but if you are looking for the latest, go to this wiki= =E2=80=9D. > I therefore > >>>> would support the proposal outlined below. It gives the SDO a stable > point of > >>>> reference with a document, which gets updated occasionally, but also > allows > >>>> them to peak at what is coming down the pipeline. > >>>> > >>>> Thanks. > >>>> > >>>>> On Nov 15, 2017, at 6:53 PM, Robert Wilton > wrote: > >>>>> > >>>>> I liked the suggestion from Chris Hopps: > >>>>> > >>>>> I think that it was along the lines of ... > >>>>> > >>>>> The RFC contains a reference at the top that states that updates to > the > >>>> guidelines is available on a wiki at .... > >>>>> Every few years the guidelines on the wiki can be folded into a > latest > >>>> version of the guidelines draft. > >>>>> 6087bis looks to be 3.5 years old. Should folks, e.g. at BBF,, > IEEE, or MEF be > >>>> using the latest draft guidelines, or should then use the published > RFC until > >>>> 6087bis is actually republshed? > >>>>> Thanks, > >>>>> Rob > >>>>> > >>>>> > >>>>> On 15/11/2017 10:14, Martin Bjorklund wrote: > >>>>>> Hi, > >>>>>> > >>>>>> There was a proposal in the meeting today to have the guidelines f= or > >>>>>> tree diagrams in a wiki, instead of having them in 6087bis or in t= he > >>>>>> tree diagram document. > >>>>>> > >>>>>> Was the proposal really to have a wiki for just the tree guideline= s, > >>>>>> or was the proposal to withdraw 6087bis from the process and inste= ad > >>>>>> publish all guidelines as a wiki? > >>>>>> > >>>>>> If it is the former, is it really worth it? > >>>>>> > >>>>>> Advantages with a wiki: > >>>>>> > >>>>>> + It can be updated more easily > >>>>>> > >>>>>> Some drawbacks: > >>>>>> > >>>>>> - It can be updated more easily > >>>>>> (meaning they are less stable) > >>>>>> > >>>>>> - Wikis tend to not be alive after some time, and are not that > >>>>>> easy to find. Just try to find the various YANG-related wik= is > >>>>>> we've tried to maintain over the years. > >>>>>> > >>>>>> - Links in RFCs also have problems. Sites are re-orginized et= c. > >>>>>> As an example, the link to the security guidelines template = in > >>>>>> RFC 6087 doesn't work anymore. > >>>>>> > >>>>>> - People that are looking for a stable reference will have > problems > >>>>>> (I think Rob mentioned that IEEE still refer to RFC 6087 > (which > >>>>>> is understandable; that's the published version). > >>>>>> > >>>>>> - Who maintains the Wiki, and what are the rules for updating > it? > >>>>>> > >>>>>> > >>>>>> I suggest we have the tree-related guidelines (actually just a few > >>>>>> sentences) in the tree draft, and since 6087bis already refers to > >>>>>> this document it is not a big problem that guidelines are spread o= ut > >>>>>> over several documents that are difficult to find. > >>>>>> > >>>>>> > >>>>>> > >>>>>> /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 > >>>> 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 list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > --089e082f5ce454ef1f055fdb99d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

These changes are OK with me.
=



Andy

=

On Thu, Dec= 7, 2017 at 3:38 PM, Lou Berger <lberger@labn.net> wrote:
=
Hi,

Following up on this discussion (and hoping to wrap it up):

I have created two=C2=A0 wikis off of
https://trac.ietf.org/trac/netmod/wiki/WikiStar= t, one for 6087bis
content and the other for section 3 of tree diagrams.=C2=A0 I also propose<= br> the following changes to the tree-diagrams draft:

To section 3 intro, add:
=C2=A0=C2=A0=C2=A0 For the most current quidelines being developed, please = see the IETF
NetMod Working
=C2=A0=C2=A0 Group Wiki, see:=C2=A0 https://trac.iet= f.org/trac/netmod/wiki/WikiStart

Add :
=C2=A0 3.2.=C2=A0 Groupings

=C2=A0=C2=A0 If the YANG module is comprised of groupings only, then the tr= ee
=C2=A0=C2=A0 diagram should contain the groupings.=C2=A0 The 'pyang'= ; compiler can be
=C2=A0=C2=A0 used to produce a tree diagram with groupings using the "= -f tree --
=C2=A0=C2=A0 tree-print-groupings" command line parameters.

And to section 3.3, start with:

=C2=A0=C2=A0 Tree diagrams can be split into sections to correspond to docu= ment
=C2=A0=C2=A0 structure.

For 6087 bis, I think section 3.4 gets replaced with something like.

=C2=A0=C2=A0=C2=A0 YANG tree diagrams provide a concise representation of a= YANG module,
=C2=A0=C2=A0 and SHOULD be included to help readers understand YANG module<= br> =C2=A0 =C2=A0 structure.=C2=A0 Guidelines on tree diagrams can be found in = Section 3 of
=C2=A0 =C2=A0 [I-D.ietf-netmod-yang-tree-diagrams].

These changes can be found at:
https= ://github.com/netmod-wg/yang-tree-diagrams/commit/53919e0a4549c28= 5758eb5aaaf02cf980269afff

This leaves the intended status as the key open issue on the draft.

Lou


On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote:
> I am confused. I think there was some consensus to
>
> - include all tree related guidelines in the tree document, remove all= tree
>=C2=A0 =C2=A0related guidelines from 6087bis and have 6087bis point to = the tree document
>=C2=A0 =C2=A0(which it already does)
>
> The rest is pointless since AFAIK there is no wiki guidelines pages to=
> point to and there is AFAIK nobody in place to actually maintain such<= br> > a wiki page. Perhaps a wiki is the future but until future has
> arrived, we should not point to it.
>
> The other proposal I heard was to have a landing page that points to > the current guideline work which points to the relevant documents. A > wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does = not
> affect the documents.
>
> /js
>
> PS: I am happy to add pointers to guidelines as a section to the
>=C2=A0 =C2=A0 =C2=A0wikipedia page.
>
> On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:
>> To circle back to this.=C2=A0 My sense of this discussion (as cont= ributor) is
>> (a) the tree diagrams draft should be updated to point to a "= guidelines"
>> wiki page for "the most current guidelines"
>> (b) the tree diagrams draft should be updated to include a full se= t of the
>> current tree related guidelines
>> (c) 6087bis should be updated to point to a "guidelines"= wiki page for "the
>> most current guidelines"
>> (d) 6087bis should have it's tree guidelines point to the tree= diagrams
>> document -- in addition to pointing to the wiki
>>
>> Does this sound right?
>>
>> Lou
>> (as tree co-author)
>>
>> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
>>> The Wiki is useful as a starting point providing a collection = of pointers to guideline RFCs and the bis-revisions in development.
>>>
>>> Cheers,
>>> Mehmet
>>>
>>>> -----Original Message-----
>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh
>>>> Jethanandani
>>>> Sent: Thursday, November 16, 2017 7:39 AM
>>>> To: Robert Wilton <rwilton@cisco.com>
>>>> Cc: netmod@ietf.org=
>>>> Subject: Re: [netmod] tree diagram guidelines
>>>>
>>>> Other SDOs can and follow the work in IETF through the RFC= s we publish.
>>>> They do not follow wiki=E2=80=99s, unless the document its= elf says, =E2=80=9Chere are the
>>>> guidelines, but if you are looking for the latest, go to t= his wiki=E2=80=9D. I therefore
>>>> would support the proposal outlined below. It gives the SD= O a stable point of
>>>> reference with a document, which gets updated occasionally= , but also allows
>>>> them to peak at what is coming down the pipeline.
>>>>
>>>> Thanks.
>>>>
>>>>> On Nov 15, 2017, at 6:53 PM, Robert Wilton <rwilton@cisco.com> wrote:
>>>>>
>>>>> I liked the suggestion from Chris Hopps:
>>>>>
>>>>> I think that it was along the lines of ...
>>>>>
>>>>> The RFC contains a reference at the top that states th= at updates to the
>>>> guidelines is available on a wiki at ....
>>>>> Every few years the guidelines on the wiki can be fold= ed into a latest
>>>> version of the guidelines draft.
>>>>> 6087bis looks to be 3.5 years old.=C2=A0 Should folks,= e.g. at BBF,, IEEE, or MEF be
>>>> using the latest draft guidelines, or should then use the = published RFC until
>>>> 6087bis is actually republshed?
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 15/11/2017 10:14, Martin Bjorklund wrote:
>>>>>> Hi,
>>>>>>
>>>>>> There was a proposal in the meeting today to have = the guidelines for
>>>>>> tree diagrams in a wiki, instead of having them in= 6087bis or in the
>>>>>> tree diagram document.
>>>>>>
>>>>>> Was the proposal really to have a wiki for just th= e tree guidelines,
>>>>>> or was the proposal to withdraw 6087bis from the p= rocess and instead
>>>>>> publish all guidelines as a wiki?
>>>>>>
>>>>>> If it is the former, is it really worth it?
>>>>>>
>>>>>> Advantages with a wiki:
>>>>>>
>>>>>>=C2=A0 =C2=A0 +=C2=A0 It can be updated more easily=
>>>>>>
>>>>>> Some drawbacks:
>>>>>>
>>>>>>=C2=A0 =C2=A0 -=C2=A0 It can be updated more easily=
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(meaning they are less s= table)
>>>>>>
>>>>>>=C2=A0 =C2=A0 -=C2=A0 Wikis tend to not be alive af= ter some time, and are not that
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0easy to find.=C2=A0 Just= try to find the various YANG-related wikis
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0we've tried to maint= ain over the years.
>>>>>>
>>>>>>=C2=A0 =C2=A0 -=C2=A0 Links in RFCs also have probl= ems.=C2=A0 Sites are re-orginized etc.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0As an example, the link = to the security guidelines template in
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6087 doesn't wor= k anymore.
>>>>>>
>>>>>>=C2=A0 =C2=A0 -=C2=A0 People that are looking for a= stable reference will have problems
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(I think Rob mentioned t= hat IEEE still refer to RFC 6087 (which
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0is understandable; that&= #39;s the published version).
>>>>>>
>>>>>>=C2=A0 =C2=A0 -=C2=A0 Who maintains the Wiki, and w= hat are the rules for updating it?
>>>>>>
>>>>>>
>>>>>> I suggest we have the tree-related guidelines (act= ually just a few
>>>>>> sentences) in the tree draft, and since 6087bis al= ready refers to
>>>>>> this document it is not a big problem that guideli= nes are spread out
>>>>>> over several documents that are difficult to find.=
>>>>>>
>>>>>>
>>>>>>
>>>>>> /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/l= istinfo/netmod
>>>> Mahesh Jethanandani
>>>> mjethanandani@g= mail.com
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listi= nfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/netmod
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netm= od


--089e082f5ce454ef1f055fdb99d2-- From nobody Sat Dec 9 03:49:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88458127698; Sat, 9 Dec 2017 03:49:24 -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 cYC5SfKtGirs; Sat, 9 Dec 2017 03:49:22 -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 B92131201F8; Sat, 9 Dec 2017 03:49:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 37A861424F47; Sat, 9 Dec 2017 12:49:19 +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 9kOd37tPkgMm; Sat, 9 Dec 2017 12:49:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 025071424F4B; Sat, 9 Dec 2017 12:49:19 +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 ZCAdw3VxeFEr; Sat, 9 Dec 2017 12:49:18 +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 C51BE1424F47; Sat, 9 Dec 2017 12:49:18 +0100 (CET) From: Vladimir Vassilev To: Andy Bierman , Kent Watsen Cc: "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> Message-ID: <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> Date: Sat, 9 Dec 2017 12:49:18 +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] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2017 11:49:24 -0000 On 12/08/2017 07:01 PM, Andy Bierman wrote: > Hi, > > A library per datastore sounds too complicated. I am not proposing that. The fundamental point proposed is that the datastore relevant bits are=20 kept in the ietf-datastores module instead of merging everything in a=20 new ietf-yang-library entangled monster module. If needed=20 ietf-datastores can augment ietf-yang-library but ietf-yang-library=20 should be usable on its own without ietf-datastores. The solution is=20 coherent and modular and addresses the problem statement. > I prefer the proposal that was made at the IETF meeting that had > a 'not-implemented-in' leaf-list and a single module list. This constraint is already specified in the text of the revised=20 datastores draft. Clients conforming to the draft can expect servers to=20 comply with the MUST requirement even if there is a separate=20 yang-library data tree for each datastore the constraint of=20 configuration stores mapping to 'operational' should be enforced=20 according to the draft. There is no contradiction here. That said I would be also be OK with ietf-datastores augmenting=20 ietf-yang-library with such a leaf-list ('not-implemented-in' leaf-list)=20 as a more constrained flavor of the same approach instead of going for=20 independent copies of yang-library data. For any of that to happen=20 change in ietf-datastores.yang is needed and change in the original=20 rfc7895 ietf-yang-library is not needed at all. Vladimir > > Why is it interesting to have a separate module list for regular=20 > modules and imported modules? > I prefer to keep the conformance leaf and not change the module list. > > NMDA needs to be possible to implement with a single schema tree such=20 > that a module > is implemented in all datastores, or a subset of all datastores.=C2=A0=20 > Otherwise it probably won't > get supported in clients. > > > Andy > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > wrote: > > CC-ing NETCONF, where the draft is being worked on. > > Kent > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote= : > > > > > > Yes. The default value for yang-library-datastore leaf is > ds:operational > > > (the only possible one for the ds:operational datastore). This > is backward > > > compatible. If one needs different model for 'running', etc. > then a new > > > datastore identity has to be defined=C2=A0 and set in place of = the > default value. > > > Then this identity can be used to read the yang-library data wi= th > > > . > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > datastore (lets call it ) that reports the > schema for > > ? Is there another datastore? > Will > > the recursion end? Perhaps it does since > > might have itself listed as the schema defining datastore. I gues= s > > Lada will like these kind of meta and meta-meta datastores. > > Not really. Metadata needn't be in datastores. > > Lada > > > > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3v= oDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwq= YmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeF= RrvQI5l8&e=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 From nobody Sat Dec 9 09:44:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56D012726E for ; Sat, 9 Dec 2017 09:44:05 -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 mlNtqrORs7ep for ; Sat, 9 Dec 2017 09:44:02 -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 F1D331200FC for ; Sat, 9 Dec 2017 09:44:01 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id x20so15013556lff.1 for ; Sat, 09 Dec 2017 09:44:01 -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=JazFw+k1T9cT1bmg608gM23L2nvDOKfWun5JsVeNjPE=; b=2FGkqr2ggdJDh3Q9Anl4lVOrMQf0PTcqzkjG4gtWrzpePIFzX91gwydcSt04M9G6zi utv0djB/iZMYmtZAwI8G4t2zGglITkBDlLQWVLbvT5Brc59fflttlxXgLuEpHV59wI3E ljPP6jS2AcjtJgvSIFrFjfglQlbdrN/gqEtCikmhVqWupeBvRsf+KaOvP9PCVJPxewZn rTv1YMdZnec1cPQrnL5shstdiXrUm9dRPn7PfP75lFxDZgKHRkptrCH6XiyH1fcmG8f7 s7PpyXk8oSp6OW8sl7t/wkEA781rNBTuKwajP72170x2aiKZ7re5VKJQ/ydI3fHEP2i9 h+Jg== 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=JazFw+k1T9cT1bmg608gM23L2nvDOKfWun5JsVeNjPE=; b=AoUBGdc1ZC3aUMB6TM/RnDZA4g8epmP8esJk407+NEQ8aq1pqBnxezPfwKq6cvPoy8 Z+RJIKkQEnh+WO+HuEoDQhPA6RbPnmwiqkaediwkxhlMPw7OonX7kg7Vt07cl8NhW275 xD011lpzrHAoAi9Ioeqe6Vt2IXxdquQsFuL0RyRYfF+KNL45VKQHlVYx7qIQB+TTfu2L mMUTsl0kAGxmVpylbO6x1lhslFXMk1vl/YpRs72DuN9izDbtYfboY56Fthy/bu3xZg7g lyT/FriaaKZrNzd+sdN0kxgfTttKc87h9dsabFZ+w+QM6dMBGP1E2D+/AdUHZNZFjUyT IqSw== X-Gm-Message-State: AJaThX6Epq6qD4clbqkJ1E3jVQAF/Eh+/ugc1+/4Tglfb7a216w041co bB41KXNPxfDHr5VKoFQyvToX7WxyY4bcyorOuIp/cKyz X-Google-Smtp-Source: AGs4zMZjiEG/1B5RI9e0QLZ9yotgfRigW1CUOkB+Rx8KZXOo6NTp+iPyJZDowHNLl/ALlQU9EWNZn0WfR4ewgg+J0jY= X-Received: by 10.46.70.18 with SMTP id t18mr17751227lja.190.1512841440071; Sat, 09 Dec 2017 09:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Sat, 9 Dec 2017 09:43:59 -0800 (PST) In-Reply-To: <20171208.104741.1957721911727198135.mbj@tail-f.com> References: <20171208.104741.1957721911727198135.mbj@tail-f.com> From: Andy Bierman Date: Sat, 9 Dec 2017 09:43:59 -0800 Message-ID: To: Martin Bjorklund , Netconf Cc: NetMod WG Content-Type: multipart/alternative; boundary="f403045f771ea32625055febd813" Archived-At: Subject: Re: [netmod] YANG library structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Dec 2017 17:44:06 -0000 --f403045f771ea32625055febd813 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 8, 2017 at 1:47 AM, Martin Bjorklund wrote: > Hi, > > There has been quite a lot of discussion about the YANG library > data model on the list. The authors of draft-ietf-netconf-rfc7895bis > have tried to understand all arguments in the discussion, and provide > a solution. Below are 3 solution proposals (we have discussed more, > but they are basically just variations on the same themes). > > Absolute Requirements > --------------------- > > o RFC 7950, Section 5.6.5 says: > > A server MUST NOT implement more than one revision of a module. > > o draft-ietf-netmod-revised-datastores says: > > The conventional configuration datastores [...] share exactly > the same datastore schema > > o draft-ietf-netmod-revised-datastores says: > > The datastore schema for MUST be a superset of the > combined datastore schema used in all configuration datastores > except that YANG nodes supported in a configuration datastore MAY > be omitted from if a server is not able to > accurately report them. > > > These requirements (of course) still hold, and we think that the YANG > library document should explain what they imply for the data reported > as part of the library. (For example, all conventional datastores > MUST have a reference to the same "schema"). > > > Objectives (in no particular order) > ----------------------------------- > > 1. As efficient as possible for a client to consume. > > Since the size of the yang library can be quite large, it should > be possible for clients to cache the yang library information. > > Why do all of the alternatives ignore this objective? All of them are 2X to 3X larger for message encoding than the IETF100 solution. Why is the schema list needed at all? Is this for schema-mount? What does each schema list instance represent in an NMDA server? The existing RFC 7895 library could be used, and each special feature (NMDA, licensing, who-knows-what-else) can augment the module list with additional data. I guess YANG stability only matters to the people who already ship code that does it the existing way. Given that the new NMDA version (modules instead of modules-state) is read-only, I fail to see how deprecating the modules-state subtree solves any real problem. IMO, all of the new proposals are moving in the wrong direction and force the client to potentially retrieve lots of conflicting schema information. An existing client can easily be adapted to work with a single module list / schema tree that now applies to a subset of datastores (instead of all datastores). If the client now needs to retrieve and resolve potentially overlapping module lists / schema trees, then deployment may be limited to new 2nd party client implementations only. Andy 2. A dynamic datastore must be able to implement a module or feature > that is not implemented in the conventional datastores. > > 3. It must be possible to NOT implement a module or feature in > operational, even if it is implemented in some other datastore. > > This is required for transition purposes; a server that wants to > implement should not have to implement all modules at > once. > > 4. A given module can only be implemented in one revision in all > datastores. If a module is implemented in more than one > datastores, the same revision is implemented in all these > datastores. > > 5. Multiple revisions can be used for import, if import-by revision > is used. > > 6. Nice to have: make it possible to be used by schema mount > > > It should be noted that because of 2 and 3 (and 6), the original data > model in RFC 7895 cannot be used. > > > Use Cases > --------- > > Here's a set of use cases that must be supported. > > C1. conventional + operational, all have the same schema > > C2. conventional + operational, ietf-hardware is not implemented in > conventional > > C3. conventional + operational, some modules not yet implemented in > operational, and some modules are partly implemented in > operational. > > C4. conventional + operational + ephemeral, ephemeral has its own > set of modules > > > > Alt. A. > ------- > > Each datastore refers to a schema, and each schema contains a flat > list of all modules, features, etc. > > +--ro yang-library > +--ro schema* [name] > | +--ro name string > | +--ro checksum string > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? revision-identifier > | | +--ro namespace inet:uri > | | +--ro location* inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? revision-identifier > | | | +--ro location* inet:uri > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | +--ro deviation* [module] > | | +--ro module -> ../../name > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro namespace inet:uri > | +--ro location* inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > > How does this solution handle the use cases above? > > C1: One schema, all datastores refer to this schema. > > C2: Two schemas, "conventional" and "operational". They differ in > just one element (ietf-hardware). All other module information > is entirely duplicated in both. > > C3: Two schemas, "conventional" and "operational". They differ in > the modules not implemented in operational, and operational also > has some deviation modules with "not-implemented". > > C4: Three schemas, "conventional", "ephemeral", "operational". > "operational" contains the union of all modules in the other > two. > > > Pro: simple on the client, simple on the server > > Con: verbose, since a single difference requires a complete, new, > schema. > > > Alt. B. > ------- > > Each datastore refers to a schema, and each schema contains a list > of references to module-sets, and each module-set contains a flat > list of all modules, features, etc. > > When combining module-sets into a schema there MUST NOT be any > duplicate module definitions in the module-sets. > > > +--ro yang-library > +--ro module-set* [name] > | +--ro name string > | +--ro checksum string > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? revision-identifier > | | +--ro namespace inet:uri > | | +--ro location* inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? revision-identifier > | | | +--ro location* inet:uri > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | +--ro deviation* [module] > | | +--ro module -> ../../name > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro namespace inet:uri > | +--ro location* inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro schema* [name] > | +--ro name string > | +--ro checksum string > | +--ro module-set* -> ../../module-set/name > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > How does this solution handle the use cases above? > > C1: One module-set, one schema, all datastores refer to this schema, > the schema refers to the single module-set. > > C2: Two schemas, "conventional" and "operational", and two > module-sets. One module-set contains just "ietf-hardware" and > the other everything else. The "operational" schema refers to > both module-sets, and the "conventional" to just the one without > "ietf-hardware". > > C3: Two schemas, "conventional" and "operational", and three > module-sets. One module-set contains all modules fully > implemented in both conventional and operational, one contains > the modules implemented only in conventional, and one the > modules and deviations for the partly implemented modules in > operational. > > C4: Three schemas, "conventional", "ephemeral", "operational", but > just two module-sets. "conventional" refers to one of the > module-sets, and "ephemeral" to the other. "operational" refers > to both. > > Pro: less verbose > > Con: the client has to follow extra references and must combine the > result from the references into a single schema. > > > Alt. C. > ------- > > (This is the draft -02 version with just some name changes) > > Each datastore refers to a schema, and each schema contains a list > of references to each module it includes. > > +--ro yang-library > +--ro module* [id] > | +--ro id string > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > | +--ro namespace inet:uri > | +--ro feature* yang:yang-identifier > | +--ro deviation* [module] > | | +--ro module -> ../../id > | +--ro conformance-type enumeration > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro schema* [name] > | +--ro name string > | +--ro module* -> ../../module/id > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > How does this solution handle the use cases above? > > C1: One schema, all datastores refer to this schema, > the schema refers to all modules. > > C2: Two schemas, "conventional" and "operational", and the module > list contains all modules. The "operational" schema refers to > all modules, and "conventional" to all modules except > "ietf-hardware". > > C3: similar to C2, except there will be two entries in the module > list for evenry module that is partly implemented in > operational. > > C4: Three schemas, "conventional", "ephemeral", "operational", and > the module list contains all modules. > Each schema refers to the modules it supports. > > Pro: All modules available are listed in one place. > > Con: the client has to follow extra references and must combine the > result from the references into a single schema. > > the least "direct" solution due to the module "id". > > probably a bit tricky to implement on the server. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f403045f771ea32625055febd813 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 8, 2017 at 1:47 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Hi,

There has been quite a lot of discussion about the YANG library
data model on the list.=C2=A0 The authors of draft-ietf-netconf-rfc7895bis<= br> have tried to understand all arguments in the discussion, and provide
a solution.=C2=A0 Below are 3 solution proposals (we have discussed more, but they are basically just variations on the same themes).

Absolute Requirements
---------------------

o=C2=A0 RFC 7950, Section 5.6.5 says:

=C2=A0 =C2=A0 =C2=A0A server MUST NOT implement more than one revision of a= module.

o=C2=A0 draft-ietf-netmod-revised-datastores says:

=C2=A0 =C2=A0 =C2=A0The conventional configuration datastores [...] share e= xactly
=C2=A0 =C2=A0 =C2=A0the same datastore schema

o=C2=A0 draft-ietf-netmod-revised-datastores says:

=C2=A0 =C2=A0 =C2=A0The datastore schema for <operational> MUST be a = superset of the
=C2=A0 =C2=A0 =C2=A0combined datastore schema used in all configuration dat= astores
=C2=A0 =C2=A0 =C2=A0except that YANG nodes supported in a configuration dat= astore MAY
=C2=A0 =C2=A0 =C2=A0be omitted from <operational> if a server is not = able to
=C2=A0 =C2=A0 =C2=A0accurately report them.


These requirements (of course) still hold, and we think that the YANG
library document should explain what they imply for the data reported
as part of the library.=C2=A0 (For example, all conventional datastores
MUST have a reference to the same "schema").


Objectives (in no particular order)
-----------------------------------

1. As efficient as possible for a client to consume.

=C2=A0 =C2=A0Since the size of the yang library can be quite large, it shou= ld
=C2=A0 =C2=A0be possible for clients to cache the yang library information.=



Why do all of the alter= natives ignore this objective?
All of them are 2X to 3X larger fo= r message encoding than the IETF100 solution.

= Why is the schema list needed at all?
Is this for schema-mount?
What does each schema list instance represent in an NMDA server?

The existing RFC 7895 library could be used, and ea= ch special feature
(NMDA, licensing, who-knows-what-else) can aug= ment the module list
with additional data.=C2=A0 I guess YANG sta= bility only matters to the people
who already ship code that does= it the existing way.=C2=A0 Given that the new NMDA
version (modu= les instead of modules-state) is read-only, I fail to see how
dep= recating the modules-state subtree solves any real problem.

<= /div>
IMO, all of the new proposals are moving in the wrong direction a= nd force
the client to potentially retrieve lots of conflicting s= chema information.
An existing client can easily be adapted to wo= rk with a single module list / schema
tree that now applies to a = subset of datastores (instead of all datastores).
If the client n= ow needs to retrieve and resolve potentially overlapping
module l= ists / schema trees, then deployment may be limited to new
2nd pa= rty client implementations only.


An= dy


2. A dynamic datastore must be able to implement a module or feature
=C2=A0 =C2=A0that is not implemented in the conventional datastores.

3. It must be possible to NOT implement a module or feature in
=C2=A0 =C2=A0operational, even if it is implemented in some other datastore= .

=C2=A0 =C2=A0This is required for transition purposes; a server that wants = to
=C2=A0 =C2=A0implement <operational> should not have to implement all= modules at
=C2=A0 =C2=A0once.

4. A given module can only be implemented in one revision in all
=C2=A0 =C2=A0datastores.=C2=A0 If a module is implemented in more than one<= br> =C2=A0 =C2=A0datastores, the same revision is implemented in all these
=C2=A0 =C2=A0datastores.

5. Multiple revisions can be used for import, if import-by revision
=C2=A0 =C2=A0is used.

6. Nice to have: make it possible to be used by schema mount


It should be noted that because of 2 and 3 (and 6), the original data
model in RFC 7895 cannot be used.


Use Cases
---------

Here's a set of use cases that must be supported.

=C2=A0 C1. conventional + operational, all have the same schema

=C2=A0 C2. conventional + operational, ietf-hardware is not implemented in<= br> =C2=A0 =C2=A0 =C2=A0 conventional

=C2=A0 C3. conventional + operational, some modules not yet implemented in<= br> =C2=A0 =C2=A0 =C2=A0 operational, and some modules are partly implemented i= n
=C2=A0 =C2=A0 =C2=A0 operational.

=C2=A0 C4. conventional + operational + ephemeral, ephemeral has its own =C2=A0 =C2=A0 =C2=A0 set of modules



Alt. A.
-------

=C2=A0 Each datastore refers to a schema, and each schema contains a flat =C2=A0 list of all modules, features, etc.

=C2=A0 =C2=A0 +--ro yang-library
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro schema* [name]
=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 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro checksum=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro revision?=C2=A0 =C2=A0 rev= ision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro namespace=C2=A0 =C2=A0 ine= t:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro location*=C2=A0 =C2=A0 ine= t:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro submodule* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 = =C2=A0 =C2=A0 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0 = =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro location*=C2=A0 = =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro feature* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 = yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro deviation* [module]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--ro module=C2=A0 = =C2=A0 -> ../../name
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro import-only-module* [name revision= ]
=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=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro revision=C2=A0 =C2=A0= =C2=A0union
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro namespace=C2=A0 =C2= =A0 inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro location*=C2=A0 =C2= =A0 inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro submodule* [name]
=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 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro revision?=C2= =A0 =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro location*=C2= =A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro datastore* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 identityr= ef
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro schema=C2=A0 =C2=A0 -> ../../sc= hema/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro checksum=C2=A0 =C2=A0 =C2=A0string


=C2=A0 How does this solution handle the use cases above?

=C2=A0 C1: One schema, all datastores refer to this schema.

=C2=A0 C2: Two schemas, "conventional" and "operational"= ;.=C2=A0 They differ in
=C2=A0 =C2=A0 =C2=A0 just one element (ietf-hardware).=C2=A0 All other modu= le information
=C2=A0 =C2=A0 =C2=A0 is entirely duplicated in both.

=C2=A0 C3: Two schemas, "conventional" and "operational"= ;.=C2=A0 They differ in
=C2=A0 =C2=A0 =C2=A0 the modules not implemented in operational, and operat= ional also
=C2=A0 =C2=A0 =C2=A0 has some deviation modules with "not-implemented&= quot;.

=C2=A0 C4: Three schemas, "conventional", "ephemeral", = "operational".
=C2=A0 =C2=A0 =C2=A0 "operational" contains the union of all modu= les in the other
=C2=A0 =C2=A0 =C2=A0 two.


=C2=A0 Pro: simple on the client, simple on the server

=C2=A0 Con: verbose, since a single difference requires a complete, new, =C2=A0 =C2=A0 =C2=A0 =C2=A0schema.


Alt. B.
-------

=C2=A0 Each datastore refers to a schema, and each schema contains a list =C2=A0 of references to module-sets, and each module-set contains a flat =C2=A0 list of all modules, features, etc.

=C2=A0 When combining module-sets into a schema there MUST NOT be any
=C2=A0 duplicate module definitions in the module-sets.


=C2=A0 =C2=A0 +--ro yang-library
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro module-set* [name]
=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 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro checksum=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro revision?=C2=A0 =C2=A0 rev= ision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro namespace=C2=A0 =C2=A0 ine= t:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro location*=C2=A0 =C2=A0 ine= t:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro submodule* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 = =C2=A0 =C2=A0 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0 = =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro location*=C2=A0 = =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro feature* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 = yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro deviation* [module]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--ro module=C2=A0 = =C2=A0 -> ../../name
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro import-only-module* [name revision= ]
=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=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro revision=C2=A0 =C2=A0= =C2=A0union
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro namespace=C2=A0 =C2= =A0 inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro location*=C2=A0 =C2= =A0 inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro submodule* [name]
=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 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro revision?=C2= =A0 =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro location*=C2= =A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro schema* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro checksum=C2=A0 =C2=A0 =C2=A0 strin= g
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module-set*=C2=A0 =C2=A0-> ../.= ./module-set/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro datastore* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 identityr= ef
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro schema=C2=A0 =C2=A0 -> ../../sc= hema/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro checksum=C2=A0 =C2=A0 =C2=A0 string

=C2=A0 How does this solution handle the use cases above?

=C2=A0 C1: One module-set, one schema, all datastores refer to this schema,=
=C2=A0 =C2=A0 =C2=A0 the schema refers to the single module-set.

=C2=A0 C2: Two schemas, "conventional" and "operational"= ;, and two
=C2=A0 =C2=A0 =C2=A0 module-sets.=C2=A0 One module-set contains just "= ietf-hardware" and
=C2=A0 =C2=A0 =C2=A0 the other everything else.=C2=A0 The "operational= " schema refers to
=C2=A0 =C2=A0 =C2=A0 both module-sets, and the "conventional" to = just the one without
=C2=A0 =C2=A0 =C2=A0 "ietf-hardware".

=C2=A0 C3: Two schemas, "conventional" and "operational"= ;, and three
=C2=A0 =C2=A0 =C2=A0 module-sets.=C2=A0 One module-set contains all modules= fully
=C2=A0 =C2=A0 =C2=A0 implemented in both conventional and operational, one = contains
=C2=A0 =C2=A0 =C2=A0 the modules implemented only in conventional, and one = the
=C2=A0 =C2=A0 =C2=A0 modules and deviations for the partly implemented modu= les in
=C2=A0 =C2=A0 =C2=A0 operational.

=C2=A0 C4: Three schemas, "conventional", "ephemeral", = "operational", but
=C2=A0 =C2=A0 =C2=A0 just two module-sets. "conventional" refers = to one of the
=C2=A0 =C2=A0 =C2=A0 module-sets, and "ephemeral" to the other.= =C2=A0 "operational" refers
=C2=A0 =C2=A0 =C2=A0 to both.

=C2=A0 Pro: less verbose

=C2=A0 Con: the client has to follow extra references and must combine the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0result from the references into a single schema.=


Alt. C.
-------

=C2=A0 (This is the draft -02 version with just some name changes)

=C2=A0 Each datastore refers to a schema, and each schema contains a list =C2=A0 of references to each module it includes.

=C2=A0 =C2=A0 +--ro yang-library
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro module* [id]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=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 =C2=A0 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro revision?=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro location*=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro namespace=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro feature*=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro deviation* [module]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro module=C2=A0 =C2=A0 -> = ../../id
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro conformance-type=C2=A0 =C2=A0 enum= eration
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro submodule* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0 =C2=A0 =C2= =A0 =C2=A0 yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro revision?=C2=A0 =C2= =A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro location*=C2=A0 =C2= =A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro schema* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 string =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module*=C2=A0 =C2=A0-> ../../mo= dule/id
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro datastore* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro schema=C2=A0 =C2=A0 -> ../../sc= hema/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro checksum=C2=A0 =C2=A0 =C2=A0 =C2=A0string<= br>
=C2=A0 How does this solution handle the use cases above?

=C2=A0 C1: One schema, all datastores refer to this schema,
=C2=A0 =C2=A0 =C2=A0 the schema refers to all modules.

=C2=A0 C2: Two schemas, "conventional" and "operational"= ;, and the module
=C2=A0 =C2=A0 =C2=A0 list contains all modules.=C2=A0 The "operational= " schema refers to
=C2=A0 =C2=A0 =C2=A0 all modules, and "conventional" to all modul= es except
=C2=A0 =C2=A0 =C2=A0 "ietf-hardware".

=C2=A0 C3: similar to C2, except there will be two entries in the module =C2=A0 =C2=A0 =C2=A0 list for evenry module that is partly implemented in =C2=A0 =C2=A0 =C2=A0 operational.

=C2=A0 C4: Three schemas, "conventional", "ephemeral", = "operational", and
=C2=A0 =C2=A0 =C2=A0 the module list contains all modules.
=C2=A0 =C2=A0 =C2=A0 Each schema refers to the modules it supports.

=C2=A0 Pro: All modules available are listed in one place.

=C2=A0 Con: the client has to follow extra references and must combine the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0result from the references into a single schema.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0the least "direct" solution due to the= module "id".

=C2=A0 =C2=A0 =C2=A0 =C2=A0probably a bit tricky to implement on the server= .



/martin

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

--f403045f771ea32625055febd813-- From nobody Sat Dec 9 21:09:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FCC126CD6 for ; Sat, 9 Dec 2017 21:09:47 -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 BjjMubKcBSZD for ; Sat, 9 Dec 2017 21:09:45 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 ECCE11267BB for ; Sat, 9 Dec 2017 21:09:44 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id l24so9461491pfj.6 for ; Sat, 09 Dec 2017 21:09: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:message-id:references :to; bh=2URI5Ti9wgmhVRVBxMAK31DeD6iv5nxGZx86T7Nuddo=; b=LEkiPu7w6B1V7hDUiNR+Hpy9DzBs+q20f0Q7mkjnyDyT27CnaI70o5Qro3aiG0eBeo 1bx3c6TzyRO3va8c/vNDas6OGf9UCYNOMj6VJamqwHZ8HHb+EUPppG9a+Lh3wDXmoEG5 phvX5oNsYTLELQ9Y0+XsYpK1sIPfB3AS+Eu7RIVx3TQKK2AZWqlBMehlrFQXXdsn7aPW EFNQImRtw8OSVMU3RPujRKA5ts3kqZsSnVbMdfhat6b6Js2tBnJhSBnwE/p0iaWnKw0O LxdV9GG37G0laI9Qs2jXaPRMvXBDo+348YyzfPcrRw5FsHhhwmBzzhn74bsb1HbB/i7P GoDQ== 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 :message-id:references:to; bh=2URI5Ti9wgmhVRVBxMAK31DeD6iv5nxGZx86T7Nuddo=; b=iL6t9C/fbm2wmUk0+QGrSf4Kqc/sX4LFn3tp6jXM+FaxVjW0cbCPexSNiamTuNxZPM EBS+NiskqDIz5MTG08WnZ2pfjHcGEpb8zCI5HWU6J1ZovcOY6g/xp1WvuX7ucS1qm1G4 ofYWcqDdTrnK7Yq+0Cb668DdgK7gokrMTHQoUHsaJfRkADCZ563Hl4+UfLlaZkxN/aWy ctOFZzVLgYs1yeZ5wFpzWSxQJPBhEjO/Tw59kUFeh5N1YuSV7au0Deoz6kVn1aiB0V9k epjSvwqztVCNXex4Iz/LhggKATK18yA8ueGR+MwHFZtbPBX7k/07fU8MDZ9blhKoQSAp Wutg== X-Gm-Message-State: AJaThX4ZQlFjWc5+S4AWfPvoyEaOKsnwXXLoNoSrGsjhWF7QVNqOJooy r2PxoiWUMA0plJ14C5gaOdaFTS2x0/Y= X-Google-Smtp-Source: AGs4zMb6GYIiFmWZNdsBCqznFaz94tQ3qOemL9mLht4CVTCPyD84TGjkvWM6dNm250ei7ApG+fPzZA== X-Received: by 10.101.66.66 with SMTP id d2mr34185213pgq.244.1512882583874; Sat, 09 Dec 2017 21:09:43 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:597a:fdc9:4d62:1b47]) by smtp.gmail.com with ESMTPSA id c28sm20819116pfe.69.2017.12.09.21.09.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Dec 2017 21:09:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Sat, 9 Dec 2017 21:09:41 -0800 Cc: Robert Wilton , Jeffrey Haas , Sonal Agarwal , Kristian Larsson , Kristian Larsson , Martin Bjorklund Message-Id: References: <87y3mr3loc.fsf@dev.terastrm.net> <20171128.111715.2283575031970124402.mbj@tail-f.com> To: NetMod WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] IETF ACL 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: Sun, 10 Dec 2017 05:09:47 -0000 --Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This PR tries to = address what are hopefully the last set of comments before we publish = the draft for LC. Unless I hear objections, I will roll in these changes by the end of the = week (Dec. 15). > On Nov 29, 2017, at 12:11 PM, Mahesh Jethanandani = wrote: >=20 > The updated commit here = takes care of restoring =E2=80=9Ctype" to = "acl-type", fixes some indentation issues, adds a choice for =E2=80=9Cl3" = where either =E2=80=9Cipv4" or =E2=80=9Cipv6" can be selected, and a = similar choice at =E2=80=9Cl4" that allows either =E2=80=9Ctcp", =E2=80=9C= udp" or =E2=80=9Cicmp" to be selected, and removes changes for = =E2=80=9Cglobal" attachment point. Will add the last item as a separate = commit. >=20 > Unless I hear objections, I will roll the pr/18 changes into the = master branch in 48 hours. >=20 >> On Nov 28, 2017, at 2:17 AM, Martin Bjorklund > wrote: >>=20 >> Mahesh Jethanandani > wrote: >>> An updated version of the model has been posted as part of the PR = here >>> = >. >>>=20 >>> The particular change removes any-acl from the model, expands on eth >>> (to ethernet), removes acl- prefix for things like acl-type and >>> acl-name. Please review. >>=20 >> I think 99% of the changes in this PR look good. The one >> exception is the typedef that used to be called "acl-type". I think >> it should still be called "acl-type". "type" is too broad. NOTE, >> this is just the typedef; the leaf /access-lists/acl/type should keep >> its name ("type"). >>=20 >>=20 >> /martin >>=20 >>=20 >>=20 >>>=20 >>>> On Nov 27, 2017, at 5:17 AM, Kristian Larsson > >>>> wrote: >>>>=20 >>>>=20 >>>> Robert Wilton > = writes: >>>>=20 >>>>> Thinking about this some more. I'm not sure what it means for the = "ACL >>>>> Type" to be "any-acl". It seems that the "match any packet" should = be >>>>> a >>>>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than = a=20 >>>>> type of ACL. >>>>=20 >>>> Yes, I agree as so far that any-acl makes no sense as an acl-type. = The >>>> way I understood acl-type, and the way that vendors have told me it >>>> will >>>> be used, is to say "this is an IPv4 ACL" and then on an attachment >>>> point >>>> you can specify that only ACLs of acl-type ipv4-acl can be attached = to >>>> the interface. That makes perfect sense. I do not see how any-acl = can >>>> map into this. >>>>=20 >>>> I agree that any-acl is logically a type of ACE but we don't have = an >>>> ace-type and the exact same information can IMHO already be = conveyed >>>> WITHOUT the any-acl type and thus it has no reason to exist. Nor do = we >>>> need a feature for it. >>>>=20 >>>> =46rom what I can tell the any-acl container in the ACE should be = used >>>> to >>>> explicitly signify a match on "any". Think of IOS style ipv4 acl: >>>> permit ip any any >>>>=20 >>>> We have to provide a source and destination so this would be a = rather >>>> explicit mapping of that. However, our structure in this YANG model = is >>>> just completely different than an IOS command so I don't see why we >>>> should try and mimic IOS in the YANg model. >>>>=20 >>>> Not specifying a destination IP address means we match on any >>>> destination IP address. The same is true for any other field we can >>>> match on. Not setting a match implies we don't try to match on that >>>> field, thus we allow "any" value. I think the logical continuation = of >>>> this is that for an ACE with no matches defined at all, we match = any >>>> packet. I think we can update the text to better explain this. >>>>=20 >>>>=20 >>>>=20 >>>>> Otherwise if the ACL type is "any-acl" then this only allows two = types >>>>> of ACLs to be defined, neither of which seem to be particularly >>>>> useful: >>>>> (1) An ACL that matches all traffic and permits it, i.e. the same = as=20 >>>>> having no ACL at all. >>>>> (2) An ACL that matches all traffic and drops. >>>>>=20 >>>>> So I think perhaps the answer here is to define neither ACL type=20= >>>>> "any-acl" nor leaf "any". The presumption could be that any ACE = that >>>>> is >>>>> configured to match no fields implicitly matches all packets = (because=20 >>>>> all non specified fields are treated as wildcards), and then = applies >>>>> the >>>>> permit/deny rule associated with the ACE. This logic can apply to = all=20 >>>>> ACL types. >>>>=20 >>>> Yes yes yes :) >>>>=20 >>>> Kristian. >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>>=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This PR tries to address what are hopefully the last = set of comments before we publish the draft for LC.

Unless I hear objections, I will roll = in these changes by the end of the week (Dec. 15).

On Nov 29, 2017, at 12:11 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

The updated = commit here takes care of = restoring =E2=80=9Ctype" to "acl-type", fixes some indentation issues, = adds a choice for =E2=80=9Cl3" where either =E2=80=9Cipv4" or =E2=80=9Cipv= 6" can be selected, and a similar choice at =E2=80=9Cl4" that allows = either =E2=80=9Ctcp", =E2=80=9Cudp" or =E2=80=9Cicmp" to be selected, = and removes changes for =E2=80=9Cglobal" attachment point. Will add the = last item as a separate commit.

Unless I hear objections, I will roll the pr/18 changes into = the master branch in 48 hours.

On Nov 28, 2017, at 2:17 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
An updated version of = the model has been posted as part of the PR here
<https://github.com/netmod-wg/acl-model/commit/2477cd400cce6d399= 33c908ad97da27ff759588b>.

The = particular change removes any-acl from the model, expands on eth
(to ethernet), removes acl- prefix for things like acl-type = and
acl-name. Please review.

I think 99% of the changes in this PR look good.  The = one
exception is the typedef that used to be called = "acl-type".  I think
it should still be called = "acl-type".  "type" is too broad.  NOTE,
this is = just the typedef; the leaf /access-lists/acl/type should keep
its name ("type").


/martin




On Nov 27, 2017, at 5:17 AM, Kristian Larsson = <kll@dev.terastrm.net>
wrote:


Robert Wilton <rwilton@cisco.com> = writes:

Thinking about this some more. I'm not sure what it means for = the "ACL
Type" to be "any-acl". It seems that the "match = any packet" should be
a
type of ACE, e.g. = perhaps as the last entry of an ACL, rather than a
type = of ACL.

Yes, I agree as so far = that any-acl makes no sense as an acl-type. The
way I = understood acl-type, and the way that vendors have told me it
will
be used, is to say "this is an IPv4 ACL" = and then on an attachment
point
you can = specify that only ACLs of acl-type ipv4-acl can be attached to
the interface. That makes perfect sense. I do not see how = any-acl can
map into this.

I = agree that any-acl is logically a type of ACE but we don't have an
ace-type and the exact same information can IMHO already be = conveyed
WITHOUT the any-acl type and thus it has no = reason to exist. Nor do we
need a feature for it.

=46rom what I can tell the any-acl container = in the ACE should be used
to
explicitly = signify a match on "any". Think of IOS style ipv4 acl:
= permit ip any any

We have to provide a = source and destination so this would be a rather
explicit = mapping of that. However, our structure in this YANG model is
just completely different than an IOS command so I don't see = why we
should try and mimic IOS in the YANg model.

Not specifying a destination IP address means = we match on any
destination IP address. The same is true = for any other field we can
match on. Not setting a match = implies we don't try to match on that
field, thus we allow = "any" value. I think the logical continuation of
this is = that for an ACE with no matches defined at all, we match any
packet. I think we can update the text to better explain = this.



Otherwise if the ACL = type is "any-acl" then this only allows two types
of ACLs = to be defined, neither of which seem to be particularly
useful:
(1) An ACL that matches all traffic and = permits it, i.e. the same as
having no ACL at all.
(2) An ACL that matches all traffic and drops.

So I think perhaps the answer here is to = define neither ACL type
"any-acl" nor leaf "any". The = presumption could be that any ACE that
is
configured to match no fields implicitly matches all packets = (because
all non specified fields are treated as = wildcards), and then applies
the
permit/deny = rule associated with the ACE. This logic can apply to all
ACL types.

Yes yes = yes :)

 Kristian.

Mahesh Jethanandani
mjethanandani@gmail.com


Mahesh Jethanandani
mjethanandani@gmail.com


Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4-- From nobody Sun Dec 10 08:16:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA65B12702E for ; Sun, 10 Dec 2017 08:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 9ST1KNhNd9UM for ; Sun, 10 Dec 2017 08:15:57 -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 9342E124D6C for ; Sun, 10 Dec 2017 08:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2865; q=dns/txt; s=iport; t=1512922556; x=1514132156; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=yiL9yPi0zqv6naMDAze3j9fuDF7+MBSbovTM4fQD1T8=; b=bU5A3PM7x4LgPdode9ziiHbAW1MFavMLZNElJ7A85kMgZY1L5Eo48KG1 OSa1JMu2+Q/rqwNcDXVhrggOMdklTUaPjHGEL1hi88xz2Yw6HlkIzcfYQ oG+/H8ig0DUgumZ/ZaGe/Uqyi9U4Gy/IOJCs1Fxmk5svlMaAdyOn8tGh1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3BQAuXS1a/xbLJq1bHAEBAQQBAQoBA?= =?us-ascii?q?YQkdCeEAosVkAWRQYVfggEKJ4UUAoUhFQEBAQEBAQEBAWsohSIBBiNLGw8NAwE?= =?us-ascii?q?CKwICTQIIBg0GAgEBiiQQpmKCJyaKPQEBAQEBAQEBAQEBAQEBAQEBARsFg2iDY?= =?us-ascii?q?YISgwKEZ1iCdYJjBYxylh+VIYwRh1KOX4d/gTs1I4FPMhoIGxU6DROCCYIZgj1?= =?us-ascii?q?AN4llAQEB?= X-IronPort-AV: E=Sophos;i="5.45,389,1508803200"; d="scan'208,217";a="809218" 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; 10 Dec 2017 16:15:54 +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 vBAGFs7n012201 for ; Sun, 10 Dec 2017 16:15:54 GMT References: <745f2195-4b05-8049-5df6-baeae7aa6393@cisco.com> To: NETMOD Working Group From: Benoit Claise X-Forwarded-Message-Id: <745f2195-4b05-8049-5df6-baeae7aa6393@cisco.com> Message-ID: <9197f1d0-d3fc-69a2-7f3c-dc35f6d10eb8@cisco.com> Date: Sun, 10 Dec 2017 17:15:53 +0100 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: <745f2195-4b05-8049-5df6-baeae7aa6393@cisco.com> Content-Type: multipart/alternative; boundary="------------E752622EF505C0BB2ED57484" Content-Language: en-US Archived-At: Subject: [netmod] Fwd: Blog: YANG Data Models in the Industry: Current State of Affairs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2017 16:15:59 -0000 This is a multi-part message in MIME format. --------------E752622EF505C0BB2ED57484 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Forwarding. I know that some of you are not on the ietf@ietf.org mailing list. Regards, Benoit. -------- Forwarded Message -------- Subject: Blog: YANG Data Models in the Industry: Current State of Affairs Date: Sun, 10 Dec 2017 17:15:21 +0100 From: Benoit Claise To: IETF-Discussion list Dear all, https://www.ietf.org/blog/2017/12/yang-data-models-in-the-industry-current-state-of-affairs-november-2017/ Enjoy. Regards, Benoit --------------E752622EF505C0BB2ED57484 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Forwarding.
I know that some of you are not on the ietf@ietf.org mailing list.

Regards, Benoit.

-------- Forwarded Message --------
Subject: Blog: YANG Data Models in the Industry: Current State of Affairs
Date: Sun, 10 Dec 2017 17:15:21 +0100
From: Benoit Claise <bclaise@cisco.com>
To: IETF-Discussion list <ietf@ietf.org>


Dear all,

https://www.ietf.org/blog/2017/12/yang-data-models-in-the-industry-current-state-of-affairs-november-2017/
Enjoy.

Regards, Benoit
--------------E752622EF505C0BB2ED57484-- From nobody Sun Dec 10 13:06:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DEF128CF0 for ; Sun, 10 Dec 2017 13:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 2QMJJ5p8Da1l for ; Sun, 10 Dec 2017 13:06: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 A765B1286B1 for ; Sun, 10 Dec 2017 13:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3973; q=dns/txt; s=iport; t=1512939980; x=1514149580; h=subject:from:to:references:message-id:date:mime-version: in-reply-to; bh=97xVTWSX2MAltHjaEuU3P1o8194TYFzJt94+xIgau2g=; b=H68XjqJrwHnTAcMuQ8u4Eu4iAkX7BM3UsQm3u/Ld0YkLhY6jfSrf0x47 d16wUVXbN3d496NZNj/sT1z9yGDFVZIPcoO922tBjOcYC1x84vR5vvhzR 033lAQXCnbS/OaRHe7sIAOF+TZofyt3CkHrKyUr3AUvsrcxgWsjvsPuPM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAwA7oS1a/xbLJq1bGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYQkdCeEAosVj1YJJpFBhV+CAQonhRQChSIUAQEBAQEBAQEBayiFIgEBAQE?= =?us-ascii?q?DI0sbCwQNAwECKwICTwgGDQYCAQGKJBCmfoInJoo9AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGwWDaINhghILgneEZ1iCdYJjBYxylh+VIYwRh1KOX4d/gTs2IoFPMhoIGxU?= =?us-ascii?q?6DROCCYIZgj1AN4llAQEB?= X-IronPort-AV: E=Sophos;i="5.45,390,1508803200"; d="scan'208,217";a="758735" 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; 10 Dec 2017 21:06:19 +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 vBAL6IuN020165 for ; Sun, 10 Dec 2017 21:06:18 GMT From: Benoit Claise To: NETMOD Working Group References: <745f2195-4b05-8049-5df6-baeae7aa6393@cisco.com> <9197f1d0-d3fc-69a2-7f3c-dc35f6d10eb8@cisco.com> Message-ID: <7543e01b-9845-6f02-ecaa-fa7641f22392@cisco.com> Date: Sun, 10 Dec 2017 22:06:18 +0100 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: <9197f1d0-d3fc-69a2-7f3c-dc35f6d10eb8@cisco.com> Content-Type: multipart/alternative; boundary="------------6BDDE716338AD34D8E5B1FEE" Content-Language: en-US Archived-At: Subject: Re: [netmod] Fwd: Blog: YANG Data Models in the Industry: Current State of Affairs X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2017 21:06:23 -0000 This is a multi-part message in MIME format. --------------6BDDE716338AD34D8E5B1FEE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Watch out. Following the link leads to an older blog. The new blog is at https://www.ietf.org/blog/2017/12/yang-data-models-in-the-industry-current-state-of-affairs-november-2017/ Regards, Benoit > Forwarding. > I know that some of you are not on the ietf@ietf.org mailing list. > > Regards, Benoit. > > -------- Forwarded Message -------- > Subject: Blog: YANG Data Models in the Industry: Current State of > Affairs > Date: Sun, 10 Dec 2017 17:15:21 +0100 > From: Benoit Claise > To: IETF-Discussion list > > > > Dear all, > > https://www.ietf.org/blog/2017/12/yang-data-models-in-the-industry-current-state-of-affairs-november-2017/ > > Enjoy. > > Regards, Benoit --------------6BDDE716338AD34D8E5B1FEE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Watch out.
Following the link leads to an older blog.
The new blog is at https://www.ietf.org/blog/2017/12/yang-data-models-in-the-industry-current-state-of-affairs-november-2017/

Regards, Benoit
Forwarding.
I know that some of you are not on the ietf@ietf.org mailing list.

Regards, Benoit.

-------- Forwarded Message --------
Subject: Blog: YANG Data Models in the Industry: Current State of Affairs
Date: Sun, 10 Dec 2017 17:15:21 +0100
From: Benoit Claise <bclaise@cisco.com>
To: IETF-Discussion list <ietf@ietf.org>


Dear all,

https://www.ietf.org/blog/2017/12/yang-data-models-in-the-industry-current-state-of-affairs-november-2017/
Enjoy.

Regards, Benoit

--------------6BDDE716338AD34D8E5B1FEE-- From nobody Sun Dec 10 22:31:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475E21241FC; Sun, 10 Dec 2017 22:31:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k7V1JDFLD2F; Sun, 10 Dec 2017 22:31: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 CA7B012717E; Sun, 10 Dec 2017 22:31: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 CA84AF88; Mon, 11 Dec 2017 07:31: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 oegvP17KfV6h; Mon, 11 Dec 2017 07:31:03 +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, 11 Dec 2017 07:31:06 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4FEC2012C; Mon, 11 Dec 2017 07:31:06 +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 xXOlITnXPGaC; Mon, 11 Dec 2017 07:31:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0252F20129; Mon, 11 Dec 2017 07:31:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8399A419379A; Mon, 11 Dec 2017 07:29:36 +0100 (CET) Date: Mon, 11 Dec 2017 07:29:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" Message-ID: <20171211062936.sfgj3pq6zivbcltu@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 06:31:11 -0000 On Fri, Dec 08, 2017 at 10:01:20AM -0800, Andy Bierman wrote: > > NMDA needs to be possible to implement with a single schema tree > such that a module is implemented in all datastores, or a subset of > all datastores. Otherwise it probably won't get supported in > clients. We believe it is. At the end, a+b = a+b+c-c. You can either use set addition to create the schema of a datastore or you create a superset and remove things from it. The result is the same. The key is that configuration datastores may implement a+b and operational a+b+c (and during transition even something different). /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 Dec 11 00:48:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36AB1286C7; Mon, 11 Dec 2017 00:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 mISA-Pg_Mt5g; Mon, 11 Dec 2017 00:47:57 -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 87E811241F3; Mon, 11 Dec 2017 00:47:57 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 777661C79C19E; Mon, 11 Dec 2017 08:47:53 +0000 (GMT) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 11 Dec 2017 08:47:54 +0000 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.47]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0361.001; Mon, 11 Dec 2017 16:47:43 +0800 From: Jiangyuanlong To: t.petch CC: "tictoc@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] FWD: I-D Action: draft-ietf-tictoc-1588v2-yang-07.txt Thread-Index: AQHTcFJN+smZUW6ESEmLBbIZ79b6UaM91OZw Date: Mon, 11 Dec 2017 08:47:43 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB669480@dggeml507-mbx.china.huawei.com> References: <151185035711.13451.15517049816245497403@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB65C509@dggeml507-mbx.china.huawei.com> <005a01d37051$be87a960$4001a8c0@gateway.2wire.net> In-Reply-To: <005a01d37051$be87a960$4001a8c0@gateway.2wire.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.202.215] Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] FWD: I-D Action: draft-ietf-tictoc-1588v2-yang-07.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, 11 Dec 2017 08:47:59 -0000 Dear Tom, Good suggestions+ACE- As this Appendix is informational, we would like to i= ncorporate them together with more inputs from YANG Doctors' review and IET= F review.=20 Thanks a lot+ACE- Yuanlong -----Original Message----- From: t.petch +AFs-mailto:ietfc+AEA-btconnect.com+AF0-=20 Sent: Saturday, December 09, 2017 2:24 AM To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org+ADs- netmod+AEA-ietf.org Subject: Re: +AFs-netmod+AF0- FWD: I-D Action: draft-ietf-tictoc-1588v2-yan= g-07.txt Yuanlong I belatedly read appendix A and I am impressed. A few minor thoughts. 1. I was confused by the Title Transferring YANG Work to IEEE 1588 WG (Informational) thinking you meant that the IEEE 1588 WG work would be Informational, like = an Informational RFC. What I am more used to is to start the Appendix with= the statement 'This Appendix is Informational' which I would have found clearer+ACE- 2. The start of A.1 is hard to write. It is the IESG that approves publica= tion, rather than an IETF WG, and I would assume that it has happened, in w= ording this, so perhaps start with +ACI- For the purposes of this appendix, assume that the IESG has approved the publication of an RFC containing a YANG module for= a published IEEE 1588 standard. +ACI- and you could ask the RFC Editor to insert the number of the RFC as and whe= n it is published+ADs- bit presumptuous perhaps, but think positive+ACE- 3. OLD YANG for subsequent 1588 revisions NEW a YANG module for subsequent 1588 revisions 4. A.2 I was around at the time of the MIB Module transfer and the problem was tha= t the then current standard, RFC3978, did not acquire sufficient rights+ADs= - hence the need to track down Contributors. I had thought that RFC5377/RFC5378 had fixed this but what you are proposing sounds like a goo= d plan. 6 A.3 I don't think that the chosen prefix matters. The namespace does since tha= t is what gives names their uniqueness but different YANG modules can use d= ifferent prefixes to refer to and import from the same namespace+ADs- and t= here are bound to be different modules using the same prefix within the mod= ule, if not now then in time+ADs- prefixes are not registered in any way. = (When someone says 'PTP' to me, I think RFC2637, not RFC8173:-) So an IEEE YANG Module could use the same prefix as the IETF one, could use= a different one+ADs- this is something of a live issue now, with NMDA modu= les replacing the initial ones+ADs- same or different namespace, same or di= fferent prefix? hard to know what is best, or what will be at the time of = the transfer. Tom Petch ----- Original Message ----- From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4- To: +ADw-tictoc+AEA-ietf.org+AD4AOw- +ADw-netmod+AEA-ietf.org+AD4- Sent: Tuesday, November 28, 2017 6:37 AM Subject: +AFs-netmod+AF0- FWD: I-D Action: draft-ietf-tictoc-1588v2-yang-07= .txt +AD4- Hi all, +AD4- +AD4- Based on all the comments we received after the WG Last Call, another revision of this draft is uploaded. +AD4- Thanks a lot for all those discussions. +AD4- +AD4- Regards, +AD4- Yuanlong +AD4- +AD4- -----Original Message----- +AD4- From: TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- On Behalf O= f internet-drafts+AEA-ietf.org +AD4- Sent: Tuesday, November 28, 2017 2:26 PM +AD4- To: i-d-announce+AEA-ietf.org +AD4- Cc: tictoc+AEA-ietf.org +AD4- Subject: +AFs-TICTOC+AF0- I-D Action: draft-ietf-tictoc-1588v2-yang-0= 7.txt +AD4- +AD4- +AD4- A New Internet-Draft is available from the on-line Internet-Drafts directories. +AD4- This draft is a work item of the Timing over IP Connection and Transfer of Clock WG of the IETF. +AD4- +AD4- Title : YANG Data Model for IEEE 1588-2008 +AD4- Authors : Yuanlong Jiang +AD4- Xian Liu +AD4- Jinchun Xu +AD4- Rodney Cummings +AD4- Filename : draft-ietf-tictoc-1588v2-yang-07.txt +AD4- Pages : 29 +AD4- Date : 2017-11-27 +AD4- +AD4- Abstract: +AD4- This document defines a YANG data model for the configuration of +AD4- IEEE 1588-2008 devices and clocks, and also retrieval of the +AD4- configuration information, data set and running states of IEEE +AD4- 1588-2008 clocks. +AD4- +AD4- +AD4- The IETF datatracker status page for this draft is: +AD4- https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/ +AD4- +AD4- There are also htmlized versions available at: +AD4- https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07 +AD4- https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-0= 7 +AD4- +AD4- A diff from the previous version is available at: +AD4- https://www.ietf.org/rfcdiff?url2+AD0-draft-ietf-tictoc-1588v2-yang-0= 7 +AD4- +AD4- +AD4- 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. +AD4- +AD4- Internet-Drafts are also available by anonymous FTP at: +AD4- ftp://ftp.ietf.org/internet-drafts/ +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A= XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- TICTOC mailing list +AD4- TICTOC+AEA-ietf.org +AD4- https://www.ietf.org/mailman/listinfo/tictoc +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A= XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- netmod mailing list +AD4- netmod+AEA-ietf.org +AD4- https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Dec 11 02:57:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C75124205; Mon, 11 Dec 2017 02:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 sFSm57EglJW3; Mon, 11 Dec 2017 02:57:54 -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 A2CCF120724; Mon, 11 Dec 2017 02:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14746; q=dns/txt; s=iport; t=1512989874; x=1514199474; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=DjOKLPzFUGl6LWwRYXSzl7tH51MgrgSjOPf+qHCqX40=; b=ElvBYidiZ7pA1SOmJZYa8y2sb0zf24ri/JFveyv6lidbwW3ehnTT8olX b09pWkzK14iQOHMydQigrrxCizAzRpjOKnbq5uWsLDwkK8dRc5YziOHBi IUlbS/8HnRxJy59MjfTnwED9GbtW9SwUx7dslWPIpj7PAAu/LZXU1oQfB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQBXYy5a/xbLJq1SCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDD4EVdCeEAoohdI9WL5FBhUuCFQoYAQmESk8ChSsYAQEBAQE?= =?us-ascii?q?BAQEBayiFIgEBAQECAQEBIUsLBQsLGCcDAgInHxEGAQwGAgEBF4oFCBCnQoInJ?= =?us-ascii?q?oo8AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYNog2GBaSmDAoNJgSwUgyuCYwWZS4l?= =?us-ascii?q?Gh3mNKIIWY4kYJIcujQqBVYd/gTsfOSaBKTIaCBsVOoIpCYIQgjxBNwEBiWUBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.45,391,1508803200"; d="scan'208,217";a="777616" 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; 11 Dec 2017 10:57:51 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBBAvoxA015329; Mon, 11 Dec 2017 10:57:51 GMT To: Andy Bierman , Kent Watsen Cc: "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> From: Robert Wilton Message-ID: <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> Date: Mon, 11 Dec 2017 10:57:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------72EB40BA8927C7E67E2F34CA" Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 10:57:57 -0000 This is a multi-part message in MIME format. --------------72EB40BA8927C7E67E2F34CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 08/12/2017 18:01, Andy Bierman wrote: > Hi, > > A library per datastore sounds too complicated. > I prefer the proposal that was made at the IETF meeting that had > a 'not-implemented-in' leaf-list and a single module list. The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores. I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.  E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS. > > Why is it interesting to have a separate module list for regular > modules and imported modules? Several reasons: 1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler. 2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.  (E.g. it prevents a server stating that two revisions of a module are both implemented). 3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules. For a server, I would design it to "implement" one revision of every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the server implements to satisfy "import-by-revision" and these are stated in the implemented schema anyway. > I prefer to keep the conformance leaf and not change the module list. > > NMDA needs to be possible to implement with a single schema tree such > that a module > is implemented in all datastores, or a subset of all datastores.  > Otherwise it probably won't > get supported in clients. All solutions accommodate this requirement. For me, some of the interesting design questions have revolved around: - is it better to reduce duplication in the list of modules reported at the cost of increased model complexity? - does the solution extend to schema mount? - how well does the solution cope with with configuration datastores that support very different sets of modules? To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out. E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point. Thanks, Rob > > > Andy > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > wrote: > > CC-ing NETCONF, where the draft is being worked on. > > Kent > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: > > > > > > Yes. The default value for yang-library-datastore leaf is > ds:operational > > > (the only possible one for the ds:operational datastore). This > is backward > > > compatible. If one needs different model for 'running', etc. > then a new > > > datastore identity has to be defined  and set in place of the > default value. > > > Then this identity can be used to read the yang-library data with > > > . > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > datastore (lets call it ) that reports the > schema for > > ? Is there another datastore? > Will > > the recursion end? Perhaps it does since > > might have itself listed as the schema defining datastore. I guess > > Lada will like these kind of meta and meta-meta datastores. > > Not really. Metadata needn't be in datastores. > > Lada > > > > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------72EB40BA8927C7E67E2F34CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,


On 08/12/2017 18:01, Andy Bierman wrote:
Hi,

A library per datastore sounds too complicated.
I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a single module list.
The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.  E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS.


Why is it interesting to have a separate module list for regular modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler.
2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.  (E.g. it prevents a server stating that two revisions of a module are both implemented).
3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules.

For a server, I would design it to "implement" one revision of every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the server implements to satisfy "import-by-revision" and these are stated in the implemented schema anyway.


I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such that a module
is implemented in all datastores, or a subset of all datastores.  Otherwise it probably won't
get supported in clients.
All solutions accommodate this requirement.

For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores that support very different sets of modules?

To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out.  E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point.

Thanks,
Rob




Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net> wrote:
CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:operational
> > (the only possible one for the ds:operational datastore). This is backward
> > compatible. If one needs different model for 'running', etc. then a new
> > datastore identity has to be defined  and set in place of the default value.
> > Then this identity can be used to read the yang-library data with
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the schema for
> <running>? Is there another <running-library-library> datastore? Will
> the recursion end? Perhaps it does since <running-library-library>
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=


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



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

--------------72EB40BA8927C7E67E2F34CA-- From nobody Mon Dec 11 03:16:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBDC124BE8; Mon, 11 Dec 2017 03:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 v6YGbLF6cYZi; Mon, 11 Dec 2017 03:16:27 -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 61C70120721; Mon, 11 Dec 2017 03:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6991; q=dns/txt; s=iport; t=1512990986; x=1514200586; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5kjSd3jH59ZldufV7PYlKd9u4VaEx0ebwfr9PHOf9mI=; b=G5ib0b0CQOvHyxYpr2jAtXNlAHrdQKOXRd1F5yf4QhbrP1GxgN5WiRUR 3IgAF04DeAD6VEUDBLJvcQXwERkcArrL9d8+u2rE0EikCT90f+CwOwqao zhok9nkWeyIGtT/u2I3Lsv4E5D6hKpUJY1wnfZN31XO735l8bCAQ8cQ+v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DSAAAKaC5a/xbLJq1SCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEJHQnhAKKIXSPVi+XDIIVChgLhElPAoUuGAEBAQEBAQEBAWs?= =?us-ascii?q?ohSIBAQEBAgEBASEPAQU2CxALGAICIwMCAicfEQYBDAYCAQEXigUIEKdDgieKY?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4JZg2GBaSmDAoR1FBaDFYJjBaMRh3m?= =?us-ascii?q?NKIIWY4kYJIcujl+Hf4E7HzmBTzIaCBsVOoIpCYJJHIFnQTeJZwEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,391,1508803200"; d="scan'208";a="824856" 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; 11 Dec 2017 11:16:24 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBBBGNMl020129; Mon, 11 Dec 2017 11:16:24 GMT To: Vladimir Vassilev , Andy Bierman , Kent Watsen Cc: "netconf@ietf.org" , "netmod@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> From: Robert Wilton Message-ID: <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> Date: Mon, 11 Dec 2017 11:16:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 11:16:29 -0000 Hi Vladimir, On 09/12/2017 11:49, Vladimir Vassilev wrote: > On 12/08/2017 07:01 PM, Andy Bierman wrote: > >> Hi, >> >> A library per datastore sounds too complicated. > I am not proposing that. I'm slightly lost, because I thought that was exactly what you were proposing! ;-) > > > The fundamental point proposed is that the datastore relevant bits are > kept in the ietf-datastores module instead of merging everything in a > new ietf-yang-library entangled monster module. If needed > ietf-datastores can augment ietf-yang-library but ietf-yang-library > should be usable on its own without ietf-datastores. The solution is > coherent and modular and addresses the problem statement. The issue with this is that datastore augmentations to YANG library would end up changing the meaning of the existing YANG library nodes.  E.g. an old client that ignores the datastore augmentations is going to get a nasty surprise when the server does not behave how it expects.  E.g. because the configuration node that it thinks should be there isn't there because it only supported in . This was one of the reasons for changing YANG library. In terms of the idea of just re-using YANG library but export a separate copy for each datastore I think that this has its own problems: - I don't like the idea of returning meta-data along with configuration for a on any of the configuration datastores. - How does a client know whether the YANG library for applies to the whole server (as it does today) vs just applies to the datastore (as it would for an NMDA server)? - It requires more handshaking between the client and server to get the schema, since a separate request would be required for each datastore that is supported. So, for me, I think that the only way that this solution works, would be to define a new RPC, but even then I think that it would make sense to combine the data together into a new YANG library structure. At the end of the day, I don't think that a new YANG library is going to be were the real cost for supporting NMDA comes from.  I think that the real work is supporting independently from both in the client and servers. But I also think that once servers start implementing this properly that it will simplify automation, because rather than a client having to guess what state a server is in, it can actually querey, or be notified of it, without having to write a lot of model specific code. Thanks, Rob >> I prefer the proposal that was made at the IETF meeting that had >> a 'not-implemented-in' leaf-list and a single module list. > This constraint is already specified in the text of the revised > datastores draft. Clients conforming to the draft can expect servers > to comply with the MUST requirement even if there is a separate > yang-library data tree for each datastore the constraint of > configuration stores mapping to 'operational' should be enforced > according to the draft. There is no contradiction here. > > That said I would be also be OK with ietf-datastores augmenting > ietf-yang-library with such a leaf-list ('not-implemented-in' > leaf-list) as a more constrained flavor of the same approach instead > of going for independent copies of yang-library data. For any of that > to happen change in ietf-datastores.yang is needed and change in the > original rfc7895 ietf-yang-library is not needed at all. > > Vladimir > >> >> Why is it interesting to have a separate module list for regular >> modules and imported modules? >> I prefer to keep the conformance leaf and not change the module list. >> >> NMDA needs to be possible to implement with a single schema tree such >> that a module >> is implemented in all datastores, or a subset of all datastores.  >> Otherwise it probably won't >> get supported in clients. >> >> >> Andy >> >> >> >> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > wrote: >> >>     CC-ing NETCONF, where the draft is being worked on. >> >>     Kent >> >> >>     On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: >>     > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: >>     > > >>     > > Yes. The default value for yang-library-datastore leaf is >>     ds:operational >>     > > (the only possible one for the ds:operational datastore). This >>     is backward >>     > > compatible. If one needs different model for 'running', etc. >>     then a new >>     > > datastore identity has to be defined  and set in place of the >>     default value. >>     > > Then this identity can be used to read the yang-library data >> with >>     > > . >>     > > >>     > >>     > Sorry, but I have to ask this: How do I obtain the schema for the >>     > datastore (lets call it ) that reports the >>     schema for >>     > ? Is there another datastore? >>     Will >>     > the recursion end? Perhaps it does since >>     > might have itself listed as the schema defining datastore. I guess >>     > Lada will like these kind of meta and meta-meta datastores. >> >>     Not really. Metadata needn't be in datastores. >> >>     Lada >> >>     > >>     > /js >>     > >>     -- >>     Ladislav Lhotka >>     Head, CZ.NIC Labs >>     PGP Key ID: 0xB8F92B08A9F76C67 >> >>     _______________________________________________ >>     netmod mailing list >>     netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= >> >> >> >>     _______________________________________________ >>     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 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Dec 11 07:53:38 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9169E126DFF; Mon, 11 Dec 2017 07:53:37 -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 YoI6pvKcwKxi; Mon, 11 Dec 2017 07:53: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 C6D52126B71; Mon, 11 Dec 2017 07:53:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4F2231521335; Mon, 11 Dec 2017 16:53:31 +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 AVJ-_334inVi; Mon, 11 Dec 2017 16:53:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 220BA1521331; Mon, 11 Dec 2017 16:53:31 +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 0YNE3TS80wio; Mon, 11 Dec 2017 16:53:31 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id EC762921E25; Mon, 11 Dec 2017 16:53:30 +0100 (CET) To: Robert Wilton , "netmod@ietf.org" , Netconf References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> From: Vladimir Vassilev Message-ID: <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> Date: Mon, 11 Dec 2017 16:53:30 +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: <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 15:53:37 -0000 On 12/11/2017 12:16 PM, Robert Wilton wrote: > Hi Vladimir, > > > On 09/12/2017 11:49, Vladimir Vassilev wrote: >> On 12/08/2017 07:01 PM, Andy Bierman wrote: >> >>> Hi, >>> >>> A library per datastore sounds too complicated. >> I am not proposing that. > I'm slightly lost, because I thought that was exactly what you were=20 > proposing! ;-) I propose a solution that keeps ietf-yang-library a data model of a=20 single YANG context specification doing the datastore specific modeling=20 in ietf-datastores model instead. The solution can be both flexible=20 (independent yang-library data instances per datastore as my example was=20 focused on) or constrained ('not-implemented-in' modules leaf-list).=20 Here is everything that is needed: module: ietf-datastores =C2=A0=C2=A0=C2=A0 +--ro datastores-state =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (model)? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(same-as-oper= ational) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(constrained-= to-operational) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro not= -implemented-in*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->=20 /yanglib:module-state/module/name =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstraine= 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= +--ro yang-library-datastore?=C2=A0=C2=A0 identityref YANG: ... container datastores-state { =C2=A0=C2=A0=C2=A0 config false; =C2=A0=C2=A0=C2=A0 list datastore { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name; =C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0 choice model { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case same-as-operational { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case constrained-to-operation= al { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf-list not-imp= lemented-in { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type = leafref { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 path "/yanglib:module-state/yanglib:module/yanglib:name"; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case unconstrained { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf yang-library= -datastore { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type = identityref { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 base ds:datastore; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0 } =C2=A0 } ... IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I=20 do not see why this has to be compromised. >> >> The fundamental point proposed is that the datastore relevant bits=20 >> are kept in the ietf-datastores module instead of merging everything=20 >> in a new ietf-yang-library entangled monster module. If needed=20 >> ietf-datastores can augment ietf-yang-library but ietf-yang-library=20 >> should be usable on its own without ietf-datastores. The solution is=20 >> coherent and modular and addresses the problem statement. > > The issue with this is that datastore augmentations to YANG library=20 > would end up changing the meaning of the existing YANG library nodes.=C2= =A0=20 > E.g. an old client that ignores the datastore augmentations is going=20 > to get a nasty surprise when the server does not behave how it=20 > expects.=C2=A0 E.g. because the configuration node that it thinks shoul= d be=20 > there isn't there because it only supported in . > > This was one of the reasons for changing YANG library. A well written client that finds out unsupported newer versions of=20 ietf-yang-library (which is reported in the capabilities) or any of the=20 NMDA modules is deployed should not do any damage. How exactly did you=20 solve the problem for the bad clients by changing the structure of=20 yang-library in a incompatible way is something I do not understand. > > In terms of the idea of just re-using YANG library but export a=20 > separate copy for each datastore I think that this has its own problems= : > - I don't like the idea of returning meta-data along with=20 > configuration for a on any of the configuration datastores. There is no meta data. The datastores contain only the config false;=20 /modules-state tree. I think I explained that very clearly. > - How does a client know whether the YANG library for =20 > applies to the whole server (as it does today) vs just applies to the=20 > datastore (as it would for an NMDA server)? All datastore models are "case same-as-operational" for such systems. > - It requires more handshaking between the client and server to get=20 > the schema, since a separate request would be required for each=20 > datastore that is supported. Correct. Flexibility and modularity come at a price. IMO modularity is=20 more important in this case. And there are solutions for the problem=20 e.g. send all requests before waiting for replies. NETCONF=20 supports this. > > So, for me, I think that the only way that this solution works, would=20 > be to define a new RPC, but even then I think=20 > that it would make sense to combine the data together into a new YANG=20 > library structure. As I said my focus is on keeping ietf-yang-library modular (single YANG=20 model context). or just adding datastore=20 identities allowing the client to use to achieve the=20 retrieval of the data is of little importance to me. > > At the end of the day, I don't think that a new YANG library is going=20 > to be were the real cost for supporting NMDA comes from.=C2=A0 I think = that=20 > the real work is supporting independently from =20 > both in the client and servers. But I also think that once servers=20 > start implementing this properly that it will simplify automation,=20 > because rather than a client having to guess what state a server is=20 > in, it can actually querey, or be notified of it, without having to=20 > write a lot of model specific code. +1 Vladimir > > Thanks, > Rob > > >>> I prefer the proposal that was made at the IETF meeting that had >>> a 'not-implemented-in' leaf-list and a single module list. >> This constraint is already specified in the text of the revised=20 >> datastores draft. Clients conforming to the draft can expect servers=20 >> to comply with the MUST requirement even if there is a separate=20 >> yang-library data tree for each datastore the constraint of=20 >> configuration stores mapping to 'operational' should be enforced=20 >> according to the draft. There is no contradiction here. >> >> That said I would be also be OK with ietf-datastores augmenting=20 >> ietf-yang-library with such a leaf-list ('not-implemented-in'=20 >> leaf-list) as a more constrained flavor of the same approach instead=20 >> of going for independent copies of yang-library data. For any of that=20 >> to happen change in ietf-datastores.yang is needed and change in the=20 >> original rfc7895 ietf-yang-library is not needed at all. >> >> Vladimir >> >>> >>> Why is it interesting to have a separate module list for regular=20 >>> modules and imported modules? >>> I prefer to keep the conformance leaf and not change the module list. >>> >>> NMDA needs to be possible to implement with a single schema tree=20 >>> such that a module >>> is implemented in all datastores, or a subset of all datastores.=C2=A0= =20 >>> Otherwise it probably won't >>> get supported in clients. >>> >>> >>> Andy >>> >>> >>> >>> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen >> > wrote: >>> >>> =C2=A0=C2=A0=C2=A0 CC-ing NETCONF, where the draft is being worked on= . >>> >>> =C2=A0=C2=A0=C2=A0 Kent >>> >>> >>> =C2=A0=C2=A0=C2=A0 On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenw= aelder wrote: >>> =C2=A0=C2=A0=C2=A0 > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladim= ir Vassilev=20 >>> wrote: >>> =C2=A0=C2=A0=C2=A0 > > >>> =C2=A0=C2=A0=C2=A0 > > Yes. The default value for yang-library-datast= ore leaf is >>> =C2=A0=C2=A0=C2=A0 ds:operational >>> =C2=A0=C2=A0=C2=A0 > > (the only possible one for the ds:operational = datastore). This >>> =C2=A0=C2=A0=C2=A0 is backward >>> =C2=A0=C2=A0=C2=A0 > > compatible. If one needs different model for '= running', etc. >>> =C2=A0=C2=A0=C2=A0 then a new >>> =C2=A0=C2=A0=C2=A0 > > datastore identity has to be defined=C2=A0 and= set in place of the >>> =C2=A0=C2=A0=C2=A0 default value. >>> =C2=A0=C2=A0=C2=A0 > > Then this identity can be used to read the yan= g-library data=20 >>> with >>> =C2=A0=C2=A0=C2=A0 > > . >>> =C2=A0=C2=A0=C2=A0 > > >>> =C2=A0=C2=A0=C2=A0 > >>> =C2=A0=C2=A0=C2=A0 > Sorry, but I have to ask this: How do I obtain t= he schema for the >>> =C2=A0=C2=A0=C2=A0 > datastore (lets call it ) that = reports the >>> =C2=A0=C2=A0=C2=A0 schema for >>> =C2=A0=C2=A0=C2=A0 > ? Is there another datastore? >>> =C2=A0=C2=A0=C2=A0 Will >>> =C2=A0=C2=A0=C2=A0 > the recursion end? Perhaps it does since=20 >>> >>> =C2=A0=C2=A0=C2=A0 > might have itself listed as the schema defining = datastore. I=20 >>> guess >>> =C2=A0=C2=A0=C2=A0 > Lada will like these kind of meta and meta-meta = datastores. >>> >>> =C2=A0=C2=A0=C2=A0 Not really. Metadata needn't be in datastores. >>> >>> =C2=A0=C2=A0=C2=A0 Lada >>> >>> =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 Ladislav Lhotka >>> =C2=A0=C2=A0=C2=A0 Head, CZ.NIC Labs >>> =C2=A0=C2=A0=C2=A0 PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>> =C2=A0=C2=A0=C2=A0 netmod mailing list >>> =C2=A0=C2=A0=C2=A0 netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voD= TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwqYm= kAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRr= vQI5l8&e=3D=20 >>> >>> =20 >>> >>> >>> >>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>> =C2=A0=C2=A0=C2=A0 netmod mailing list >>> =C2=A0=C2=A0=C2=A0 netmod@ietf.org >>> =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/netmod >>> =C2=A0=C2=A0=C2=A0 >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Dec 11 08:17:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE3126DEE; Mon, 11 Dec 2017 08:17:33 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMpnbDLxCFIN; Mon, 11 Dec 2017 08:17:30 -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 94441126D73; Mon, 11 Dec 2017 08:17: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 E36E269A; Mon, 11 Dec 2017 17:17:28 +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 ap06WK_SdQYN; Mon, 11 Dec 2017 17:17:25 +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, 11 Dec 2017 17:17:28 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDFF92012E; Mon, 11 Dec 2017 17:17:28 +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 hV-QL91UCLau; Mon, 11 Dec 2017 17:17:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 326C820129; Mon, 11 Dec 2017 17:17:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F33E3419454C; Mon, 11 Dec 2017 17:15:56 +0100 (CET) Date: Mon, 11 Dec 2017 17:15:56 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Cc: Robert Wilton , "netmod@ietf.org" , Netconf Message-ID: <20171211161556.me7thzsos2ywai3r@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Vladimir Vassilev , Robert Wilton , "netmod@ietf.org" , Netconf References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.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: <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 16:17:33 -0000 I do not fully understand why you think it is worth to preserve the old YANG module library structure. Clearly, it won't be backwards compatible since an NMDA implementation may list modules that are not implemented in all datastores and an old client talking to a new server will thus misunderstand what is exposed via the old YANG module library structure. Your proposal "looks" backwards compatible but it is not if one takes a closer look. One can start making changes to say the conformance-type but then this does not solve the problem since an old client does not know what a new conformance type value means. The design team did look into the option of keeping the old structure unchanged some weeks ago and we finally arrived at the conclusion that it gets (i) ugly and (ii) does not really provide backwards compatibility for a client written agains the old YANG module library structure. Note that with the new proposals on the table, it should be possible to provide a backwards compatible view on YANG library for systems that implement the exact same module set (with the exact same set of features and deviations) on all datastores they support. But for systems where this is not true, it seems better to use new definitions instead of tweaking semantics. Perhaps it helps if you can clearly phrase the objective of keeping the old structure. What is the goal you want to achieve with that? /js On Mon, Dec 11, 2017 at 04:53:30PM +0100, Vladimir Vassilev wrote: > On 12/11/2017 12:16 PM, Robert Wilton wrote: > > > Hi Vladimir, > > > > > > On 09/12/2017 11:49, Vladimir Vassilev wrote: > > > On 12/08/2017 07:01 PM, Andy Bierman wrote: > > > > > > > Hi, > > > > > > > > A library per datastore sounds too complicated. > > > I am not proposing that. > > I'm slightly lost, because I thought that was exactly what you were > > proposing! ;-) > I propose a solution that keeps ietf-yang-library a data model of a single > YANG context specification doing the datastore specific modeling in > ietf-datastores model instead. The solution can be both flexible > (independent yang-library data instances per datastore as my example was > focused on) or constrained ('not-implemented-in' modules leaf-list). Here is > everything that is needed: > > module: ietf-datastores > +--ro datastores-state > +--ro datastore* [name] > +--ro (model)? > +--:(same-as-operational) > +--:(constrained-to-operational) > | +--ro not-implemented-in* -> > /yanglib:module-state/module/name > +--:(unconstrained) > +--ro yang-library-datastore? identityref > > YANG: > ... > container datastores-state { > config false; > list datastore { > key name; > } > choice model { > case same-as-operational { > } > case constrained-to-operational { > leaf-list not-implemented-in { > type leafref { > path "/yanglib:module-state/yanglib:module/yanglib:name"; > } > } > } > case unconstrained { > leaf yang-library-datastore { > type identityref { > base ds:datastore; > } > } > } > } > } > ... > > IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I do > not see why this has to be compromised. > > > > > > The fundamental point proposed is that the datastore relevant bits > > > are kept in the ietf-datastores module instead of merging everything > > > in a new ietf-yang-library entangled monster module. If needed > > > ietf-datastores can augment ietf-yang-library but ietf-yang-library > > > should be usable on its own without ietf-datastores. The solution is > > > coherent and modular and addresses the problem statement. > > > > The issue with this is that datastore augmentations to YANG library > > would end up changing the meaning of the existing YANG library nodes. > > E.g. an old client that ignores the datastore augmentations is going to > > get a nasty surprise when the server does not behave how it expects. > > E.g. because the configuration node that it thinks should be there isn't > > there because it only supported in . > > > > This was one of the reasons for changing YANG library. > A well written client that finds out unsupported newer versions of > ietf-yang-library (which is reported in the capabilities) or any of the NMDA > modules is deployed should not do any damage. How exactly did you solve the > problem for the bad clients by changing the structure of yang-library in a > incompatible way is something I do not understand. > > > > In terms of the idea of just re-using YANG library but export a separate > > copy for each datastore I think that this has its own problems: > > - I don't like the idea of returning meta-data along with configuration > > for a on any of the configuration datastores. > There is no meta data. The datastores contain only the config false; > /modules-state tree. I think I explained that very clearly. > > - How does a client know whether the YANG library for applies > > to the whole server (as it does today) vs just applies to the > > datastore (as it would for an NMDA server)? > All datastore models are "case same-as-operational" for such systems. > > - It requires more handshaking between the client and server to get the > > schema, since a separate request would be required for each datastore > > that is supported. > Correct. Flexibility and modularity come at a price. IMO modularity is more > important in this case. And there are solutions for the problem e.g. send > all requests before waiting for replies. NETCONF supports this. > > > > So, for me, I think that the only way that this solution works, would be > > to define a new RPC, but even then I think that it > > would make sense to combine the data together into a new YANG library > > structure. > As I said my focus is on keeping ietf-yang-library modular (single YANG > model context). or just adding datastore identities > allowing the client to use to achieve the retrieval of the data > is of little importance to me. > > > > > At the end of the day, I don't think that a new YANG library is going to > > be were the real cost for supporting NMDA comes from. I think that the > > real work is supporting independently from both > > in the client and servers. But I also think that once servers start > > implementing this properly that it will simplify automation, because > > rather than a client having to guess what state a server is in, it can > > actually querey, or be notified of it, without having to write a lot of > > model specific code. > +1 > > Vladimir > > > > Thanks, > > Rob > > > > > > > > I prefer the proposal that was made at the IETF meeting that had > > > > a 'not-implemented-in' leaf-list and a single module list. > > > This constraint is already specified in the text of the revised > > > datastores draft. Clients conforming to the draft can expect servers > > > to comply with the MUST requirement even if there is a separate > > > yang-library data tree for each datastore the constraint of > > > configuration stores mapping to 'operational' should be enforced > > > according to the draft. There is no contradiction here. > > > > > > That said I would be also be OK with ietf-datastores augmenting > > > ietf-yang-library with such a leaf-list ('not-implemented-in' > > > leaf-list) as a more constrained flavor of the same approach instead > > > of going for independent copies of yang-library data. For any of > > > that to happen change in ietf-datastores.yang is needed and change > > > in the original rfc7895 ietf-yang-library is not needed at all. > > > > > > Vladimir > > > > > > > > > > > Why is it interesting to have a separate module list for regular > > > > modules and imported modules? > > > > I prefer to keep the conformance leaf and not change the module list. > > > > > > > > NMDA needs to be possible to implement with a single schema tree > > > > such that a module > > > > is implemented in all datastores, or a subset of all > > > > datastores. Otherwise it probably won't > > > > get supported in clients. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > > > wrote: > > > > > > > > CC-ing NETCONF, where the draft is being worked on. > > > > > > > > Kent > > > > > > > > > > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > > > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir > > > > Vassilev wrote: > > > > > > > > > > > > Yes. The default value for yang-library-datastore leaf is > > > > ds:operational > > > > > > (the only possible one for the ds:operational datastore). This > > > > is backward > > > > > > compatible. If one needs different model for 'running', etc. > > > > then a new > > > > > > datastore identity has to be defined and set in place of the > > > > default value. > > > > > > Then this identity can be used to read the yang-library > > > > data with > > > > > > . > > > > > > > > > > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > > > > datastore (lets call it ) that reports the > > > > schema for > > > > > ? Is there another datastore? > > > > Will > > > > > the recursion end? Perhaps it does since > > > > > > > > > might have itself listed as the schema defining datastore. > > > > I guess > > > > > Lada will like these kind of meta and meta-meta datastores. > > > > > > > > Not really. Metadata needn't be in datastores. > > > > > > > > Lada > > > > > > > > > > > > > > /js > > > > > > > > > -- > > > > Ladislav Lhotka > > > > Head, CZ.NIC Labs > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > 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 Dec 11 08:35:52 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353BF126DEE for ; Mon, 11 Dec 2017 08:35:51 -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 FAVkPN74Ht05 for ; Mon, 11 Dec 2017 08:35:49 -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 5AAA31200FC for ; Mon, 11 Dec 2017 08:35:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 36E941521348; Mon, 11 Dec 2017 17:35:47 +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 xMArQH2hMLsB; Mon, 11 Dec 2017 17:35:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 0E736152134A; Mon, 11 Dec 2017 17:35:47 +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 kTXYiV9JBAjM; Mon, 11 Dec 2017 17:35:46 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id DAA2D1521345; Mon, 11 Dec 2017 17:35:46 +0100 (CET) To: Kent Watsen , "netmod@ietf.org" References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> From: Vladimir Vassilev Message-ID: <975828fb-cd82-84fb-540b-58b8012872b5@transpacket.com> Date: Mon, 11 Dec 2017 17:35:46 +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: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nb Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 16:35:51 -0000 Hello, I've reviewed this document and believe it is ready for publication. The focus of my review this time was on validating the module and the example modules and example data through running code. I implemented NMDA for the open source tools we use and added a testcase that reproduces the result specified in "Appendix E. Example: NETCONF Reply" after loading the configuration specified in "Appendix D. Example: NETCONF Reply" and providing the config false; data and system originated configuration as needed. I can confirm the implementation validated the example modules and the example data producing identical output. IMO the examples are demonstrating well the concept of NMDA and its application for the ietf-interfaces module. I had an issue with a bug in ietf-netconf-datastores@2017-08-24.yang I had to fix in order to use the RPC. The bug is already reported on the mailing-list. diff ietf-patched/ietf-netconf-datastores@2017-08-24.yang ietf-draft/ietf-netconf-datastores@2017-08-24.yang 140c140 < when 'derived-from-or-self(../datastore, "ds:operational")'; --- > when 'derived-from-or-self(../datastore, "or:operational")'; Vladimir On 11/28/2017 08:29 PM, Kent Watsen wrote: > All, > > This starts a two-week working group last call on > draft-ietf-netmod-rfc7277bis-00. > > Please recall that this update's intention is to > modify the YANG module to be in line with the NMDA > guidelines [1]. Reviewing the diff between the two > drafts [2] should reveal just this. > > The working group last call ends on December 12. > 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. > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt > > Thank you, > Netmod Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Dec 11 08:37:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB553127076; Mon, 11 Dec 2017 08:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 xnDfXUiRcVYD; Mon, 11 Dec 2017 08:37:49 -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 171C4126DEE; Mon, 11 Dec 2017 08:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8553; q=dns/txt; s=iport; t=1513010269; x=1514219869; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=EsV8cq/hoXqt4q6VEFBpss8vZiaijQw+q7bp/fcErjc=; b=fqX1xTJzSSAXPfsGEO2MtyFksMApT/X1B8GYl8smjFHYq6QQoSEDfTcE TL6VdEuOYnS9H09mdX5c9ANKUmY5SA4nhbYcplZuQ7Lh67yP61EXF0jzz zC68onknSnMNspA4GAN2QOB7VC9jTsTkgYvlcxQ9g8YCTsFU/nn4uILG0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQAZsy5a/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUYhCmLFY9XCSaXDIIVCoU7AoUzFgEBAQEBAQEBAWsohSMBBSM?= =?us-ascii?q?ECwEFUQkCGAICJgICVwYBDAgBAReKDYo0nWyBbTqKZAEBAQEBAQEDAQEBAQEBA?= =?us-ascii?q?SGBD4JZfYJkgWkpC4FpgQ6FCYMrgmMFkg+RApUhjBGHUo5fh3+BOyYGLIFPMho?= =?us-ascii?q?IGxU6giqCURyBZ0GKFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,392,1508803200"; d="scan'208";a="785658" 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; 11 Dec 2017 16:37:47 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBBGbkaA028335; Mon, 11 Dec 2017 16:37:46 GMT To: Vladimir Vassilev , "netmod@ietf.org" , Netconf References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> From: Robert Wilton Message-ID: <516c0470-cf99-6761-f73c-9b1806b0de66@cisco.com> Date: Mon, 11 Dec 2017 16:37:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 16:37:51 -0000 On 11/12/2017 15:53, Vladimir Vassilev wrote: > On 12/11/2017 12:16 PM, Robert Wilton wrote: > >> Hi Vladimir, >> >> >> On 09/12/2017 11:49, Vladimir Vassilev wrote: >>> On 12/08/2017 07:01 PM, Andy Bierman wrote: >>> >>>> Hi, >>>> >>>> A library per datastore sounds too complicated. >>> I am not proposing that. >> I'm slightly lost, because I thought that was exactly what you were >> proposing! ;-) > I propose a solution that keeps ietf-yang-library a data model of a > single YANG context specification doing the datastore specific > modeling in ietf-datastores model instead. The solution can be both > flexible (independent yang-library data instances per datastore as my > example was focused on) or constrained ('not-implemented-in' modules > leaf-list). Here is everything that is needed: > > module: ietf-datastores >     +--ro datastores-state >        +--ro datastore* [name] >        +--ro (model)? >           +--:(same-as-operational) >           +--:(constrained-to-operational) >           |  +--ro not-implemented-in*       -> > /yanglib:module-state/module/name >           +--:(unconstrained) >              +--ro yang-library-datastore?   identityref > > YANG: > ... > container datastores-state { >     config false; >     list datastore { >       key name; >     } >     choice model { >         case same-as-operational { >         } >         case constrained-to-operational { >           leaf-list not-implemented-in { >             type leafref { >               path "/yanglib:module-state/yanglib:module/yanglib:name"; >             } >           } >         } >         case unconstrained { >           leaf yang-library-datastore { >             type identityref { >               base ds:datastore; >           } >         } >       } >     } >   } > ... > > IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I > do not see why this has to be compromised. But a major version change to YANG library is happening here. In rfc7895, if a module is implemented then it is implemented in all configuration datastores, and doesn't exist. Alas, that is not what is required for NMDA, it needs different semantics with more granularity.  You cannot achieve this without changing the meaning of the existing YANG library data nodes, which will break clients. >>> >>> The fundamental point proposed is that the datastore relevant bits >>> are kept in the ietf-datastores module instead of merging everything >>> in a new ietf-yang-library entangled monster module. If needed >>> ietf-datastores can augment ietf-yang-library but ietf-yang-library >>> should be usable on its own without ietf-datastores. The solution is >>> coherent and modular and addresses the problem statement. >> >> The issue with this is that datastore augmentations to YANG library >> would end up changing the meaning of the existing YANG library >> nodes.  E.g. an old client that ignores the datastore augmentations >> is going to get a nasty surprise when the server does not behave how >> it expects.  E.g. because the configuration node that it thinks >> should be there isn't there because it only supported in . >> >> This was one of the reasons for changing YANG library. > A well written client that finds out unsupported newer versions of > ietf-yang-library (which is reported in the capabilities) or any of > the NMDA modules is deployed should not do any damage. How exactly did > you solve the problem for the bad clients by changing the structure of > yang-library in a incompatible way is something I do not understand. Servers have a choice: If a server just wants to supports pre NMDA models + RPCs then it would use rfc7895. If a server only wants to support post NMDA models + RPCs + clients, then it can use the new YANG library (and not implement the modules-state container). If a server wants to support old and new clients then there are few choices: (1) Use configuration to control which mode the server is running in. (2) Run separate copies of the mgmt protocols on separate port numbers. (3) Implement the NMDA models, and then publish the schema of , or perhaps , in the modules-state container.  Pre NMDA clients, using would probably not see all system information.  This approach starts to have issues if there are differences between what is configurable and what is in operational. >> >> In terms of the idea of just re-using YANG library but export a >> separate copy for each datastore I think that this has its own problems: >> - I don't like the idea of returning meta-data along with >> configuration for a on any of the configuration datastores. > There is no meta data. The datastores contain only the config false; > /modules-state tree. I think I explained that very clearly. YANG library doesn't represent regular server operational data, but instead it is meta-data about the server instance, which is why it is allowed to differ between NETCONF and RESTCONF (which I don't really like). Yes, you explained returning /modules-state from candidate, running, intended, i2rs, etc.  Unfortunately I really dislike this approach because it feels like a backwards step where we have trying to get a clean split between configuration and state.   Hence defining a RPC would be a better choice. >> - How does a client know whether the YANG library for >> applies to the whole server (as it does today) vs just applies to the >> datastore (as it would for an NMDA server)? > All datastore models are "case same-as-operational" for such systems. This isn't about how the server implements it, but instead my concern is about how the client interacts with it. I appreciate that it avoids a client having to parse a new YANG library, but more concerning for me is that the existing YANG clients will not see the behavior that they expect, and rather than failing, they will work in an unknown degraded fashion. > >> - It requires more handshaking between the client and server to get >> the schema, since a separate request would be required for each >> datastore that is supported. > Correct. Flexibility and modularity come at a price. IMO modularity is > more important in this case. And there are solutions for the problem > e.g. send all requests before waiting for replies. NETCONF > supports this. I perceive that your argument is less about modularity, and instead it seems to be more centered around not making any changes to the structure of the existing YANG library. >> >> So, for me, I think that the only way that this solution works, would >> be to define a new RPC, but even then I think >> that it would make sense to combine the data together into a new YANG >> library structure. > As I said my focus is on keeping ietf-yang-library modular (single > YANG model context). or just adding datastore > identities allowing the client to use to achieve the > retrieval of the data is of little importance to me. This seems to be a complex approach, introducing new protocol semantics, or overloading operations, to avoid revising an existing module structure. I don't think the new proposed YANG library structures are less modular, in fact, I would argue that some of the approaches are designed to make the structure more modular and reusable (e.g. by having named schema). Thanks, Rob > >> >> At the end of the day, I don't think that a new YANG library is going >> to be were the real cost for supporting NMDA comes from. I think that >> the real work is supporting independently from >> both in the client and servers. But I also think that once >> servers start implementing this properly that it will simplify >> automation, because rather than a client having to guess what state a >> server is in, it can actually querey, or be notified of it, without >> having to write a lot of model specific code. > +1 > > Vladimir >> >> Thanks, >> Rob From nobody Mon Dec 11 10:43:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D781287A0 for ; Mon, 11 Dec 2017 10:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 4_c6N4B8rHts for ; Mon, 11 Dec 2017 10:43:54 -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 E2832128799 for ; Mon, 11 Dec 2017 10:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1454; q=dns/txt; s=iport; t=1513017833; x=1514227433; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0Q57+TR/Q99Ph2oG4qga+bYwf1ILKslWiGvsiw0ZNtU=; b=OFs8X6LsjbVSiWgQ8TUBjDdodoafUeFohmpTxfI9jHyH48MSJxXugrs6 T/rHn6Ke8wGCgwuK4IWMcuuVv/N6aG8W0AgI1l9pHxYb2I0FcVvZxbSs8 GhLUE1tgvrj0PaMkKX1uiVXvu05I3mOuPH7bKP/tPGhewyk0IgOA8lFBa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAACH0S5a/4oNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGOfpkJghUKGAuESU8CGoRYPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAgEDAQEhETobAgEIGgImAgICJQsVEAIEARKKKBCoH4InimQBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGgWBD4JZgguGaoUfgxWCYwWjEQKHd40ok2ONCoknAhEZAYE?= =?us-ascii?q?6AR85gU9vFTqCKYRVeIhKgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,392,1508803200"; d="scan'208";a="42661788" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2017 18:43:53 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBBIhq0a007998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Dec 2017 18:43:53 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Dec 2017 13:43: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, 11 Dec 2017 13:43:51 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , NETMOD WG Thread-Topic: [netmod] YANG module security considerations Thread-Index: AQHTap3F7g0FwBEM3EyaV4KKH3WKjKM+iraA Date: Mon, 11 Dec 2017 18:43:51 +0000 Message-ID: References: <1512130382.9397.20.camel@nic.cz> In-Reply-To: <1512130382.9397.20.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: <83775165FD1EB34AAA4118D6DAB1C5DA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] YANG module security considerations X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 18:43:56 -0000 SGkgTGFkYSwgZXQgYWwsIA0KDQpJIGhhdmVu4oCZdCBzZWVuIGFueSByZXNwb25zZSB0byB0aGlz LiBZb3VyIHN1Z2dlc3Rpb24gc2VlbXMgdG8gbWUgdG8gYmUNCm1vcmUgdGVjaG5pY2FsbHkgYWNj dXJhdGUuDQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDEyLzEvMTcsIDc6MTMgQU0sICJuZXRtb2Qg b24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQoNCj5IaSwNCj4NCj50aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgdGVtcGxhdGUgdGV4dCBbMV0gdGhhdCBoYXMgYWxyZWFkeSBiZWVu IHVzZWQNCj5pbiBhDQo+bnVtYmVyIG9mIGRvY3VtZW50cyBpcyBhcHBhcmVudGx5IGluY29ycmVj dCAtIFlBTkcgbW9kdWxlcyBhcmVuJ3QNCj5hY2Nlc3NlZCBieSBOTQ0KPnByb3RvY29scy4gSGVu Y2UNCj4NCj5PTEQNCj4NCj5UaGUgWUFORyBtb2R1bGUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50 IGlzIGRlc2lnbmVkIHRvIGJlIGFjY2Vzc2VkIHZpYQ0KPm5ldHdvcmsNCj5tYW5hZ2VtZW50IHBy b3RvY29scyBzdWNoIGFzIC4uLg0KPg0KPk5FVw0KPg0KPlRoZSBZQU5HIG1vZHVsZSBzcGVjaWZp ZWQgaW4gdGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2NoZW1hIGZvciBkYXRhIHRoYXQNCj5pcw0K PmRlc2lnbmVkIHRvIGJlIGFjY2Vzc2VkIHZpYSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xz IHN1Y2ggYXMgLi4uDQo+DQo+DQo+WzFdIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL29wcy93 aWtpL3lhbmctc2VjdXJpdHktZ3VpZGVsaW5lcw0KPg0KPkxhZGENCj4NCj4tLSANCj5MYWRpc2xh diBMaG90a2ENCj5IZWFkLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3 NkM2Nw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== From nobody Mon Dec 11 11:06:41 2017 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 D549612726E; Mon, 11 Dec 2017 11:06: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.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151301919583.21261.8194293338650695291@ietfa.amsl.com> Date: Mon, 11 Dec 2017 11:06:35 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-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, 11 Dec 2017 19:06:36 -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-03.txt Pages : 74 Date : 2017-12-11 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. This version of these YANG modules uses new names for these YANG models. The main difference from the first version is that this version fully conforms to the Network Management Datastore Architecture (NMDA). Consequently, 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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 Mon Dec 11 12:55:45 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACD61289B0 for ; Mon, 11 Dec 2017 12:55:41 -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=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 WN98LbGB2XKV for ; Mon, 11 Dec 2017 12:55:35 -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 0985D1289B5 for ; Mon, 11 Dec 2017 12:55:32 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id j124so20771204lfg.2 for ; Mon, 11 Dec 2017 12:55:31 -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=7fRZLSI/E1KXckeLggr3bqIGezVQEffWLuNcExJF3rM=; b=C2QIdJMbVmU+I8PbaIE/amVY5GDLQVpYtazxBNPBQZtMFAqDThiCPnboCPbfTQvo2k 0wzpWqPGZ+PWz/Q2D3rbpd/bTs9yC4coBum+HWheOw4xe0GVsXlkbDg/bQjno3fP6O4u EPrnMfdSpKySmOCRtfmxyG5qheVLk0atE+dByDa+eizFjSHwsg4CrEhJLK8scUHRTHMN MskyJXem6AyYqmZGHG50tSBBhGKxtXJ36+b19olRI6CzP2fs5UXxSD6F+Ohfiwb1huL0 /EzrXGjmymAq4kp05At3cd7qf6AJSKgVUSVMQ4d44bWyWF+eP4BBXsugEK/NUUH8GI6z Db+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:cc; bh=7fRZLSI/E1KXckeLggr3bqIGezVQEffWLuNcExJF3rM=; b=aKlHwRkEpTkZUiwG3xp/7hHYVZYtf0nFHyAr0qVEBS+ma6Qhx86W3spYt2AGVcWLH1 8twio9nkUqVwcvNOsN46KPx0Mb3luAW2G2B9RcW+9MKV+h7x4inCWdvSc6AQoTlfU7UQ CE6kFkwRc/CU0ZkpPCewM+/ZCTwm02LT6azJ9Ljm+dt0Wp6PTXMiXDHBKeBd/8brb2gP nYsQc7zSrze/2Aws+IicwIyDlZphP3EieaejqsV8U4cUyYGPl/VsmiSGXbEJkCBumFLx 6vjcNx0tGXTJNlDid8Pm+4+D7rwVvwrZV8rlb5Ho6qdtX5OXELPTsrEIx5H77fTozTVs tauA== X-Gm-Message-State: AKGB3mJBE/FFcCgPsAn2twgc6SO7UvkwkIPWvyn+PLjGSScHn08urEwi saRGdH9XX+mKIB+Y/VwP2rRMLxLfnJxyCI30vRzWbQ== X-Google-Smtp-Source: ACJfBouMaGVsjOFZo5wVjlDCd9Rq9xBpMNqOrj3KB6Gz8bgkl8AYs7dGNOoCSzlvTAdqQDl4TZ4xE/iB+91i2gn0pGU= X-Received: by 10.46.70.18 with SMTP id t18mr826704lja.190.1513025730095; Mon, 11 Dec 2017 12:55:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Mon, 11 Dec 2017 12:55:28 -0800 (PST) In-Reply-To: <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> From: Andy Bierman Date: Mon, 11 Dec 2017 12:55:28 -0800 Message-ID: To: Robert Wilton Cc: Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="f403045f771e2dcb01056016c1e9" Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2017 20:55:41 -0000 --f403045f771e2dcb01056016c1e9 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton wrote: > Hi, > > On 08/12/2017 18:01, Andy Bierman wrote: > > Hi, > > A library per datastore sounds too complicated. > I prefer the proposal that was made at the IETF meeting that had > a 'not-implemented-in' leaf-list and a single module list. > > The use case that this particular design doesn't work particularly well > for is if you have a dynamic datastore that just contains a few modules > that are not supported via the conventional datastores. > > I think that there are future uses cases where the set of modules used for > a dynamic datastore could be really quite different and separate from > conventional configuration. E.g. if dynamic subscribers were managed > through a dynamic configuration datastore rather than RADIUS. > > > Why is it interesting to have a separate module list for regular modules > and imported modules? > > Several reasons: > 1) It means that the list of implemented modules have a single key and > hence any references to an implemented module are cleaner/simpler. > IMO you are replacing universally meaningful keys (module-name, revision-date) with an arbitrary name, It is not cleaner and not simpler for a client. 2) The model structure naturally more strictly enforces that only a single > revision/version of a module is implemented. (E.g. it prevents a server > stating that two revisions of a module are both implemented). > How is that the case if the schema list includes its own module list? You mean there is a "unique" statement in the outer list that insures that a module/revision shows up at most once in all instances of the inner module list? > 3) I genuinely think that the list of implemented modules is more > interesting to the client than the imported, but not implemented modules. > The conformance leaf was good enough. Duplicating the module list and removing the conformance leaf is aggressively non-backward compatible. > > For a server, I would design it to "implement" one revision of every > module that it uses (including those that don't contain any data nodes, > RPCs, actions, notifications, or deviations), and then the "import-only" > list becomes the list of modules that the server implements to satisfy > "import-by-revision" and these are stated in the implemented schema anyway. > > > I prefer to keep the conformance leaf and not change the module list. > > NMDA needs to be possible to implement with a single schema tree such that > a module > is implemented in all datastores, or a subset of all datastores. > Otherwise it probably won't > get supported in clients. > > All solutions accommodate this requirement. > Seems to me all new solutions allow a server to violate the MUST in the NMDA draft that there is a superset of all modules. A client has to look for every module in a server-specific set of named schema sets, and then reconcile all these sets. I still prefer the single module list with a conformance leaf and a leaf-list indicating the supported (or unsupported) datastores. > For me, some of the interesting design questions have revolved around: > - is it better to reduce duplication in the list of modules reported at > the cost of increased model complexity? > - does the solution extend to schema mount? > - how well does the solution cope with with configuration datastores that > support very different sets of modules? > > To a lesser extent we have also been considering how well the solution > extends to packaging and semantic versioning, but I think that it is quite > tricky to know who these are going to pan out. E.g. I think that the > restriction that a given schema will only implement a single revision of a > module will end up still holding, but I'm not sure that everyone has that > same view point. > > Thanks, > Rob > > > Andy > > > Andy > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen wrote: > >> CC-ing NETCONF, where the draft is being worked on. >> >> Kent >> >> >> On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: >> > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: >> > > >> > > Yes. The default value for yang-library-datastore leaf is >> ds:operational >> > > (the only possible one for the ds:operational datastore). This is >> backward >> > > compatible. If one needs different model for 'running', etc. then a >> new >> > > datastore identity has to be defined and set in place of the default >> value. >> > > Then this identity can be used to read the yang-library data with >> > > . >> > > >> > >> > Sorry, but I have to ask this: How do I obtain the schema for the >> > datastore (lets call it ) that reports the schema for >> > ? Is there another datastore? Will >> > the recursion end? Perhaps it does since >> > might have itself listed as the schema defining datastore. I guess >> > Lada will like these kind of meta and meta-meta datastores. >> >> Not really. Metadata needn't be in datastores. >> >> Lada >> >> > >> > /js >> > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh >> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv >> jISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I >> 7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > --f403045f771e2dcb01056016c1e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20

Hi,


On 08/12/2017 18:01= , Andy Bierman wrote:
=20
Hi,

A library per datastore sounds too complicated.
I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a single module l= ist.
The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.=C2=A0 E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS.


Why is it interesting to have a separate module list for regular modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler.


IMO you are replacing universally meaningful keys =C2=A0(module-name, re= vision-date) with an arbitrary name,
It is not cleaner and not si= mpler for a client.


2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.=C2=A0 (E.g. it prevents a server stating that two revisions of a module are both implemented).


= How is that the case if the schema list includes its own module list?
=
You mean there is a "unique" statement in the outer list tha= t insures that a module/revision
shows up at most once in all ins= tances of the inner module list?

=C2=A0
3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules.


The c= onformance leaf was good enough.
Duplicating the module list and = removing the conformance leaf is aggressively non-backward compatible.

=C2=A0

For a server, I would design it to "implement" one revision o= f every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the serve= r implements to satisfy "import-by-revision" and these are stat= ed in the implemented schema anyway.


I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such that a module
is implemented in all datastores, or a subset of all datastores.=C2=A0 Otherwise it probably won't
get supported in clients.
All solutions accommodate this requirement.
=

Seems to me all new solutions allow a server = to violate the MUST in the NMDA draft that
there is a superset of= all modules.=C2=A0 A client has to look for every module in a server-speci= fic
set of named schema sets, and then reconcile all these sets.<= /div>
I still prefer the single module list with a conformance leaf and= a leaf-list indicating
the supported (or unsupported) datastores= .



For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores that support very different sets of modules?

To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out.=C2=A0 E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point.

Thanks,
Rob




Andy
=C2=A0


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net> wrote:
CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:operational
> > (the only possible one for the ds:operational datastore). This is backward
> > compatible. If one needs different model for 'running', etc. then a new
> > datastore identity has to be defined=C2=A0 and set in place of the default value.
> > Then this identity can be used to read the yang-library data with
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the schema for
> <running>? Is there another <running-library-library> datastore? Will
> the recursion end? Perhaps it does since <running-library-library>
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@iet= f.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www= .ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63= rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Y= hqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5= Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&= ;e=3D


_______________________________________________
netmod mailing list
netmod@iet= f.org
https://www.ietf.org/mailman/listinfo/n= etmod



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


--f403045f771e2dcb01056016c1e9-- From nobody Tue Dec 12 02:38:10 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE91129415; Tue, 12 Dec 2017 02:38:05 -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 YfEFADYIqdMC; Tue, 12 Dec 2017 02:38:02 -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 AD3AD128D86; Tue, 12 Dec 2017 02:38:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5437E154198B; Tue, 12 Dec 2017 11:37:59 +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 RA0tqejBfJH0; Tue, 12 Dec 2017 11:37:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2B88F154198A; Tue, 12 Dec 2017 11:37:59 +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 G8hne69XbXbt; Tue, 12 Dec 2017 11:37:59 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id DE5461541985; Tue, 12 Dec 2017 11:37:58 +0100 (CET) From: Vladimir Vassilev To: Juergen Schoenwaelder , "netmod@ietf.org" , Netconf References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> <20171211161556.me7thzsos2ywai3r@elstar.local> Message-ID: <7a0def88-53d3-0c58-a6e3-80b59c87e1bc@transpacket.com> Date: Tue, 12 Dec 2017 11:37:58 +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: <20171211161556.me7thzsos2ywai3r@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Dec 2017 10:38:06 -0000 On 12/11/2017 05:15 PM, Juergen Schoenwaelder wrote: > I do not fully understand why you think it is worth to preserve the > old YANG module library structure. Clearly, it won't be backwards > compatible since an NMDA implementation may list modules that are not > implemented in all datastores and an old client talking to a new > server will thus misunderstand what is exposed via the old YANG module > library structure. Your proposal "looks" backwards compatible but it > is not if one takes a closer look. > > One can start making changes to say the conformance-type but then this > does not solve the problem since an old client does not know what a > new conformance type value means. The design team did look into the > option of keeping the old structure unchanged some weeks ago and we > finally arrived at the conclusion that it gets (i) ugly and (ii) does > not really provide backwards compatibility for a client written agains > the old YANG module library structure. > > Note that with the new proposals on the table, it should be possible > to provide a backwards compatible view on YANG library for systems > that implement the exact same module set (with the exact same set of > features and deviations) on all datastores they support. But for > systems where this is not true, it seems better to use new > definitions instead of tweaking semantics. > > Perhaps it helps if you can clearly phrase the objective of keeping > the old structure. What is the goal you want to achieve with that? I prefer to call it the current structure for now. I will try to=20 explain. My goal is to efficiently build transactional systems based on=20 YANG models and open standards. For this I need some reusable bricks. Such a brick is the rfc7895=20 ietf-yang-libraray module. Even in a system with multiple YANG model=20 contexts eventually processing breaks down to a single model context=20 e.g. for example a YANG data validation task performed in a command line=20 application comes down to: =C2=A0$ yang-data-validator yang-library-data.xml data.xml The command can be called multiple times for different data and=20 different contexts but it is the same very well tested simple tool. So=20 my point is why can we not use one of the 2 newly introduced methods for=20 instantiating this very well designed model for the needs of NMDA. 1. Use datastore for instantiation. 2. Use schema mount to mount rfc 7895 ietf-yang-library in the=20 ietf-datastores list. (an alternative I assume is especially applicable=20 to modules like ietf-yang-library that are self-contained) In general having a solution that is flexible can easily be trimmed=20 down. Adding special cases that are less flexible e.g. the=20 (not-implemented-in leaf-list or none at all for the case of fully=20 transactional systems with a single model context (no extra work for=20 these)). The advantage is that even with the not-implemented-in=20 leaf-list solution or other diff based the data processing tasks will=20 eventually convert the differential information to a data structure=20 implementing the rfc7895 ietf-yang-library data tree and the=20 yang-data-validator application will be backward compatible and=20 reusable. With changes that introduce a whole new level of abstraction=20 in place of the simple list with module name and revision as keys one=20 can't even reuse the groupings defined in that module and that is a=20 problem I try to avoid. Vladimir > /js > > On Mon, Dec 11, 2017 at 04:53:30PM +0100, Vladimir Vassilev wrote: >> On 12/11/2017 12:16 PM, Robert Wilton wrote: >> >>> Hi Vladimir, >>> >>> >>> On 09/12/2017 11:49, Vladimir Vassilev wrote: >>>> On 12/08/2017 07:01 PM, Andy Bierman wrote: >>>> >>>>> Hi, >>>>> >>>>> A library per datastore sounds too complicated. >>>> I am not proposing that. >>> I'm slightly lost, because I thought that was exactly what you were >>> proposing! ;-) >> I propose a solution that keeps ietf-yang-library a data model of a si= ngle >> YANG context specification doing the datastore specific modeling in >> ietf-datastores model instead. The solution can be both flexible >> (independent yang-library data instances per datastore as my example w= as >> focused on) or constrained ('not-implemented-in' modules leaf-list). H= ere is >> everything that is needed: >> >> module: ietf-datastores >> =C2=A0=C2=A0=C2=A0 +--ro datastores-state >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (model)? >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(same-as-o= perational) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(constrain= ed-to-operational) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro = not-implemented-in*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> >> /yanglib:module-state/module/name >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstra= ined) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 +--ro yang-library-datastore?=C2=A0=C2=A0 identityref >> >> YANG: >> ... >> container datastores-state { >> =C2=A0=C2=A0=C2=A0 config false; >> =C2=A0=C2=A0=C2=A0 list datastore { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name; >> =C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0 choice model { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case same-as-operational { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case constrained-to-operat= ional { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf-list not-= implemented-in { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ty= pe leafref { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 path "/yanglib:module-state/yanglib:module/yanglib:name"; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case unconstrained { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf yang-libr= ary-datastore { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ty= pe identityref { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 base ds:datastore; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0 } >> =C2=A0 } >> ... >> >> IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I= do >> not see why this has to be compromised. >>>> The fundamental point proposed is that the datastore relevant bits >>>> are kept in the ietf-datastores module instead of merging everything >>>> in a new ietf-yang-library entangled monster module. If needed >>>> ietf-datastores can augment ietf-yang-library but ietf-yang-library >>>> should be usable on its own without ietf-datastores. The solution is >>>> coherent and modular and addresses the problem statement. >>> The issue with this is that datastore augmentations to YANG library >>> would end up changing the meaning of the existing YANG library nodes. >>> E.g. an old client that ignores the datastore augmentations is going = to >>> get a nasty surprise when the server does not behave how it expects. >>> E.g. because the configuration node that it thinks should be there is= n't >>> there because it only supported in . >>> >>> This was one of the reasons for changing YANG library. >> A well written client that finds out unsupported newer versions of >> ietf-yang-library (which is reported in the capabilities) or any of th= e NMDA >> modules is deployed should not do any damage. How exactly did you solv= e the >> problem for the bad clients by changing the structure of yang-library = in a >> incompatible way is something I do not understand. >>> In terms of the idea of just re-using YANG library but export a separ= ate >>> copy for each datastore I think that this has its own problems: >>> - I don't like the idea of returning meta-data along with configurati= on >>> for a on any of the configuration datastores. >> There is no meta data. The datastores contain only the config false; >> /modules-state tree. I think I explained that very clearly. >>> - How does a client know whether the YANG library for appli= es >>> to the whole server (as it does today) vs just applies to the >>> datastore (as it would for an NMDA server)? >> All datastore models are "case same-as-operational" for such systems. >>> - It requires more handshaking between the client and server to get t= he >>> schema, since a separate request would be required for each datastore >>> that is supported. >> Correct. Flexibility and modularity come at a price. IMO modularity is= more >> important in this case. And there are solutions for the problem e.g. s= end >> all requests before waiting for replies. NETCONF supports t= his. >>> So, for me, I think that the only way that this solution works, would= be >>> to define a new RPC, but even then I think that= it >>> would make sense to combine the data together into a new YANG library >>> structure. >> As I said my focus is on keeping ietf-yang-library modular (single YAN= G >> model context). or just adding datastore identit= ies >> allowing the client to use to achieve the retrieval of the = data >> is of little importance to me. >> >>> At the end of the day, I don't think that a new YANG library is going= to >>> be were the real cost for supporting NMDA comes from.=C2=A0 I think t= hat the >>> real work is supporting independently from bo= th >>> in the client and servers. But I also think that once servers start >>> implementing this properly that it will simplify automation, because >>> rather than a client having to guess what state a server is in, it ca= n >>> actually querey, or be notified of it, without having to write a lot = of >>> model specific code. >> +1 >> >> Vladimir >>> Thanks, >>> Rob >>> >>> >>>>> I prefer the proposal that was made at the IETF meeting that had >>>>> a 'not-implemented-in' leaf-list and a single module list. >>>> This constraint is already specified in the text of the revised >>>> datastores draft. Clients conforming to the draft can expect servers >>>> to comply with the MUST requirement even if there is a separate >>>> yang-library data tree for each datastore the constraint of >>>> configuration stores mapping to 'operational' should be enforced >>>> according to the draft. There is no contradiction here. >>>> >>>> That said I would be also be OK with ietf-datastores augmenting >>>> ietf-yang-library with such a leaf-list ('not-implemented-in' >>>> leaf-list) as a more constrained flavor of the same approach instead >>>> of going for independent copies of yang-library data. For any of >>>> that to happen change in ietf-datastores.yang is needed and change >>>> in the original rfc7895 ietf-yang-library is not needed at all. >>>> >>>> Vladimir >>>> >>>>> Why is it interesting to have a separate module list for regular >>>>> modules and imported modules? >>>>> I prefer to keep the conformance leaf and not change the module lis= t. >>>>> >>>>> NMDA needs to be possible to implement with a single schema tree >>>>> such that a module >>>>> is implemented in all datastores, or a subset of all >>>>> datastores.=C2=A0 Otherwise it probably won't >>>>> get supported in clients. >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen >>>> > wrote: >>>>> >>>>> =C2=A0=C2=A0=C2=A0 CC-ing NETCONF, where the draft is being worked= on. >>>>> >>>>> =C2=A0=C2=A0=C2=A0 Kent >>>>> >>>>> >>>>> =C2=A0=C2=A0=C2=A0 On Fri, 2017-12-08 at 16:34 +0100, Juergen Scho= enwaelder wrote: >>>>> =C2=A0=C2=A0=C2=A0 > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vla= dimir >>>>> Vassilev wrote: >>>>> =C2=A0=C2=A0=C2=A0 > > >>>>> =C2=A0=C2=A0=C2=A0 > > Yes. The default value for yang-library-dat= astore leaf is >>>>> =C2=A0=C2=A0=C2=A0 ds:operational >>>>> =C2=A0=C2=A0=C2=A0 > > (the only possible one for the ds:operation= al datastore). This >>>>> =C2=A0=C2=A0=C2=A0 is backward >>>>> =C2=A0=C2=A0=C2=A0 > > compatible. If one needs different model fo= r 'running', etc. >>>>> =C2=A0=C2=A0=C2=A0 then a new >>>>> =C2=A0=C2=A0=C2=A0 > > datastore identity has to be defined=C2=A0 = and set in place of the >>>>> =C2=A0=C2=A0=C2=A0 default value. >>>>> =C2=A0=C2=A0=C2=A0 > > Then this identity can be used to read the = yang-library >>>>> data with >>>>> =C2=A0=C2=A0=C2=A0 > > . >>>>> =C2=A0=C2=A0=C2=A0 > > >>>>> =C2=A0=C2=A0=C2=A0 > >>>>> =C2=A0=C2=A0=C2=A0 > Sorry, but I have to ask this: How do I obtai= n the schema for the >>>>> =C2=A0=C2=A0=C2=A0 > datastore (lets call it ) th= at reports the >>>>> =C2=A0=C2=A0=C2=A0 schema for >>>>> =C2=A0=C2=A0=C2=A0 > ? Is there another datastore? >>>>> =C2=A0=C2=A0=C2=A0 Will >>>>> =C2=A0=C2=A0=C2=A0 > the recursion end? Perhaps it does since >>>>> >>>>> =C2=A0=C2=A0=C2=A0 > might have itself listed as the schema defini= ng datastore. >>>>> I guess >>>>> =C2=A0=C2=A0=C2=A0 > Lada will like these kind of meta and meta-me= ta datastores. >>>>> >>>>> =C2=A0=C2=A0=C2=A0 Not really. Metadata needn't be in datastores. >>>>> >>>>> =C2=A0=C2=A0=C2=A0 Lada >>>>> >>>>> =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 Ladislav Lhotka >>>>> =C2=A0=C2=A0=C2=A0 Head, CZ.NIC Labs >>>>> =C2=A0=C2=A0=C2=A0 PGP Key ID: 0xB8F92B08A9F76C67 >>>>> >>>>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>>>> =C2=A0=C2=A0=C2=A0 netmod mailing list >>>>> netmod@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3v= oDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwq= YmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeF= RrvQI5l8&e=3D >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>>>> =C2=A0=C2=A0=C2=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 >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 12 02:48:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D01129420; Tue, 12 Dec 2017 02:47:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ixVqc_NLFvM9; Tue, 12 Dec 2017 02:47: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 AEC5B124C27; Tue, 12 Dec 2017 02:47:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D4CC669; Tue, 12 Dec 2017 11:47: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 syCyj3YvFqn0; Tue, 12 Dec 2017 11:47: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; Tue, 12 Dec 2017 11:47:48 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF6BA2012C; Tue, 12 Dec 2017 11:47:48 +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 v5VPPG1XKWUZ; Tue, 12 Dec 2017 11:47:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D93B220129; Tue, 12 Dec 2017 11:47:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 891294195397; Tue, 12 Dec 2017 11:46:17 +0100 (CET) Date: Tue, 12 Dec 2017 11:46:17 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Cc: "netmod@ietf.org" , Netconf Message-ID: <20171212104617.fvmpzn7q2kh2xaku@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Vladimir Vassilev , "netmod@ietf.org" , Netconf References: <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> <20171211161556.me7thzsos2ywai3r@elstar.local> <7a0def88-53d3-0c58-a6e3-80b59c87e1bc@transpacket.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: <7a0def88-53d3-0c58-a6e3-80b59c87e1bc@transpacket.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Dec 2017 10:47:54 -0000 On Tue, Dec 12, 2017 at 11:37:58AM +0100, Vladimir Vassilev wrote: > > > On 12/11/2017 05:15 PM, Juergen Schoenwaelder wrote: > > I do not fully understand why you think it is worth to preserve the > > old YANG module library structure. Clearly, it won't be backwards > > compatible since an NMDA implementation may list modules that are not > > implemented in all datastores and an old client talking to a new > > server will thus misunderstand what is exposed via the old YANG module > > library structure. Your proposal "looks" backwards compatible but it > > is not if one takes a closer look. > > > > One can start making changes to say the conformance-type but then this > > does not solve the problem since an old client does not know what a > > new conformance type value means. The design team did look into the > > option of keeping the old structure unchanged some weeks ago and we > > finally arrived at the conclusion that it gets (i) ugly and (ii) does > > not really provide backwards compatibility for a client written agains > > the old YANG module library structure. > > > > Note that with the new proposals on the table, it should be possible > > to provide a backwards compatible view on YANG library for systems > > that implement the exact same module set (with the exact same set of > > features and deviations) on all datastores they support. But for > > systems where this is not true, it seems better to use new > > definitions instead of tweaking semantics. > > > > Perhaps it helps if you can clearly phrase the objective of keeping > > the old structure. What is the goal you want to achieve with that? > I prefer to call it the current structure for now. I will try to explain. My > goal is to efficiently build transactional systems based on YANG models and > open standards. > > For this I need some reusable bricks. Such a brick is the rfc7895 > ietf-yang-libraray module. Even in a system with multiple YANG model > contexts eventually processing breaks down to a single model context e.g. > for example a YANG data validation task performed in a command line > application comes down to: > $ yang-data-validator yang-library-data.xml data.xml I think you can implement $ yang-data-validator yang-library-data-bis.xml data.xml and it will work for any datastore data in data.xml with and without schema mount. > The command can be called multiple times for different data and different > contexts but it is the same very well tested simple tool. Looks like you do not want to make changes but then you have to make changes. I am not sure how to address such a requirement. > So my point is why > can we not use one of the 2 newly introduced methods for instantiating this > very well designed model for the needs of NMDA. > > 1. Use datastore for instantiation. > 2. Use schema mount to mount rfc 7895 ietf-yang-library in the > ietf-datastores list. (an alternative I assume is especially applicable to > modules like ietf-yang-library that are self-contained) > > In general having a solution that is flexible can easily be trimmed down. > Adding special cases that are less flexible e.g. the (not-implemented-in > leaf-list or none at all for the case of fully transactional systems with a > single model context (no extra work for these)). The advantage is that even > with the not-implemented-in leaf-list solution or other diff based the data > processing tasks will eventually convert the differential information to a > data structure implementing the rfc7895 ietf-yang-library data tree and the > yang-data-validator application will be backward compatible and reusable. > With changes that introduce a whole new level of abstraction in place of the > simple list with module name and revision as keys one can't even reuse the > groupings defined in that module and that is a problem I try to avoid. I think you can easily express the ietf-yang-library model in ietf-yang-library-bis so moving to ietf-yang-library-bis will give you a clean solution. > Vladimir > > > > /js > > > > On Mon, Dec 11, 2017 at 04:53:30PM +0100, Vladimir Vassilev wrote: > > > On 12/11/2017 12:16 PM, Robert Wilton wrote: > > > > > > > Hi Vladimir, > > > > > > > > > > > > On 09/12/2017 11:49, Vladimir Vassilev wrote: > > > > > On 12/08/2017 07:01 PM, Andy Bierman wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > A library per datastore sounds too complicated. > > > > > I am not proposing that. > > > > I'm slightly lost, because I thought that was exactly what you were > > > > proposing! ;-) > > > I propose a solution that keeps ietf-yang-library a data model of a single > > > YANG context specification doing the datastore specific modeling in > > > ietf-datastores model instead. The solution can be both flexible > > > (independent yang-library data instances per datastore as my example was > > > focused on) or constrained ('not-implemented-in' modules leaf-list). Here is > > > everything that is needed: > > > > > > module: ietf-datastores > > > +--ro datastores-state > > > +--ro datastore* [name] > > > +--ro (model)? > > > +--:(same-as-operational) > > > +--:(constrained-to-operational) > > > | +--ro not-implemented-in* -> > > > /yanglib:module-state/module/name > > > +--:(unconstrained) > > > +--ro yang-library-datastore? identityref > > > > > > YANG: > > > ... > > > container datastores-state { > > > config false; > > > list datastore { > > > key name; > > > } > > > choice model { > > > case same-as-operational { > > > } > > > case constrained-to-operational { > > > leaf-list not-implemented-in { > > > type leafref { > > > path "/yanglib:module-state/yanglib:module/yanglib:name"; > > > } > > > } > > > } > > > case unconstrained { > > > leaf yang-library-datastore { > > > type identityref { > > > base ds:datastore; > > > } > > > } > > > } > > > } > > > } > > > ... > > > > > > IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I do > > > not see why this has to be compromised. > > > > > The fundamental point proposed is that the datastore relevant bits > > > > > are kept in the ietf-datastores module instead of merging everything > > > > > in a new ietf-yang-library entangled monster module. If needed > > > > > ietf-datastores can augment ietf-yang-library but ietf-yang-library > > > > > should be usable on its own without ietf-datastores. The solution is > > > > > coherent and modular and addresses the problem statement. > > > > The issue with this is that datastore augmentations to YANG library > > > > would end up changing the meaning of the existing YANG library nodes. > > > > E.g. an old client that ignores the datastore augmentations is going to > > > > get a nasty surprise when the server does not behave how it expects. > > > > E.g. because the configuration node that it thinks should be there isn't > > > > there because it only supported in . > > > > > > > > This was one of the reasons for changing YANG library. > > > A well written client that finds out unsupported newer versions of > > > ietf-yang-library (which is reported in the capabilities) or any of the NMDA > > > modules is deployed should not do any damage. How exactly did you solve the > > > problem for the bad clients by changing the structure of yang-library in a > > > incompatible way is something I do not understand. > > > > In terms of the idea of just re-using YANG library but export a separate > > > > copy for each datastore I think that this has its own problems: > > > > - I don't like the idea of returning meta-data along with configuration > > > > for a on any of the configuration datastores. > > > There is no meta data. The datastores contain only the config false; > > > /modules-state tree. I think I explained that very clearly. > > > > - How does a client know whether the YANG library for applies > > > > to the whole server (as it does today) vs just applies to the > > > > datastore (as it would for an NMDA server)? > > > All datastore models are "case same-as-operational" for such systems. > > > > - It requires more handshaking between the client and server to get the > > > > schema, since a separate request would be required for each datastore > > > > that is supported. > > > Correct. Flexibility and modularity come at a price. IMO modularity is more > > > important in this case. And there are solutions for the problem e.g. send > > > all requests before waiting for replies. NETCONF supports this. > > > > So, for me, I think that the only way that this solution works, would be > > > > to define a new RPC, but even then I think that it > > > > would make sense to combine the data together into a new YANG library > > > > structure. > > > As I said my focus is on keeping ietf-yang-library modular (single YANG > > > model context). or just adding datastore identities > > > allowing the client to use to achieve the retrieval of the data > > > is of little importance to me. > > > > > > > At the end of the day, I don't think that a new YANG library is going to > > > > be were the real cost for supporting NMDA comes from. I think that the > > > > real work is supporting independently from both > > > > in the client and servers. But I also think that once servers start > > > > implementing this properly that it will simplify automation, because > > > > rather than a client having to guess what state a server is in, it can > > > > actually querey, or be notified of it, without having to write a lot of > > > > model specific code. > > > +1 > > > > > > Vladimir > > > > Thanks, > > > > Rob > > > > > > > > > > > > > > I prefer the proposal that was made at the IETF meeting that had > > > > > > a 'not-implemented-in' leaf-list and a single module list. > > > > > This constraint is already specified in the text of the revised > > > > > datastores draft. Clients conforming to the draft can expect servers > > > > > to comply with the MUST requirement even if there is a separate > > > > > yang-library data tree for each datastore the constraint of > > > > > configuration stores mapping to 'operational' should be enforced > > > > > according to the draft. There is no contradiction here. > > > > > > > > > > That said I would be also be OK with ietf-datastores augmenting > > > > > ietf-yang-library with such a leaf-list ('not-implemented-in' > > > > > leaf-list) as a more constrained flavor of the same approach instead > > > > > of going for independent copies of yang-library data. For any of > > > > > that to happen change in ietf-datastores.yang is needed and change > > > > > in the original rfc7895 ietf-yang-library is not needed at all. > > > > > > > > > > Vladimir > > > > > > > > > > > Why is it interesting to have a separate module list for regular > > > > > > modules and imported modules? > > > > > > I prefer to keep the conformance leaf and not change the module list. > > > > > > > > > > > > NMDA needs to be possible to implement with a single schema tree > > > > > > such that a module > > > > > > is implemented in all datastores, or a subset of all > > > > > > datastores. Otherwise it probably won't > > > > > > get supported in clients. > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > > > > > wrote: > > > > > > > > > > > > CC-ing NETCONF, where the draft is being worked on. > > > > > > > > > > > > Kent > > > > > > > > > > > > > > > > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > > > > > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir > > > > > > Vassilev wrote: > > > > > > > > > > > > > > > > Yes. The default value for yang-library-datastore leaf is > > > > > > ds:operational > > > > > > > > (the only possible one for the ds:operational datastore). This > > > > > > is backward > > > > > > > > compatible. If one needs different model for 'running', etc. > > > > > > then a new > > > > > > > > datastore identity has to be defined and set in place of the > > > > > > default value. > > > > > > > > Then this identity can be used to read the yang-library > > > > > > data with > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > > > > > > datastore (lets call it ) that reports the > > > > > > schema for > > > > > > > ? Is there another datastore? > > > > > > Will > > > > > > > the recursion end? Perhaps it does since > > > > > > > > > > > > > might have itself listed as the schema defining datastore. > > > > > > I guess > > > > > > > Lada will like these kind of meta and meta-meta datastores. > > > > > > > > > > > > Not really. Metadata needn't be in datastores. > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > -- > > > > > > Ladislav Lhotka > > > > > > Head, CZ.NIC Labs > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > > 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 Tue Dec 12 07:42:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74F1294A2 for ; Tue, 12 Dec 2017 07:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 lauQHLktsG6r for ; Tue, 12 Dec 2017 07:42:47 -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 ACB07127077 for ; Tue, 12 Dec 2017 07:42:47 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 1BB011E106B for ; Tue, 12 Dec 2017 08:42:04 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id l3i01w00D2SSUrH013i3f4; Tue, 12 Dec 2017 08:42:04 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=FcTUuYA1uVtRCE6JGIQA: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:References:To:From: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=TUkKcg+m9z+67JTbZ+TOArCpH5ufeld78usGxXTdCyo=; b=frM0TvMe5En3WEruLbmAAAYjOt TUGr6/xCnOMEYegWt9Mw3VZOPRaqOCwzkVXx/uZvtmzz2+mLSxnQa93Tkd+VBwQfpTyTVItJBtj6F Ziayzhmch8dir+XiF9c+/J4wo; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:36296 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 1eOmgy-003inV-FE; Tue, 12 Dec 2017 08:42:00 -0700 From: Lou Berger To: "draft-ietf-netmod-revised-datastores@ietf.org" References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> Cc: NetMod WG , NetMod WG Chairs Message-ID: <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> Date: Tue, 12 Dec 2017 10:41:59 -0500 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: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> 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: 1eOmgy-003inV-FE 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]:36296 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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, 12 Dec 2017 15:42:49 -0000 Hi, These comments are based on my Shepherd review of this document and should be addressed as part of addressing any LC comments: 1) Considering the recent discussion on Library made me consider the general case of a module that is composed entirely of operational state. I think this case is subject to interpretation and therefore needs to be explicitly covered. For example section 5.3 states: The datastore schema for MUST be a superset of the combined datastore schema used in all configuration datastores except that YANG nodes supported in a configuration datastore MAY be omitted from if a server is not able to accurately report them. This could be read that a module that an operational state MUST be present (but presumably empty>?) in some other DS to be present in operational. I don't believe this is your intent, but it should be explicitly covered for the benefit of future readers. I suspect that this also should translate to an explicit case in section 6.1 as well. 2) The abstract needs to mention that it updates RFC7950 (per idnits) 3) A minor point, the document uses the terms boot and reboot. I suspect that these terms are intended to cover any full or partial, e.g., protocol, restart operation supported on a system - which may not include a full boot. I think the document needs to be clear on this point. Perhaps just add a definition, or note that full and partial restart operations are included when the document refers to boot and reboot. Thank you, Lou (As Shepherd) On 12/04/2017 09:35 AM, Lou Berger wrote: > All, > > This starts a second working group last call on > draft-ietf-netmod-revised-datastores. > > As this is a 2nd LC that is focused on changes since the last LC, it closes in *one* week. The working group last call ends on December 11. Please send your comments to the netmod mailing list. > > At this point, we're most interested in verifying that previous comments are addressed since the last call on the -04 rev of the draft was held. > > A summary of changes can be found at > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4 > > A diff can be found at > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt > > Comments along the of: I have reviewed this version of the document and it addresses my previous comments would be particularly helpful. > > Thank you, > Netmod Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Dec 12 07:45:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4B81294A6 for ; Tue, 12 Dec 2017 07:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 HUrDwAecd8xx for ; Tue, 12 Dec 2017 07:45:32 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 D6C3E1294A3 for ; Tue, 12 Dec 2017 07:45:30 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 85A331406DE for ; Tue, 12 Dec 2017 08:45:30 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id l3lS1w00U2SSUrH013lVYD; Tue, 12 Dec 2017 08:45:30 -0700 X-Authority-Analysis: v=2.2 cv=OMJX5WSB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=mkKBeB7oJYWmdtwfqfkA: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:References:To:From: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=4cKdvUV9eYmwYXdyVgeHeGRQE56xHtx8h1qNC6mq1F4=; b=Vm2icnsVnFqHG+/dhH0XZruf87 99yGsAaTtzXlX65GF2e+ta5rqNifcPOemFkTIQU68voCTLCG+5Yx8OzU7F74SEpT3WPMeAi0/DZ+g Gs95I1BlXS3Iz+tB6fqnyXYQ6; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:36446 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 1eOmkI-003jqs-GR; Tue, 12 Dec 2017 08:45:26 -0700 From: Lou Berger To: NetMod WG , "draft-ietf-netmod-revised-datastores@ietf.org" References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> Cc: NetMod WG Chairs Message-ID: <51904884-9544-2ef5-26d8-df25cb2bc136@labn.net> Date: Tue, 12 Dec 2017 10:45:25 -0500 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: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> 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: 1eOmkI-003jqs-GR 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]:36446 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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, 12 Dec 2017 15:45:34 -0000 All, This LC is closed. Authors, Please address any/all comments received during the LC. Once you've published the version that you believe addresses all comments/pending changes, please summarize the changes on the list and let us all know that you believe that the version is ready to submit to the IESG for publication. Thank you, Lou On 12/04/2017 09:35 AM, Lou Berger wrote: > All, > > This starts a second working group last call on > draft-ietf-netmod-revised-datastores. > > As this is a 2nd LC that is focused on changes since the last LC, it closes in *one* week. The working group last call ends on December 11. Please send your comments to the netmod mailing list. > > At this point, we're most interested in verifying that previous comments are addressed since the last call on the -04 rev of the draft was held. > > A summary of changes can be found at > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4 > > A diff can be found at > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt > > Comments along the of: I have reviewed this version of the document and it addresses my previous comments would be particularly helpful. > > Thank you, > Netmod Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Dec 12 11:20:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32035129534 for ; Tue, 12 Dec 2017 11:20:06 -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 OEgk_oAzHzlI for ; Tue, 12 Dec 2017 11:20:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67C12952E for ; Tue, 12 Dec 2017 11:20:02 -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 735A41AE0335; Tue, 12 Dec 2017 20:20:01 +0100 (CET) Date: Tue, 12 Dec 2017 20:20:01 +0100 (CET) Message-Id: <20171212.202001.1743562517319162368.mbj@tail-f.com> To: vladimir@transpacket.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Dec 2017 19:20:06 -0000 Hi, Vladimir Vassilev wrote: > = > = > On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: > > On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: > >> Vladimir Vassilev wrote: > >>> On 11/15/2017 06:29 PM, Robert Wilton wrote: > >>> > >>>> I don't think that this is really a good idea.=A0 You would end = up > >>>> returning server metadata in addition to the configuration. > >>> Obviously RFC 7895 defines only config false; data and I was not > >>> proposing a change to that. But I agree something has to be added= to > >>> complete the solution. Special purpose datastore identities can b= e > >>> defined that return instance of yang-library data when read with > >>> . (Datastores with yang-library config false; only data= not > >>> represented in 'operational') > >>> > >>> Adding this special yang-library-datastore to the proposed > >>> ietf-datastores container e.g. > >>> > >>> module: ietf-datastores > >>> +--ro datastores > >>> |=A0 +--ro datastore* [name] > >>> |=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityref > >>> |=A0=A0=A0=A0 +--ro yang-library-datastore =A0=A0=A0=A0=A0=A0=A0=A0= identityref > >>> > >> I don't understand this proposal. How would a client learn the > >> library for ? For ? > > My interpretation is that the client reads the datastores list from= > > and the list entries give you the identity of a separ= ate > > datastore that gives you the content of the yang library for that > > datastore. (For each datastore, you have a separate datastore to > > report its yang library.) > Yes. The default value for yang-library-datastore leaf is > ds:operational (the only possible one for the ds:operational > datastore). This is backward compatible. If one needs different model= > for 'running', etc. then a new datastore identity has to be defined=A0= > and set in place of the default value. Then this identity can be used= > to read the yang-library data with . Ah, ok. This is a clever solution, but quite complicated. It requires several round trips for a client to learn all library instances. Also, w/o any changes, it is not clear which module-set-id is sent in the capability, and a client must query all module-set-ids in all (meta)datastores in order to just check if it has the latest version or not. It is also not clear how the existing notification "yang-library-change" would work when there are multiple instances involved. So I don't think that this solution will actually work w/o an update to 7895 - but not updating 7895 was the whole reason for doing this. /martin From nobody Tue Dec 12 12:04:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F681128656 for ; Tue, 12 Dec 2017 12:04: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, 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 bQ6oDchaCbAs for ; Tue, 12 Dec 2017 12:04:20 -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 EB3F1126B7E for ; Tue, 12 Dec 2017 12:04:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 78D141541A84; Tue, 12 Dec 2017 21:04:17 +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 1LxNKZNR50Yw; Tue, 12 Dec 2017 21:04:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4CDAE1541A86; Tue, 12 Dec 2017 21:04:17 +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 ylOAVEJ5aKIf; Tue, 12 Dec 2017 21:04:17 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 2C5671541A84; Tue, 12 Dec 2017 21:04:17 +0100 (CET) From: Vladimir Vassilev To: Kent Watsen , "netmod@ietf.org" References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> <975828fb-cd82-84fb-540b-58b8012872b5@transpacket.com> Message-ID: Date: Tue, 12 Dec 2017 21:04:16 +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: <975828fb-cd82-84fb-540b-58b8012872b5@transpacket.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Dec 2017 20:04:23 -0000 Hello, The previous post was intended for the rfc7223bis Last Call (wrong=20 subject line). I just completed similar validation through a testcase for the examples=20 in rfc7277bis ("Appendix A.=C2=A0 Example: NETCONF reply" an= d=20 "Appendix B.=C2=A0 Example: NETCONF Reply") Here there are some inconsistencies between the output and=20 the expected output. A missing origin bug is probably more=20 significant then the rest. The following patch fixes the inconsistencies=20 and the testcase passes: --- before.txt=C2=A0=C2=A0=C2=A0 2017-12-12 20:39:09.037576425 +0100 +++ after.txt=C2=A0=C2=A0=C2=A0 2017-12-12 20:37:46.425656680 +0100 @@ -7,14 +7,12 @@ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ianaift:ethernetCsmacd =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= false -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 1500 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 192.0.2.1 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 24 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 static =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 192.0.2.2 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:01:02:03:04:05 @@ -22,7 +20,6 @@ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= false =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 1280 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 2001:db8::10 In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and this=20 is only a report of a detected issue. Vladimir On 12/11/2017 05:35 PM, Vladimir Vassilev wrote: > Hello, > > I've reviewed this document and believe it is ready for publication. > > The focus of my review this time was on validating the module and the=20 > example modules and example data through running code. I implemented=20 > NMDA for the open source tools we use and added a testcase that=20 > reproduces the result specified in "Appendix E. Example: NETCONF=20 > Reply" after loading the configuration specified in=20 > "Appendix D.=C2=A0 Example: NETCONF Reply" and providing t= he=20 > config false; data and system originated configuration as needed. I=20 > can confirm the implementation validated the example modules and the=20 > example data producing identical output. > > IMO the examples are demonstrating well the concept of NMDA and its=20 > application for the ietf-interfaces module. > > I had an issue with a bug in ietf-netconf-datastores@2017-08-24.yang I=20 > had to fix in order to use the RPC. The bug is already=20 > reported on the mailing-list. > > diff ietf-patched/ietf-netconf-datastores@2017-08-24.yang=20 > ietf-draft/ietf-netconf-datastores@2017-08-24.yang > 140c140 > <=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when 'derived-from-or= -self(../datastore, "ds:operational")'; > --- >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when 'derived-from-or-self(= ../datastore, "or:operational")'; > > Vladimir > > > On 11/28/2017 08:29 PM, Kent Watsen wrote: >> All, >> >> This starts a two-week working group last call on >> draft-ietf-netmod-rfc7277bis-00. >> >> Please recall that this update's intention is to >> modify the YANG module to be in line with the NMDA >> guidelines [1].=C2=A0 Reviewing the diff between the two >> drafts [2] should reveal just this. >> >> The working group last call ends on December 12. >> 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. >> >> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 >> [2]=20 >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7277bis-00.= txt >> >> Thank you, >> Netmod 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 Tue Dec 12 12:59:01 2017 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 CAC891294FD; Tue, 12 Dec 2017 12:58:56 -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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151311233678.14038.17470158262264222561@ietfa.amsl.com> Date: Tue, 12 Dec 2017 12:58:56 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-18.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, 12 Dec 2017 20:58: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 : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-18.txt Pages : 33 Date : 2017-12-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 "xxxx" --> the assigned RFC value for draft-ietf-netconf-keystore o "yyyy" --> 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-18 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 Dec 12 13:02:16 2017 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 ECFB0128B4E; Tue, 12 Dec 2017 13:02: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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151311252893.14038.17806980825762270436@ietfa.amsl.com> Date: Tue, 12 Dec 2017 13:02:08 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-04.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, 12 Dec 2017 21:02:09 -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-04.txt Pages : 74 Date : 2017-12-12 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 main difference from the first version is that this version fully conforms to the Network Management Datastore Architecture (NMDA). Consequently, 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 12 13:06:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA6012896F for ; Tue, 12 Dec 2017 13:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.499 X-Spam-Level: X-Spam-Status: No, score=-13.499 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, 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 HhRAdBKYeeal for ; Tue, 12 Dec 2017 13:06:42 -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 C44561279E5 for ; Tue, 12 Dec 2017 13:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3516; q=dns/txt; s=iport; t=1513112801; x=1514322401; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wfo4aCERvi/FXbHwX4s/xpn3EaKhOaQtJQnppRyD254=; b=Tl8Ky5YOVYfvmDx/5wMQwaCROcw7XE2RMsRKGA8Rrg+4YpiwXQ7DSZKz qm7zDzTWJs0E6dq8Wi3PLsolaUmkJxDaTBbldfSfbEIR45ve8/Q6+kOhJ slvvM9p1lDAviqxqyyxByT9PY/VvlPITTz398tiXee2xaXANeOY/2dSWt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AACERDBa/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQYDweDe4ohjwWBRASXRoIVChgLhElPAhoMhGI/GAEBAQE?= =?us-ascii?q?BAQEBAWsohRsJAgQBASEROgsQAgEIEggCJgICAiULFQIOAhIFhXKENhCoeYIni?= =?us-ascii?q?mEBAQEBAQEBAwEBAQEBAQEBIIEPglSCC4M/gyuDLgEBF4FWgxUUgk8FoxcCh3m?= =?us-ascii?q?NK4IWY4Uviz+NDokpAhEZAYE6AR85gU5vFRYkgQQIgR0JhEx4iTiBFQEBBQ?= X-IronPort-AV: E=Sophos;i="5.45,395,1508803200"; d="scan'208";a="43242371" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2017 21:06:41 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBCL6ePt009807 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Dec 2017 21:06:40 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, 12 Dec 2017 16:06:40 -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, 12 Dec 2017 16:06:40 -0500 From: "Acee Lindem (acee)" CC: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-04.txt Thread-Index: AQHTc4yOIi3LyDkvCEmxCqgCb+iW+KNAMw+A Date: Tue, 12 Dec 2017 21:06:39 +0000 Message-ID: References: <151311252893.14038.17806980825762270436@ietfa.amsl.com> In-Reply-To: <151311252893.14038.17806980825762270436@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-04.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, 12 Dec 2017 21:06:43 -0000 VGhpcyB2ZXJzaW9uIGluY2x1ZGVzIHVwZGF0ZXMgdG8gdGhlIGV4YW1wbGVzIGluIEFwcGVuZGl4 IEQgdG8gbWF0Y2ggdGhlDQpORE1BIG1vZGVscyBhbmQgYSBuZXcgTkVUQ09ORiBYTUwgZXhhbXBs ZSBpbiBhcHBlbmRpeCBFIChhcyBzdWdnZXN0ZWQgYnkNClZsYWRpbWlyKS4gQWRkaXRpb25hbGx5 LCB0aGUg4oCcQWJzdHJhY3QiIGFuZCDigJxJbnRyb2R1Y3Rpb24iIGhhdmUgYmVlbg0KdXBkYXRl ZCB0byByZW1vdmUgdGhlIHN0YXRlbWVudCBpbmRpY2F0aW5nIHRoYXQgdGhlIE5ETUEgbW9kZWxz IGhhdmUgbmV3DQpuYW1lcy4gDQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDEyLzEyLzE3LCA0OjAy IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo8bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5kaXJlY3Rvcmllcy4NCj5UaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIE1vZGVsaW5nIFdHIG9mIHRoZSBJRVRGLg0KPg0K PiAgICAgICAgVGl0bGUgICAgICAgICAgIDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIFJvdXRpbmcg TWFuYWdlbWVudCAoTkRNQQ0KPlZlcnNpb24pDQo+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBM YWRpc2xhdiBMaG90a2ENCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEFjZWUgTGluZGVtDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICBZaW5nemhlbiBRdQ0KPglGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTA0LnR4dA0KPglQYWdlcyAgICAgICAgICAg OiA3NA0KPglEYXRlICAgICAgICAgICAgOiAyMDE3LTEyLTEyDQo+DQo+QWJzdHJhY3Q6DQo+ICAg VGhpcyBkb2N1bWVudCBjb250YWlucyBhIHNwZWNpZmljYXRpb24gb2YgdGhyZWUgWUFORyBtb2R1 bGVzIGFuZCBvbmUNCj4gICBzdWJtb2R1bGUuICBUb2dldGhlciB0aGV5IGZvcm0gdGhlIGNvcmUg cm91dGluZyBkYXRhIG1vZGVsIHRoYXQNCj4gICBzZXJ2ZXMgYXMgYSBmcmFtZXdvcmsgZm9yIGNv bmZpZ3VyaW5nIGFuZCBtYW5hZ2luZyBhIHJvdXRpbmcNCj4gICBzdWJzeXN0ZW0uICBJdCBpcyBl eHBlY3RlZCB0aGF0IHRoZXNlIG1vZHVsZXMgd2lsbCBiZSBhdWdtZW50ZWQgYnkNCj4gICBhZGRp dGlvbmFsIFlBTkcgbW9kdWxlcyBkZWZpbmluZyBkYXRhIG1vZGVscyBmb3IgY29udHJvbC1wbGFu ZQ0KPiAgIHByb3RvY29scywgcm91dGUgZmlsdGVycywgYW5kIG90aGVyIGZ1bmN0aW9ucy4gIFRo ZSBjb3JlIHJvdXRpbmcgZGF0YQ0KPiAgIG1vZGVsIHByb3ZpZGVzIGNvbW1vbiBidWlsZGluZyBi bG9ja3MgZm9yIHN1Y2ggZXh0ZW5zaW9ucyAtLSByb3V0ZXMsDQo+ICAgUm91dGluZyBJbmZvcm1h dGlvbiBCYXNlcyAoUklCcyksIGFuZCBjb250cm9sLXBsYW5lIHByb3RvY29scy4NCj4NCj4gICBU aGUgbWFpbiBkaWZmZXJlbmNlIGZyb20gdGhlIGZpcnN0IHZlcnNpb24gaXMgdGhhdCB0aGlzIHZl cnNpb24gZnVsbHkNCj4gICBjb25mb3JtcyB0byB0aGUgTmV0d29yayBNYW5hZ2VtZW50IERhdGFz dG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpLg0KPiAgIENvbnNlcXVlbnRseSwgdGhpcyBkb2N1bWVu dCBvYnNvbGV0ZXMgUkZDIDgwMjIuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy8NCj4NCj5UaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDQNCj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDQNCj4NCj5BIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDQN Cj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoN Cg== From nobody Tue Dec 12 23:19:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2FA126C26; Tue, 12 Dec 2017 23:19:10 -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 VCK3aOtOhtxJ; Tue, 12 Dec 2017 23:19:06 -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 D232A1292C5; Tue, 12 Dec 2017 23:19:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 90E2C1541B65; Wed, 13 Dec 2017 08:19: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 0Rh9TDIovatf; Wed, 13 Dec 2017 08:19:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6318F1541A12; Wed, 13 Dec 2017 08:19: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 tIYUHKMsiQOV; Wed, 13 Dec 2017 08:19:03 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 30E9D15419CA; Wed, 13 Dec 2017 08:19:03 +0100 (CET) To: Martin Bjorklund References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171212.202001.1743562517319162368.mbj@tail-f.com> Cc: "netmod@ietf.org" , Netconf From: Vladimir Vassilev Message-ID: Date: Wed, 13 Dec 2017 08:19: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: <20171212.202001.1743562517319162368.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 07:19:11 -0000 On 12/12/2017 08:20 PM, Martin Bjorklund wrote: > Hi, > > Vladimir Vassilev wrote: >> >> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: >>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: >>>> Vladimir Vassilev wrote: >>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: >>>>> >>>>>> I don't think that this is really a good idea.=C2=A0 You would end= up >>>>>> returning server metadata in addition to the configuration. >>>>> Obviously RFC 7895 defines only config false; data and I was not >>>>> proposing a change to that. But I agree something has to be added t= o >>>>> complete the solution. Special purpose datastore identities can be >>>>> defined that return instance of yang-library data when read with >>>>> . (Datastores with yang-library config false; only data n= ot >>>>> represented in 'operational') >>>>> >>>>> Adding this special yang-library-datastore to the proposed >>>>> ietf-datastores container e.g. >>>>> >>>>> module: ietf-datastores >>>>> +--ro datastores >>>>> |=C2=A0 +--ro datastore* [name] >>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 identityref >>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>> >>>> I don't understand this proposal. How would a client learn the >>>> library for ? For ? >>> My interpretation is that the client reads the datastores list from >>> and the list entries give you the identity of a separat= e >>> datastore that gives you the content of the yang library for that >>> datastore. (For each datastore, you have a separate datastore to >>> report its yang library.) >> Yes. The default value for yang-library-datastore leaf is >> ds:operational (the only possible one for the ds:operational >> datastore). This is backward compatible. If one needs different model >> for 'running', etc. then a new datastore identity has to be defined >> and set in place of the default value. Then this identity can be used >> to read the yang-library data with . > Ah, ok. This is a clever solution, but quite complicated. It > requires several round trips for a client to learn all library > instances. Also, w/o any changes, it is not clear which module-set-id > is sent in the capability, and a client must query all module-set-ids > in all (meta)datastores in order to just check if it has the latest > version or not. It is also not clear how the existing notification > "yang-library-change" would work when there are multiple instances > involved. How about this? module: ietf-datastores ... =C2=A0 augment /yanglib:yang-library-change: =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref Vladimir > So I don't think that this solution will actually work w/o > an update to 7895 - but not updating 7895 was the whole reason for > doing this. > > > /martin > From nobody Tue Dec 12 23:41:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A9D12700F; Tue, 12 Dec 2017 23:41:53 -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 VpK9CdTRZIyg; Tue, 12 Dec 2017 23:41: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 CBF40126C26; Tue, 12 Dec 2017 23:41:50 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C4AE1AE02BD; Wed, 13 Dec 2017 08:41:49 +0100 (CET) Date: Wed, 13 Dec 2017 08:40:30 +0100 (CET) Message-Id: <20171213.084030.1399882156946529918.mbj@tail-f.com> To: vladimir@transpacket.com Cc: netmod@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20171212.202001.1743562517319162368.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] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 07:41:53 -0000 Vladimir Vassilev wrote: > On 12/12/2017 08:20 PM, Martin Bjorklund wrote: > = > > Hi, > > > > Vladimir Vassilev wrote: > >> > >> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: > >>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote:= > >>>> Vladimir Vassilev wrote: > >>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: > >>>>> > >>>>>> I don't think that this is really a good idea.=A0 You would en= d up > >>>>>> returning server metadata in addition to the configuration. > >>>>> Obviously RFC 7895 defines only config false; data and I was no= t > >>>>> proposing a change to that. But I agree something has to be add= ed to > >>>>> complete the solution. Special purpose datastore identities can= be > >>>>> defined that return instance of yang-library data when read wit= h > >>>>> . (Datastores with yang-library config false; only da= ta not > >>>>> represented in 'operational') > >>>>> > >>>>> Adding this special yang-library-datastore to the proposed > >>>>> ietf-datastores container e.g. > >>>>> > >>>>> module: ietf-datastores > >>>>> +--ro datastores > >>>>> |=A0 +--ro datastore* [name] > >>>>> |=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityref= > >>>>> |=A0=A0=A0=A0 +--ro yang-library-datastore =A0=A0=A0=A0=A0=A0=A0= =A0 identityref > >>>>> > >>>> I don't understand this proposal. How would a client learn the > >>>> library for ? For ? > >>> My interpretation is that the client reads the datastores list fr= om > >>> and the list entries give you the identity of a sep= arate > >>> datastore that gives you the content of the yang library for that= > >>> datastore. (For each datastore, you have a separate datastore to > >>> report its yang library.) > >> Yes. The default value for yang-library-datastore leaf is > >> ds:operational (the only possible one for the ds:operational > >> datastore). This is backward compatible. If one needs different mo= del > >> for 'running', etc. then a new datastore identity has to be define= d > >> and set in place of the default value. Then this identity can be u= sed > >> to read the yang-library data with . > > Ah, ok. This is a clever solution, but quite complicated. It > > requires several round trips for a client to learn all library > > instances. Also, w/o any changes, it is not clear which module-set= -id > > is sent in the capability, and a client must query all module-set-i= ds > > in all (meta)datastores in order to just check if it has the latest= > > version or not. It is also not clear how the existing notification= > > "yang-library-change" would work when there are multiple instances > > involved. > How about this? > module: ietf-datastores > ... > =A0 augment /yanglib:yang-library-change: > =A0=A0=A0 +---- datastore?=A0=A0 identityref This has the same issue as augementing a datastore leaf-list into the current /modules-state/modules list would have - old clients won't understand this new node. /martin From nobody Tue Dec 12 23:50:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2935126D05; Tue, 12 Dec 2017 23:50:37 -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 AW1DCyMeo-Gs; Tue, 12 Dec 2017 23:50:35 -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 6B869126C26; Tue, 12 Dec 2017 23:50:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id C5EC11541B5F; Wed, 13 Dec 2017 08:50:33 +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 gf2Pr6xHjdey; Wed, 13 Dec 2017 08:50:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9911C1541B65; Wed, 13 Dec 2017 08:50:33 +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 XYQt8yAcXsay; Wed, 13 Dec 2017 08:50:33 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 63A8B1541AB1; Wed, 13 Dec 2017 08:50:33 +0100 (CET) From: Vladimir Vassilev To: Martin Bjorklund Cc: Netconf , "netmod@ietf.org" References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171212.202001.1743562517319162368.mbj@tail-f.com> Message-ID: <1c97862a-9bc5-6101-6a79-3438573a9aca@transpacket.com> Date: Wed, 13 Dec 2017 08:50:33 +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] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 07:50:37 -0000 On 12/13/2017 08:19 AM, Vladimir Vassilev wrote: > On 12/12/2017 08:20 PM, Martin Bjorklund wrote: > >> Hi, >> >> Vladimir Vassilev wrote: >>> >>> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: >>>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: >>>>> Vladimir Vassilev wrote: >>>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: >>>>>> >>>>>>> I don't think that this is really a good idea.=C2=A0 You would en= d up >>>>>>> returning server metadata in addition to the configuration. >>>>>> Obviously RFC 7895 defines only config false; data and I was not >>>>>> proposing a change to that. But I agree something has to be added = to >>>>>> complete the solution. Special purpose datastore identities can be >>>>>> defined that return instance of yang-library data when read with >>>>>> . (Datastores with yang-library config false; only data=20 >>>>>> not >>>>>> represented in 'operational') >>>>>> >>>>>> Adding this special yang-library-datastore to the proposed >>>>>> ietf-datastores container e.g. >>>>>> >>>>>> module: ietf-datastores >>>>>> +--ro datastores >>>>>> |=C2=A0 +--ro datastore* [name] >>>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>>> >>>>> I don't understand this proposal.=C2=A0 How would a client learn th= e >>>>> library for ?=C2=A0 For ? >>>> My interpretation is that the client reads the datastores list from >>>> and the list entries give you the identity of a separa= te >>>> datastore that gives you the content of the yang library for that >>>> datastore. (For each datastore, you have a separate datastore to >>>> report its yang library.) >>> Yes. The default value for yang-library-datastore leaf is >>> ds:operational (the only possible one for the ds:operational >>> datastore). This is backward compatible. If one needs different model >>> for 'running', etc. then a new datastore identity has to be defined >>> and set in place of the default value. Then this identity can be used >>> to read the yang-library data with . >> Ah, ok.=C2=A0 This is a clever solution, but quite complicated.=C2=A0 = It >> requires several round trips for a client to learn all library >> instances.=C2=A0 Also, w/o any changes, it is not clear which module-s= et-id >> is sent in the capability, The module-set-id sent in capabilities has to be the one for operational=20 since the client needs to get started by reading /datastores-state. >> and a client must query all module-set-ids >> in all (meta)datastores in order to just check if it has the latest >> version or not. Adding a /datastores-state/datastore/module-set-id leaf in operational=20 can resolve this problem. At the current point I think all issues raised are addressed with the=20 following model (notice the added anydata option which can replace the=20 use of yang-library-datastore and if implemented as an alternative can=20 make retrieval as a single tree): module: ietf-datastores =C2=A0=C2=A0=C2=A0 +--ro datastores-state =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module-set-id=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (model)? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(same-as-oper= ational) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(constrained-= to-operational) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro not= -implemented* [name revision] =C2=A0=C2=A0=C2=A0=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 -> /yanglib:m= odule-state/module/name =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0 -> /yanglib:module-state/module/r= evision =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstraine= d-datastore-instance) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro yan= g-library-datastore=C2=A0=C2=A0=C2=A0 identityref =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstraine= d-anydata) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--ro 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 =C2=A0 augment /yanglib:yang-library-change: =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref Vladimir >> =C2=A0 It is also not clear how the existing notification >> "yang-library-change" would work when there are multiple instances >> involved. > How about this? > module: ietf-datastores > ... > =C2=A0 augment /yanglib:yang-library-change: > =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref > > Vladimir >> =C2=A0=C2=A0 So I don't think that this solution will actually work w/= o >> an update to 7895 - but not updating 7895 was the whole reason for >> doing this. >> >> >> /martin >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Dec 13 00:31:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38812700F; Wed, 13 Dec 2017 00:31:45 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJQDRTHDedlb; Wed, 13 Dec 2017 00:31: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 ABEE4120726; Wed, 13 Dec 2017 00:31: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 554B54C6; Wed, 13 Dec 2017 09:31: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 OYAL1pQSCqi3; Wed, 13 Dec 2017 09:31:41 +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, 13 Dec 2017 09:31:41 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 412392012E; Wed, 13 Dec 2017 09:31: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 KXLy__gk6Is9; Wed, 13 Dec 2017 09:31:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94BF12012C; Wed, 13 Dec 2017 09:31:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 96A704196B76; Wed, 13 Dec 2017 09:29:39 +0100 (CET) Date: Wed, 13 Dec 2017 09:29:39 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Cc: Martin Bjorklund , Netconf , "netmod@ietf.org" Message-ID: <20171213082939.thmjs6zf4nfwtsrd@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Vladimir Vassilev , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171212.202001.1743562517319162368.mbj@tail-f.com> <1c97862a-9bc5-6101-6a79-3438573a9aca@transpacket.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: <1c97862a-9bc5-6101-6a79-3438573a9aca@transpacket.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 08:31:45 -0000 On Wed, Dec 13, 2017 at 08:50:33AM +0100, Vladimir Vassilev wrote: > > At the current point I think all issues raised are addressed with the > following model (notice the added anydata option which can replace the use > of yang-library-datastore and if implemented as an alternative can make > retrieval as a single tree): > > module: ietf-datastores > +--ro datastores-state > +--ro datastore* [name] > +--ro module-set-id string > +--ro (model)? > +--:(same-as-operational) > +--:(constrained-to-operational) > | +--ro not-implemented* [name revision] > | +--ro name -> /yanglib:module-state/module/name > | +--ro revision -> /yanglib:module-state/module/revision > +--:(unconstrained-datastore-instance) > | +--ro yang-library-datastore identityref > +--:(unconstrained-anydata) > +--ro yang-library? > > augment /yanglib:yang-library-change: > +---- datastore? identityref > It is (a) architecturally backwards to have ietf-datastores depend on ietf-yang-library and (b) the proposal does not solve the issue that you are silently changing the semantics of the definitions in the old ietf-yang-library. It remains unclear to me which problem this is approach solving, i.e., what the benfit is over the other proposals (since the semantics of ietf-yang-library change, it is _not_ backwards compatible). /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 Dec 13 00:56:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15792127869; Wed, 13 Dec 2017 00:56:38 -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 gwNzNZmbBDbA; Wed, 13 Dec 2017 00:56: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 C64E7120726; Wed, 13 Dec 2017 00:56:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id D745B1541B6D; Wed, 13 Dec 2017 09:56:31 +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 WSg18S3-XZdb; Wed, 13 Dec 2017 09:56:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4A82F1541B6A; Wed, 13 Dec 2017 09:56:31 +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 Vdby_2G2r6PH; Wed, 13 Dec 2017 09:56:31 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 241371541980; Wed, 13 Dec 2017 09:56:31 +0100 (CET) To: Martin Bjorklund Cc: netmod@ietf.org, netconf@ietf.org References: <20171212.202001.1743562517319162368.mbj@tail-f.com> <20171213.084030.1399882156946529918.mbj@tail-f.com> From: Vladimir Vassilev Message-ID: <5c71cddd-b091-223a-9d6f-2e338e7044ed@transpacket.com> Date: Wed, 13 Dec 2017 09:56:30 +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: <20171213.084030.1399882156946529918.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 08:56:38 -0000 On 12/13/2017 08:40 AM, Martin Bjorklund wrote: > Vladimir Vassilev wrote: >> On 12/12/2017 08:20 PM, Martin Bjorklund wrote: >> >>> Hi, >>> >>> Vladimir Vassilev wrote: >>>> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: >>>>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: >>>>>> Vladimir Vassilev wrote: >>>>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: >>>>>>> >>>>>>>> I don't think that this is really a good idea.=C2=A0 You would e= nd up >>>>>>>> returning server metadata in addition to the configuration. >>>>>>> Obviously RFC 7895 defines only config false; data and I was not >>>>>>> proposing a change to that. But I agree something has to be added= to >>>>>>> complete the solution. Special purpose datastore identities can b= e >>>>>>> defined that return instance of yang-library data when read with >>>>>>> . (Datastores with yang-library config false; only data= not >>>>>>> represented in 'operational') >>>>>>> >>>>>>> Adding this special yang-library-datastore to the proposed >>>>>>> ietf-datastores container e.g. >>>>>>> >>>>>>> module: ietf-datastores >>>>>>> +--ro datastores >>>>>>> |=C2=A0 +--ro datastore* [name] >>>>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>>>> >>>>>> I don't understand this proposal. How would a client learn the >>>>>> library for ? For ? >>>>> My interpretation is that the client reads the datastores list from >>>>> and the list entries give you the identity of a separ= ate >>>>> datastore that gives you the content of the yang library for that >>>>> datastore. (For each datastore, you have a separate datastore to >>>>> report its yang library.) >>>> Yes. The default value for yang-library-datastore leaf is >>>> ds:operational (the only possible one for the ds:operational >>>> datastore). This is backward compatible. If one needs different mode= l >>>> for 'running', etc. then a new datastore identity has to be defined >>>> and set in place of the default value. Then this identity can be use= d >>>> to read the yang-library data with . >>> Ah, ok. This is a clever solution, but quite complicated. It >>> requires several round trips for a client to learn all library >>> instances. Also, w/o any changes, it is not clear which module-set-i= d >>> is sent in the capability, and a client must query all module-set-ids >>> in all (meta)datastores in order to just check if it has the latest >>> version or not. It is also not clear how the existing notification >>> "yang-library-change" would work when there are multiple instances >>> involved. >> How about this? >> module: ietf-datastores >> ... >> =C2=A0 augment /yanglib:yang-library-change: >> =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref > This has the same issue as augementing a datastore leaf-list into the > current /modules-state/modules list would have - old clients won't > understand this new node. IMO it is different. Augmenting the data tree under /modules-state can=20 potentially compromise the bootstrap resolution of the model context=20 (depending on whether ignoring the data with unknown namespaces does=20 change the original model semantics). However I do not see any issue=20 with the case of the proposed augmentation to yang-library-change=20 notification. Correctly implemented client needs to read /modules-state=20 and make sure there are no unsupported modules,features etc. (e.g.=20 ietf-datastores is supported) before going further (e.g. subscribing to=20 notifications editing configuration etc.). > /martin From nobody Wed Dec 13 06:49:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FD2126C3D for ; Wed, 13 Dec 2017 06:48:59 -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 ED4KdGbGGp1y for ; Wed, 13 Dec 2017 06:48:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D3C32124B0A for ; Wed, 13 Dec 2017 06:48:57 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id A2CBD1AE02BD; Wed, 13 Dec 2017 15:48:56 +0100 (CET) Date: Wed, 13 Dec 2017 15:47:34 +0100 (CET) Message-Id: <20171213.154734.273404682004037071.mbj@tail-f.com> To: vladimir@transpacket.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> <975828fb-cd82-84fb-540b-58b8012872b5@transpacket.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] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 14:49:00 -0000 Hi, Thanks for reporting this. I'll add the missing origin. But why did you think forwarding and mtu should be removed? In fact, I think I missed , so here's my diff: --- ex-get-data-reply.xml +++ ex-get-data-reply.xml @@ -13,6 +13,7 @@ = + true false 1500
@@ -20,12 +21,13 @@ 24 static
- + 192.0.2.2 00:01:02:03:04:05 + true false 1280
/martin Vladimir Vassilev wrote: > Hello, > = > The previous post was intended for the rfc7223bis Last Call (wrong > subject line). > = > I just completed similar validation through a testcase for the > examples in rfc7277bis ("Appendix A.=A0 Example: NETCONF = > reply" and "Appendix B.=A0 Example: NETCONF Reply") > = > Here there are some inconsistencies between the output > and the expected output. A missing origin bug is probably > more significant then the rest. The following patch fixes the > inconsistencies and the testcase passes: > = > --- before.txt=A0=A0=A0 2017-12-12 20:39:09.037576425 +0100 > +++ after.txt=A0=A0=A0 2017-12-12 20:37:46.425656680 +0100 > @@ -7,14 +7,12 @@ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ianaift:ethernetCsmacd= > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 false > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1500 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 192.0.2.1 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 24 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 static= > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 192.0.2.2 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 00:01:02:03:04:05= > @@ -22,7 +20,6 @@ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 false > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1280 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2001:db8::10 > = > = > In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and > this is only a report of a detected issue. > = > Vladimir > = > On 12/11/2017 05:35 PM, Vladimir Vassilev wrote: > > Hello, > > > > I've reviewed this document and believe it is ready for publication= .= > > > > The focus of my review this time was on validating the module and t= he > > example modules and example data through running code. I implemente= d > > NMDA for the open source tools we use and added a testcase that > > reproduces the result specified in "Appendix E. Example: NETCONF > > Reply" after loading the configuration specified in > > "Appendix D.=A0 Example: NETCONF Reply" and providing = the > > config false; data and system originated configuration as needed. I= > > can confirm the implementation validated the example modules and th= e > > example data producing identical output. > > > > IMO the examples are demonstrating well the concept of NMDA and its= > > application for the ietf-interfaces module. > > > > I had an issue with a bug in ietf-netconf-datastores@2017-08-24.yan= g I > > had to fix in order to use the RPC. The bug is already > > reported on the mailing-list. > > > > diff ietf-patched/ietf-netconf-datastores@2017-08-24.yang > > ietf-draft/ietf-netconf-datastores@2017-08-24.yang > > 140c140 > > <=A0=A0=A0=A0=A0=A0=A0=A0 when 'derived-from-or-self(../datastore, = "ds:operational")'; > > --- > >> =A0=A0=A0=A0=A0=A0=A0 when 'derived-from-or-self(../datastore, "or= :operational")'; > > > > Vladimir > > > > > > On 11/28/2017 08:29 PM, Kent Watsen wrote: > >> All, > >> > >> This starts a two-week working group last call on > >> draft-ietf-netmod-rfc7277bis-00. > >> > >> Please recall that this update's intention is to > >> modify the YANG module to be in line with the NMDA > >> guidelines [1].=A0 Reviewing the diff between the two > >> drafts [2] should reveal just this. > >> > >> The working group last call ends on December 12. > >> 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. > >> > >> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > >> [2] > >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7277bis= -00.txt > >> > >> Thank you, > >> Netmod 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 Wed Dec 13 06:55:38 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8EE124B0A; Wed, 13 Dec 2017 06:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 tNW59Nyn6-4Y; Wed, 13 Dec 2017 06:55:33 -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 E052F120227; Wed, 13 Dec 2017 06:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25462; q=dns/txt; s=iport; t=1513176933; x=1514386533; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=7HWsKJt/TwllmdJwxpCCozLpL5ZC4WTNyLOvR5Jssf4=; b=XWJxjyojPAjlLMXJsEzXj8EbfK4pNIGd0tT1ZG3JbJKDPLsRkBez5Y4Q UGZgWSxWFDJ7Mlroz26Hqlq7rPstpGCn0IQmRUZwmeGdlqrk4NcwTH312 gdjxpCgAhM14pP1NreYKKVrJ/v/cxjrMZF9lPMsMKVHLU0CosC1RVZsa8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACtPjFa/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDD4EVdCeEAoohdJAOfpYTghUKGAEJhEpPAoVSGAEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEBAgEBASFLCxALGCAHAwICJx8RBg0GAgEBF4oFCBCoZYInJoo2A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYNgg2GBaSmCTDaDLgEYgSwUgyuCYwWSFIc?= =?us-ascii?q?+iU2He40sghZjiRokhzGNEIFWiACBOx85JYEpMhoIGxU6gikJghCCPEE3AQGKO?= =?us-ascii?q?AEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208,217";a="885961" 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; 13 Dec 2017 14:55:30 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBDEtU0j009264; Wed, 13 Dec 2017 14:55:30 GMT To: Andy Bierman Cc: Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> From: Robert Wilton Message-ID: <60876a73-3dec-9a4f-e313-1787b432fb34@cisco.com> Date: Wed, 13 Dec 2017 14:55:30 +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="------------829A8D330DE6ABA13763460A" Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 14:55:37 -0000 This is a multi-part message in MIME format. --------------829A8D330DE6ABA13763460A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/12/2017 20:55, Andy Bierman wrote: > > > On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton > wrote: > > Hi, > > > On 08/12/2017 18:01, Andy Bierman wrote: >> Hi, >> >> A library per datastore sounds too complicated. >> I prefer the proposal that was made at the IETF meeting that had >> a 'not-implemented-in' leaf-list and a single module list. > The use case that this particular design doesn't work particularly > well for is if you have a dynamic datastore that just contains a > few modules that are not supported via the conventional datastores. > > I think that there are future uses cases where the set of modules > used for a dynamic datastore could be really quite different and > separate from conventional configuration.  E.g. if dynamic > subscribers were managed through a dynamic configuration datastore > rather than RADIUS. > >> >> Why is it interesting to have a separate module list for regular >> modules and imported modules? > Several reasons: > 1) It means that the list of implemented modules have a single key > and hence any references to an implemented module are cleaner/simpler. > > > > IMO you are replacing universally meaningful keys  (module-name, > revision-date) with an arbitrary name, > It is not cleaner and not simpler for a client. No, for alternatives A and B, the list key is the module name itself, nor an arbitrary name. Alternative C uses an arbitrary name. > > > 2) The model structure naturally more strictly enforces that only > a single revision/version of a module is implemented. (E.g. it > prevents a server stating that two revisions of a module are both > implemented). > > > > How is that the case if the schema list includes its own module list? > You mean there is a "unique" statement in the outer list that insures > that a module/revision > shows up at most once in all instances of the inner module list? For alt A, each schema represents a single list (so no duplicated implemented modules are possible). For alt B, yes, the rule is that there must be no duplicates in the module-sets that are combined into a single schema. > > 3) I genuinely think that the list of implemented modules is more > interesting to the client than the imported, but not implemented > modules. > > > > The conformance leaf was good enough. > Duplicating the module list and removing the conformance leaf is > aggressively non-backward compatible. > > > For a server, I would design it to "implement" one revision of > every module that it uses (including those that don't contain any > data nodes, RPCs, actions, notifications, or deviations), and then > the "import-only" list becomes the list of modules that the server > implements to satisfy "import-by-revision" and these are stated in > the implemented schema anyway. > > >> I prefer to keep the conformance leaf and not change the module list. >> >> NMDA needs to be possible to implement with a single schema tree >> such that a module >> is implemented in all datastores, or a subset of all datastores.  >> Otherwise it probably won't >> get supported in clients. > All solutions accommodate this requirement. > > > > Seems to me all new solutions allow a server to violate the MUST in > the NMDA draft that > there is a superset of all modules.  A client has to look for every > module in a server-specific > set of named schema sets, and then reconcile all these sets. > I still prefer the single module list with a conformance leaf and a > leaf-list indicating > the supported (or unsupported) datastores. So, this is a trade off between a more expressive model vs a more constrained model. It is worth noting that the existing YANG library (RFC 7895) allows servers to produce illegal module lists because they could implement multiple revisions of the same module. Thanks, Rob > > > > For me, some of the interesting design questions have revolved around: > - is it better to reduce duplication in the list of modules > reported at the cost of increased model complexity? > - does the solution extend to schema mount? > - how well does the solution cope with with configuration > datastores that support very different sets of modules? > > To a lesser extent we have also been considering how well the > solution extends to packaging and semantic versioning, but I think > that it is quite tricky to know who these are going to pan out.  > E.g. I think that the restriction that a given schema will only > implement a single revision of a module will end up still holding, > but I'm not sure that everyone has that same view point. > > Thanks, > Rob > > > > > Andy > >> >> >> Andy >> >> >> >> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > wrote: >> >> CC-ing NETCONF, where the draft is being worked on. >> >> Kent >> >> >> On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: >> > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev >> wrote: >> > > >> > > Yes. The default value for yang-library-datastore leaf is >> ds:operational >> > > (the only possible one for the ds:operational datastore). >> This is backward >> > > compatible. If one needs different model for 'running', >> etc. then a new >> > > datastore identity has to be defined and set in place of >> the default value. >> > > Then this identity can be used to read the yang-library >> data with >> > > . >> > > >> > >> > Sorry, but I have to ask this: How do I obtain the schema >> for the >> > datastore (lets call it ) that reports the >> schema for >> > ? Is there another >> datastore? Will >> > the recursion end? Perhaps it does since >> >> > might have itself listed as the schema defining datastore. >> I guess >> > Lada will like these kind of meta and meta-meta datastores. >> >> Not really. Metadata needn't be in datastores. >> >> Lada >> >> > >> > /js >> > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > --------------829A8D330DE6ABA13763460A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/12/2017 20:55, Andy Bierman wrote:


On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,


On 08/12/2017 18:01, Andy Bierman wrote:
Hi,

A library per datastore sounds too complicated.
I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a single module list.
The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.  E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS.


Why is it interesting to have a separate module list for regular modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler.


IMO you are replacing universally meaningful keys  (module-name, revision-date) with an arbitrary name,
It is not cleaner and not simpler for a client.
No, for alternatives A and B, the list key is the module name itself, nor an arbitrary name.
Alternative C uses an arbitrary name.




2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.  (E.g. it prevents a server stating that two revisions of a module are both implemented).


How is that the case if the schema list includes its own module list?
You mean there is a "unique" statement in the outer list that insures that a module/revision
shows up at most once in all instances of the inner module list?
For alt A, each schema represents a single list (so no duplicated implemented modules are possible).

For alt B, yes, the rule is that there must be no duplicates in the module-sets that are combined into a single schema.



 
3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules.


The conformance leaf was good enough.
Duplicating the module list and removing the conformance leaf is aggressively non-backward compatible.

 

For a server, I would design it to "implement" one revision of every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the server implements to satisfy "import-by-revision" and these are stated in the implemented schema anyway.


I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such that a module
is implemented in all datastores, or a subset of all datastores.  Otherwise it probably won't
get supported in clients.
All solutions accommodate this requirement.


Seems to me all new solutions allow a server to violate the MUST in the NMDA draft that
there is a superset of all modules.  A client has to look for every module in a server-specific
set of named schema sets, and then reconcile all these sets.
I still prefer the single module list with a conformance leaf and a leaf-list indicating
the supported (or unsupported) datastores.
So, this is a trade off between a more expressive model vs a more constrained model.

It is worth noting that the existing YANG library (RFC 7895) allows servers to produce illegal module lists because they could implement multiple revisions of the same module.

Thanks,
Rob





For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores that support very different sets of modules?

To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out.  E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point.

Thanks,
Rob




Andy
 


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net> wrote:
CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:operational
> > (the only possible one for the ds:operational datastore). This is backward
> > compatible. If one needs different model for 'running', etc. then a new
> > datastore identity has to be defined  and set in place of the default value.
> > Then this identity can be used to read the yang-library data with
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the schema for
> <running>? Is there another <running-library-library> datastore? Will
> the recursion end? Perhaps it does since <running-library-library>
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=


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



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



--------------829A8D330DE6ABA13763460A-- From nobody Wed Dec 13 06:57:08 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F235127241 for ; Wed, 13 Dec 2017 06:57:07 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znHLO51iylsA for ; Wed, 13 Dec 2017 06:57:05 -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 6F7DD126C2F for ; Wed, 13 Dec 2017 06:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10544; q=dns/txt; s=iport; t=1513177025; x=1514386625; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=naczvbdnItTddnNLEDYr2iQ7mSvt3Jf3OfRFmUFllFY=; b=cw1BIRjcSKJdZH9nxsqp7UP2W6LFnJxVoHk92PLW4RqJFVWhu2JhcIZ+ B2ebLZqngIkvcxKYsI0FI8fO20cPt9BIb+xdAxHffwGhSbETKGiCfu/An +iW4RHDZFJ2OWwrrg0nL45OGGcX11NiAMy0dVqmTyFd/8DS/qVh7LGuFw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAQAlPzFa/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPBYFXkWqFTYIVChgBCoRJTwIahHk/GAEBAQE?= =?us-ascii?q?BAQEBAWsohSQCAQMBASEERwsQAgEIPwMCAgIlCxQRAgQBDQWJRGQQqGWBbTqKX?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg2CCC4NoC4J3gy4BgW2DFjGCMgWSFJE?= =?us-ascii?q?LApUlk2iTI4MWAhEZAYE6AR85gU5vFToqAYF+P4QWeIklgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208,217";a="330063781" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 14:57:04 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vBDEv3Wa017376 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 14:57:04 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, 13 Dec 2017 09:57:02 -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, 13 Dec 2017 09:57:02 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Eliot Lear , Mahesh Jethanandani , Kristian Larsson CC: "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwA= Date: Wed, 13 Dec 2017 14:57:02 +0000 Message-ID: <37FA28D8-6799-491C-94CB-04237766E4D3@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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.210.168] Content-Type: multipart/alternative; boundary="_000_37FA28D86799491C94CB04237766E4D3ciscocom_" 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, 13 Dec 2017 14:57:07 -0000 --_000_37FA28D86799491C94CB04237766E4D3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgaW50ZXJmYWNlOg0K DQogIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0KICAgICstLXJ3IGluZ3Jl c3MtYWNscw0KICAgIHwgICstLXJ3IGFjbC1zZXRzDQogICAgfCAgICAgKy0tcncgYWNsLXNldCog W25hbWVdDQogICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1s aXN0cy9hY2wvbmFtZQ0KICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+IC9h Y2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICB8ICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGljcyog W25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgIHwgICAgICAgICAgICstLXJvIG5hbWUgICAg ICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAgfCAgICAg ICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgfCAgICAg ICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQogICAgKy0tcncg ZWdyZXNzLWFjbHMNCiAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAgICAgICstLXJ3IGFjbC1z ZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgIC0+IC9hY2Nl c3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICAgICAgICArLS1ydyB0eXBlPyAgICAgICAgICAgICAt PiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgICAgICAgKy0tcm8gYWNlLXN0YXRpc3Rp Y3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAgICAgICAgICAgICArLS1ybyBuYW1l ICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQ0KICAgICAg ICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNvdW50ZXI2NA0KICAgICAg ICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNvdW50ZXI2NA0KDQpDb3Vs ZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBhYm92ZSBib3RoIHRoZXNlICYgcmVu YW1lIOKAnGluZ3Jlc3MtYWNscyIgdG8g4oCcaW5ncmVzc+KAnSwgZXRjLiB0byBnaXZlIGEgc2lu Z2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50YXRpb24gaWYgcHJlZmVycmVkLg0KDQpDaGVlcnMsDQoN CkVpbmFyDQoNCg0KT24gNiBEZWMgMjAxNywgYXQgMTk6NDMsIEVsaW90IExlYXIgPGxlYXJAY2lz Y28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gMTIvNi8xNyA3 OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0KSG93IGRvZXMgb25lIG1vdmUgdGhl IGludGVyZmFjZSBhdHRhY2htZW50IHBvaW50LCBjdXJyZW50bHkgYW4NCidpbnRlcmZhY2UtcmVm JywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZSBpZjppbnRlcmZhY2VzL2ludGVyZmFjZSwNCmlu c2lkZSBvZiB0aGUg4oCYYWNs4oCZICBjb250YWluZXI/IERvd24gdGhlIGxpbmUgd2UgbWlnaHQg bmVlZCB0byBoYXZlIGFuDQpjb250YWluZXIgZm9yICJhdHRhY2htZW50IHBvaW50cyIgdG8gYWNj b21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5IG9mDQphdHRhY2hpbmcgYW4gQUNMIGVpdGhlciB0byBh biBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uDQoNCg0KS2VlcGluZyBpbiBtaW5kIHRoYXQg b25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFjaCB0byBhbg0KaW50ZXJmYWNlIGF0 IGFsbC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K --_000_37FA28D86799491C94CB04237766E4D3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <17CF6F6DFFD1704394FBC781BD63E550@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClBlcmhhcHMgbGlrZSB0aGlzLCBhcyBhbiBhdWdt ZW50YXRpb24gdG8gdGhlIGludGVyZmFjZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5v bmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVy ZmFjZXMvaWY6aW50ZXJmYWNlOjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmIzQzOy0tcncgaW5ncmVzcy1hY2xzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW25hbWVd PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7LSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvbmFtZTwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1z dGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZTwvZm9udD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5 YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmIzQz Oy0tcncgZWdyZXNzLWFjbHM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBhY2wtc2V0czwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW25h bWVdPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvdHlwZTwvZm9udD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2Vz L2FjZS9uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLXBhY2tl dHM/ICZuYnNwOyB5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0t cm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q291bGQgYWxzbyBwdXQgYW4g4oCcYWNlc+KAnSBjb250YWlu ZXIgYWJvdmUgYm90aCB0aGVzZSAmYW1wOyByZW5hbWUg4oCcaW5ncmVzcy1hY2xzJnF1b3Q7IHRv IOKAnGluZ3Jlc3PigJ0sIGV0Yy4gdG8gZ2l2ZSBhIHNpbmdsZSByb290IGZvciB0aGUgYXVnbWVu dGF0aW9uIGlmIHByZWZlcnJlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDYg RGVjIDIwMTcsIGF0IDE5OjQzLCBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVhckBj aXNjby5jb20iIGNsYXNzPSIiPmxlYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMTIvNi8xNyA3OjIz IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhvdyBkb2VzIG9uZSBtb3ZlIHRoZSBpbnRlcmZhY2UgYXR0 YWNobWVudCBwb2ludCwgY3VycmVudGx5IGFuPGJyIGNsYXNzPSIiPg0KJ2ludGVyZmFjZS1yZWYn LCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlIGlmOmludGVyZmFjZXMvaW50ZXJmYWNlLDxiciBj bGFzcz0iIj4NCmluc2lkZSBvZiB0aGUg4oCYYWNs4oCZICZuYnNwO2NvbnRhaW5lcj8gRG93biB0 aGUgbGluZSB3ZSBtaWdodCBuZWVkIHRvIGhhdmUgYW48YnIgY2xhc3M9IiI+DQpjb250YWluZXIg Zm9yICZxdW90O2F0dGFjaG1lbnQgcG9pbnRzJnF1b3Q7IHRvIGFjY29tbW9kYXRlIHRoZSBwb3Nz aWJpbGl0eSBvZjxiciBjbGFzcz0iIj4NCmF0dGFjaGluZyBhbiBBQ0wgZWl0aGVyIHRvIGFuIGlu dGVyZmFjZSBvciDigJxnbG9iYWxseeKAnS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpLZWVwaW5nIGluIG1pbmQgdGhhdCBvbmUgdXNl IGlzIHRoYXQgYW4gQUNMIGRvZXNuJ3QgYXR0YWNoIHRvIGFuPGJyIGNsYXNzPSIiPg0KaW50ZXJm YWNlIGF0IGFsbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBj bGFzcz0iIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_37FA28D86799491C94CB04237766E4D3ciscocom_-- From nobody Wed Dec 13 07:00:36 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672B5126C3D for ; Wed, 13 Dec 2017 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 QUBW0s7bfgaf for ; Wed, 13 Dec 2017 07:00:30 -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 D9B17124B0A for ; Wed, 13 Dec 2017 07:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13816; q=dns/txt; s=iport; t=1513177230; x=1514386830; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=MY4r0JTJGpjG4rOOLU/WkAa7jlaWXYJEDjWAwsub3rY=; b=JW5m7msxjgFednTsH3hHotGud1bhiWw8vAZmfsw5VVCW23WnsflGdHXZ H26Ec9wc+MaG7vegVPfo7jK/C4iVi5j5h3fxXRIJfM4ih2JA2S242EGf/ x0vXg+G2w3qcSU4bMaHyZwSoLpyyutjDbY3NtpLav3KWU95TPYzY7Lfak M=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="asc'?scan'208,217";a="839148" 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; 13 Dec 2017 15:00:28 +0000 Received: from [10.61.83.169] (ams3-vpn-dhcp5034.cisco.com [10.61.83.169]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBDF0RlJ023268; Wed, 13 Dec 2017 15:00:27 GMT To: "Einar Nilsen-Nygaard (einarnn)" , Mahesh Jethanandani , Kristian Larsson Cc: "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> From: Eliot Lear Message-ID: Date: Wed, 13 Dec 2017 16:00:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="A3wKpPKuugt4Q2h8A5sM8Hp9mCglvGm85" 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, 13 Dec 2017 15:00:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A3wKpPKuugt4Q2h8A5sM8Hp9mCglvGm85 Content-Type: multipart/mixed; boundary="6eC9kK2rgoCB20QiSNEquEuWGRRVP5WlR"; protected-headers="v1" From: Eliot Lear To: "Einar Nilsen-Nygaard (einarnn)" , Mahesh Jethanandani , Kristian Larsson Cc: "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> In-Reply-To: <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> --6eC9kK2rgoCB20QiSNEquEuWGRRVP5WlR Content-Type: multipart/alternative; boundary="------------A1879C157E8A64230FA52284" Content-Language: en-US This is a multi-part message in MIME format. --------------A1879C157E8A64230FA52284 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBsaWtlIHRoaXMgYmVjYXVzZSBBQ0xzIHdpbGwgYmUgdXNlZCBpbiBtYW55IGRpZmZlcmVu dCB3YXlzLCBhbmQKZXhwZWN0aW5nIHRoYXQgYSBzaW5nbGUgbW9kZWwgYmUgYXVnbWVudGVk IGZvciBlYWNoIGF0dGFjaG1lbnQgc2VlbXMgYQpiaXQgdW5yZWFsaXN0aWMuCgpFbGlvdAoK T24gMTIvMTMvMTcgMzo1NyBQTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdy b3RlOgo+IFBlcmhhcHMgbGlrZSB0aGlzLCBhcyBhbiBhdWdtZW50YXRpb24gdG8gdGhlIGlu dGVyZmFjZToKPgo+ICAgICDCoCBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFj ZToKPiAgICAgwqAgwqAgKy0tcncgaW5ncmVzcy1hY2xzCj4gICAgIMKgIMKgIHwgwqArLS1y dyBhY2wtc2V0cwo+ICAgICDCoCDCoCB8IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+ ICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDC oC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUKPiAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCst LXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUK PiAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0g e2ludGVyZmFjZS1zdGF0c30/Cj4gICAgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8g bmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+ICAgICAvYWNjZXNzLWxpc3RzL2FjbC9h Y2VzL2FjZS9uYW1lCj4gICAgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbWF0Y2hl ZC1wYWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2NAo+ICAgICDCoCDCoCB8IMKgIMKgIMKgIMKg IMKgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4gICAgIMKg IMKgICstLXJ3IGVncmVzcy1hY2xzCj4gICAgIMKgIMKgIMKgIMKgKy0tcncgYWNsLXNldHMK PiAgICAgwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldCogW25hbWVdCj4gICAgIMKgIMKg IMKgIMKgIMKgIMKgIMKgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoC0+IC9hY2Nl c3MtbGlzdHMvYWNsL25hbWUKPiAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ydyB0eXBl PyDCoCDCoCDCoCDCoCDCoCDCoCAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4gICAgIMKg IMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJm YWNlLXN0YXRzfT8KPiAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbmFtZSDC oCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+ICAgICAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2Fj ZS9uYW1lCj4gICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtcGFj a2V0cz8gwqAgeWFuZzpjb3VudGVyNjQKPiAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Ky0tcm8gbWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPgo+Cj4gQ291bGQg YWxzbyBwdXQgYW4g4oCcYWNlc+KAnSBjb250YWluZXIgYWJvdmUgYm90aCB0aGVzZSAmIHJl bmFtZQo+IOKAnGluZ3Jlc3MtYWNscyIgdG8g4oCcaW5ncmVzc+KAnSwgZXRjLiB0byBnaXZl IGEgc2luZ2xlIHJvb3QgZm9yIHRoZQo+IGF1Z21lbnRhdGlvbiBpZiBwcmVmZXJyZWQuCj4K PiBDaGVlcnMsCj4KPiBFaW5hcgo+Cj4KPj4gT24gNiBEZWMgMjAxNywgYXQgMTk6NDMsIEVs aW90IExlYXIgPGxlYXJAY2lzY28uY29tCj4+IDxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3 cm90ZToKPj4KPj4KPj4KPj4gT24gMTIvNi8xNyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5k YW5pIHdyb3RlOgo+Pj4gSG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2ht ZW50IHBvaW50LCBjdXJyZW50bHkgYW4KPj4+ICdpbnRlcmZhY2UtcmVmJywgdG8gYW4gYXVn bWVudGF0aW9uIG9mIHRoZSBpZjppbnRlcmZhY2VzL2ludGVyZmFjZSwKPj4+IGluc2lkZSBv ZiB0aGUg4oCYYWNs4oCZIMKgY29udGFpbmVyPyBEb3duIHRoZSBsaW5lIHdlIG1pZ2h0IG5l ZWQgdG8gaGF2ZSBhbgo+Pj4gY29udGFpbmVyIGZvciAiYXR0YWNobWVudCBwb2ludHMiIHRv IGFjY29tbW9kYXRlIHRoZSBwb3NzaWJpbGl0eSBvZgo+Pj4gYXR0YWNoaW5nIGFuIEFDTCBl aXRoZXIgdG8gYW4gaW50ZXJmYWNlIG9yIOKAnGdsb2JhbGx54oCdLgo+Pj4KPj4KPj4gS2Vl cGluZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFj aCB0byBhbgo+PiBpbnRlcmZhY2UgYXQgYWxsLgo+Pgo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+ IG5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKPgoK --------------A1879C157E8A64230FA52284 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I like this because ACLs will be used in many different ways, and expecting that a single model be augmented for each attachment seems a bit unrealistic.

Eliot

On 12/13/17 3:57 PM, Einar Nilsen-Nygaard (einarnn) wrote:
Perhaps like this, as an augmentation to the interface:

=C2=A0 augmen= t /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 -> /acce= ss-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:counter64
=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 -> /acce= ss-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: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 th= e 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? Do= wn 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=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/listinfo/netmod


--------------A1879C157E8A64230FA52284-- --6eC9kK2rgoCB20QiSNEquEuWGRRVP5WlR-- --A3wKpPKuugt4Q2h8A5sM8Hp9mCglvGm85 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJaMUCLAAoJEIe2a0bZ0noz1xsH/j/YyINz2PdwET97fAZDAkor t5QtKnuOFL+nU6n1ZAjumTqviN18IWpdIQGjB/RUOwC2OPqnCgrMdLKnXtlpCk3x 85Tb0cE4mswuw4pjVu1vFj5F5qPhH64OwPd1X1mFNbIlC5xWe5GT4psA2wI7Gb+k Bb/pTbBqm9DOfDaOpBR8ZJUnLUcIiMqPne17Ghd/rrYIXRLFazDvpfUolhLpMowD PVZoYcELQRoPZMqaTUhBa7WfZo9+SuUkOTk6LvM3PbttD/OTnrGdmToxf4psySA4 Axoyk2MHC4p4aPLkUIhAeVJpWGTkEfID9r+DPhZNtHZH/iYTKPX5rPuOP2oGsNg= =L8NV -----END PGP SIGNATURE----- --A3wKpPKuugt4Q2h8A5sM8Hp9mCglvGm85-- From nobody Wed Dec 13 07:26:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0940126CF6 for ; Wed, 13 Dec 2017 07:26:53 -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 wZM0Ugd_YC9u for ; Wed, 13 Dec 2017 07:26:50 -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 6528B12422F for ; Wed, 13 Dec 2017 07:26:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9D7F61541BFD; Wed, 13 Dec 2017 16:26:48 +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 I2QsC7L138tB; Wed, 13 Dec 2017 16:26:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 714871541BFC; Wed, 13 Dec 2017 16:26:48 +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 hmmr7mfiaZJi; Wed, 13 Dec 2017 16:26:48 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 46A1C1541BF9; Wed, 13 Dec 2017 16:26:48 +0100 (CET) To: Martin Bjorklund Cc: kwatsen@juniper.net, netmod@ietf.org References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> <975828fb-cd82-84fb-540b-58b8012872b5@transpacket.com> <20171213.154734.273404682004037071.mbj@tail-f.com> From: Vladimir Vassilev Message-ID: <500e497e-9a80-8d00-22ca-6fe271fcd725@transpacket.com> Date: Wed, 13 Dec 2017 16:26:48 +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: <20171213.154734.273404682004037071.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 15:26:54 -0000 Hi, On 12/13/2017 03:47 PM, Martin Bjorklund wrote: > Hi, > > Thanks for reporting this. I'll add the missing origin. But why did > you think forwarding and mtu should be removed? 1. IMO since is not present in the container in the=20 Appendix A () example and does not have default value in the=20 model I still think it should be removed. > In fact, I think I > missed , 2. IMO both fixes adding or removing should be OK=20 depending on the RFC6243 defined with-defaults capability 'basic-mode'=20 parameter advertised by the server. I was running the example with=20 basic-mode=3Dexplicit Vladimir > so here's my diff: > > --- ex-get-data-reply.xml > +++ ex-get-data-reply.xml > @@ -13,6 +13,7 @@ > > =20 > > + true > false > 1500 >
> @@ -20,12 +21,13 @@ > 24 > static >
> - > + > 192.0.2.2 > 00:01:02:03:04:05 > > > > + true > false > 1280 >
> > > > /martin > > > > Vladimir Vassilev wrote: >> Hello, >> >> The previous post was intended for the rfc7223bis Last Call (wrong >> subject line). >> >> I just completed similar validation through a testcase for the >> examples in rfc7277bis ("Appendix A.=C2=A0 Example: NETCONF >> reply" and "Appendix B.=C2=A0 Example: NETCONF Reply") >> >> Here there are some inconsistencies between the output >> and the expected output. A missing origin bug is probably >> more significant then the rest. The following patch fixes the >> inconsistencies and the testcase passes: >> >> --- before.txt=C2=A0=C2=A0=C2=A0 2017-12-12 20:39:09.037576425 +0100 >> +++ after.txt=C2=A0=C2=A0=C2=A0 2017-12-12 20:37:46.425656680 +0100 >> @@ -7,14 +7,12 @@ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ianaift:ethernetCsmacd >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 false >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 1500 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 192.0.2.1 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 24 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 static >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0
>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 192.0.2.2 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:01:02:03:04:05 >> @@ -22,7 +20,6 @@ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 false >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 1280 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 2001:db8::10 >> >> >> In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and >> this is only a report of a detected issue. >> >> Vladimir >> >> On 12/11/2017 05:35 PM, Vladimir Vassilev wrote: >>> Hello, >>> >>> I've reviewed this document and believe it is ready for publication. >>> >>> The focus of my review this time was on validating the module and the >>> example modules and example data through running code. I implemented >>> NMDA for the open source tools we use and added a testcase that >>> reproduces the result specified in "Appendix E. Example: NETCONF >>> Reply" after loading the configuration specified in >>> "Appendix D.=C2=A0 Example: NETCONF Reply" and providing= the >>> config false; data and system originated configuration as needed. I >>> can confirm the implementation validated the example modules and the >>> example data producing identical output. >>> >>> IMO the examples are demonstrating well the concept of NMDA and its >>> application for the ietf-interfaces module. >>> >>> I had an issue with a bug in ietf-netconf-datastores@2017-08-24.yang = I >>> had to fix in order to use the RPC. The bug is already >>> reported on the mailing-list. >>> >>> diff ietf-patched/ietf-netconf-datastores@2017-08-24.yang >>> ietf-draft/ietf-netconf-datastores@2017-08-24.yang >>> 140c140 >>> <=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when 'derived-from-= or-self(../datastore, "ds:operational")'; >>> --- >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when 'derived-from-or-se= lf(../datastore, "or:operational")'; >>> Vladimir >>> >>> >>> On 11/28/2017 08:29 PM, Kent Watsen wrote: >>>> All, >>>> >>>> This starts a two-week working group last call on >>>> draft-ietf-netmod-rfc7277bis-00. >>>> >>>> Please recall that this update's intention is to >>>> modify the YANG module to be in line with the NMDA >>>> guidelines [1].=C2=A0 Reviewing the diff between the two >>>> drafts [2] should reveal just this. >>>> >>>> The working group last call ends on December 12. >>>> 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. >>>> >>>> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 >>>> [2] >>>> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7277bis-0= 0.txt >>>> >>>> Thank you, >>>> Netmod 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 Wed Dec 13 08:00:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F26C1288B8 for ; Wed, 13 Dec 2017 08:00: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 WaDI9ntwmfzq for ; Wed, 13 Dec 2017 08:00: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 B8E13128B44 for ; Wed, 13 Dec 2017 08:00:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5C82D1541C09; Wed, 13 Dec 2017 17:00:06 +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 ntlsrmU_ffGe; Wed, 13 Dec 2017 17:00:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 359CE1541C06; Wed, 13 Dec 2017 17:00:06 +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 xOCcpfqq19-O; Wed, 13 Dec 2017 17:00:06 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 0F2B21541C05; Wed, 13 Dec 2017 17:00:05 +0100 (CET) From: Vladimir Vassilev To: Martin Bjorklund Cc: netmod@ietf.org References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> <975828fb-cd82-84fb-540b-58b8012872b5@transpacket.com> <20171213.154734.273404682004037071.mbj@tail-f.com> <500e497e-9a80-8d00-22ca-6fe271fcd725@transpacket.com> Message-ID: <937fadab-b3f0-1246-8543-00cb4d6a5acd@transpacket.com> Date: Wed, 13 Dec 2017 17:00:05 +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: <500e497e-9a80-8d00-22ca-6fe271fcd725@transpacket.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Dec 2017 16:00:11 -0000 On 12/13/2017 04:26 PM, Vladimir Vassilev wrote: > Hi, > > On 12/13/2017 03:47 PM, Martin Bjorklund wrote: > >> Hi, >> >> Thanks for reporting this.=C2=A0 I'll add the missing origin.=C2=A0 Bu= t why did >> you think forwarding and mtu should be removed? > 1. IMO since is not present in the container in the=20 > Appendix A () example and does not have default value in=20 > the model I still think it should be removed. Alternatively the ipv4/mtu node can be a good example of a=20 origin=3D"or:system" configuration. >> =C2=A0=C2=A0 In fact, I think I >> missed , > 2. IMO both fixes adding or removing should be=20 > OK depending on the RFC6243 defined with-defaults capability=20 > 'basic-mode' parameter advertised by the server. I was running the=20 > example with basic-mode=3Dexplicit > > Vladimir > >> =C2=A0 so here's my diff: >> >> --- ex-get-data-reply.xml >> +++ ex-get-data-reply.xml >> @@ -13,6 +13,7 @@ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 true<= /enabled> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 false >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1500 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> @@ -20,12 +21,13 @@ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 24 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 static >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 192.0.2.2 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 00:01:02:03:04:05 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 true<= /enabled> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 false >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1280 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> >> >> >> /martin >> >> >> >> Vladimir Vassilev wrote: >>> Hello, >>> >>> The previous post was intended for the rfc7223bis Last Call (wrong >>> subject line). >>> >>> I just completed similar validation through a testcase for the >>> examples in rfc7277bis ("Appendix A.=C2=A0 Example: NETCONF >>> reply" and "Appendix B.=C2=A0 Example: NETCONF Reply") >>> >>> Here there are some inconsistencies between the output >>> and the expected output. A missing origin bug is probably >>> more significant then the rest. The following patch fixes the >>> inconsistencies and the testcase passes: >>> >>> --- before.txt=C2=A0=C2=A0=C2=A0 2017-12-12 20:39:09.037576425 +0100 >>> +++ after.txt=C2=A0=C2=A0=C2=A0 2017-12-12 20:37:46.425656680 +0100 >>> @@ -7,14 +7,12 @@ >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ianaift:ethernetCsmacd >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 false >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 1500 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 192.0.2.1 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 24 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 static >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0
>>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >>> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 192.0.2.2 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00:01:02:03:04:05 >>> @@ -22,7 +20,6 @@ >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >>> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 false >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 1280 >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 2001:db8::10 >>> >>> >>> In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and >>> this is only a report of a detected issue. >>> >>> Vladimir >>> >>> On 12/11/2017 05:35 PM, Vladimir Vassilev wrote: >>>> Hello, >>>> >>>> I've reviewed this document and believe it is ready for publication. >>>> >>>> The focus of my review this time was on validating the module and th= e >>>> example modules and example data through running code. I implemented >>>> NMDA for the open source tools we use and added a testcase that >>>> reproduces the result specified in "Appendix E. Example: NETCONF >>>> Reply" after loading the configuration specified in >>>> "Appendix D.=C2=A0 Example: NETCONF Reply" and providin= g the >>>> config false; data and system originated configuration as needed. I >>>> can confirm the implementation validated the example modules and the >>>> example data producing identical output. >>>> >>>> IMO the examples are demonstrating well the concept of NMDA and its >>>> application for the ietf-interfaces module. >>>> >>>> I had an issue with a bug in ietf-netconf-datastores@2017-08-24.yang= I >>>> had to fix in order to use the RPC. The bug is already >>>> reported on the mailing-list. >>>> >>>> diff ietf-patched/ietf-netconf-datastores@2017-08-24.yang >>>> ietf-draft/ietf-netconf-datastores@2017-08-24.yang >>>> 140c140 >>>> <=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when 'derived-from= -or-self(../datastore, "ds:operational")'; >>>> --- >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when 'derived-from= -or-self(../datastore, "or:operational")'; >>>> Vladimir >>>> >>>> >>>> On 11/28/2017 08:29 PM, Kent Watsen wrote: >>>>> All, >>>>> >>>>> This starts a two-week working group last call on >>>>> draft-ietf-netmod-rfc7277bis-00. >>>>> >>>>> Please recall that this update's intention is to >>>>> modify the YANG module to be in line with the NMDA >>>>> guidelines [1].=C2=A0 Reviewing the diff between the two >>>>> drafts [2] should reveal just this. >>>>> >>>>> The working group last call ends on December 12. >>>>> 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. >>>>> >>>>> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 >>>>> [2] >>>>> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7277bis-= 00.txt=20 >>>>> >>>>> >>>>> Thank you, >>>>> Netmod 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Dec 13 12:10:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6184A1242F5 for ; Wed, 13 Dec 2017 12:10:46 -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 DagcyYk_NhPV for ; Wed, 13 Dec 2017 12:10:44 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 093A1126D45 for ; Wed, 13 Dec 2017 12:10:38 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id f12so1787685pgo.5 for ; Wed, 13 Dec 2017 12:10: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:message-id:references :to; bh=lvS8t/dBPegemMp2GyLMqqwQhX+7SnibNBrMa/IdDk4=; b=RLPgUdrAIiNR2ojykPG8jhxArpJOKIzQez8vxM+I5HNlvfI4iuKt0l/lrLhSBJDAYJ hUsCJcjBdBmcOoKZ3kO11yJRVxNFa3zK7JirgC+2S+oLDHzOd27wbwe5taWstl534smt N52lApg7dImLBwFd/UGs3qCLfbwOr4ZUta1NtrmEACiW2YJgPzhrAwkBGSQrWBxNDdLS NnxTZAfyPcBubOzgd83iBoWPYSm8GtqHWRv7bgXoxxps3LKvwT2OwwkmcyTGZdNmiAer rC7MQCuhM+WTbhW0ztsNwRqVe6F2qAlfevsZO8p1j1pJzTSR9bhxB8rMQz3AaZ/7C2Tt J5iw== 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 :message-id:references:to; bh=lvS8t/dBPegemMp2GyLMqqwQhX+7SnibNBrMa/IdDk4=; b=Su98lngEd12LlFBd7J/Th15lTrQr/tW9shvSQLRXo9Nz2cNI3sqsiqGsC/62U+4YTW 6qNLRYlugLt1e6eH9qovZ1OWJPMuGPgaCMlhcEUZXB64usriRxQVA7/nAJvotBr/4ES+ 6YhUVhbfwJ8v+ao92oA/NN/jOvx612ozFtGq/Dis671P504ypJ2mBPJ/GQrNzbU3EC0V TjF+N8LWr6D+3mQCDSLaGJskurNvttoYIAJioEXdFQpBrwoWhyOLoJGfKTD5icTEB/JF kzNNVPG40LByCnmhm2f3HtfxHilYoR8+htZ0Zb1WzJgQiPWf7+Q1zz0M/ELYLK04apJ7 2Bkg== X-Gm-Message-State: AKGB3mJfuiXqDiE91lqSthH5f/9CYjrwOiMVONIoYXfDdQ2IHijVxrPu x279HAKi4A9IZzihfEqdetCsak2+ X-Google-Smtp-Source: ACJfBosXH7Zoylvce5dErRSMjdn+TraPlwQeAQEMNkqLQvs66ZHfuDFUwgINPj0zTJuhjKiWih3uqw== X-Received: by 10.98.99.68 with SMTP id x65mr7240909pfb.56.1513195837491; Wed, 13 Dec 2017 12:10:37 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:4c65:acaa:7a67:d727]) by smtp.gmail.com with ESMTPSA id q24sm3932592pgv.27.2017.12.13.12.10.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Dec 2017 12:10:36 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3DA56E60-25E8-415D-B1C1-21108DBBEE13" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> Date: Wed, 13 Dec 2017 12:10:35 -0800 Cc: Eliot Lear , Kristian Larsson , "netmod@ietf.org" Message-Id: <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.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> To: "Einar Nilsen-Nygaard (einarnn)" X-Mailer: Apple Mail (2.3124) 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, 13 Dec 2017 20:10:46 -0000 --Apple-Mail=_3DA56E60-25E8-415D-B1C1-21108DBBEE13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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) = 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 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3DA56E60-25E8-415D-B1C1-21108DBBEE13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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

= --Apple-Mail=_3DA56E60-25E8-415D-B1C1-21108DBBEE13-- From nobody Wed Dec 13 12:25:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1742A126FDC for ; Wed, 13 Dec 2017 12:25:12 -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, 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 q5AHZrourzdy for ; Wed, 13 Dec 2017 12:25:09 -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 B1277128BBB for ; Wed, 13 Dec 2017 12:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21160; q=dns/txt; s=iport; t=1513196704; x=1514406304; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zONPRKzM+Kb/NnEPUmhRYS+gaAK328GpsiBj0u/XA9M=; b=Ru6XAFAZL2S+wxgdAMBKI8co80YTDeAnLMzRhyojGAbhJyXMOOJG5bUY vsbiKA620Qk2wz2aBPzCf62XTR7ZgejV6W2ovXxMGpiDyNC2aP/tc+Q7+ IyCqo5+ETijGj8db1dYLy7cQsnNxNqc+FO/0pQOuf2WUj6DGbxy5/6Yq2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAAC4izFa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPBoFXiR6ITIVNghUKGAEKhElPAhqEeT8YAQE?= =?us-ascii?q?BAQEBAQEBayiFJAIEAQEhBEcLEAIBCA4xAwICAh8GCxQRAgQOBYlETAMVEKhng?= =?us-ascii?q?W06hzoNgxsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNggguDaAuCd4JqRAGBbYM?= =?us-ascii?q?WMYIyBZIUkE49ApAohH2TaI1NhVaDFgIRGQGBOgEfOYFObxU6KgGBfj+EF3iJF?= =?us-ascii?q?4EVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208,217";a="114122583" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 20:25:03 +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 vBDKP3R5030803 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 20:25:03 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Dec 2017 15:25:02 -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, 13 Dec 2017 15:25:02 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani CC: Eliot Lear , Kristian Larsson , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAABBMA Date: Wed, 13 Dec 2017 20:25:02 +0000 Message-ID: <42A2F0C4-52FD-4894-8D08-092BB2B0772B@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> In-Reply-To: <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.210.168] Content-Type: multipart/alternative; boundary="_000_42A2F0C452FD48948D08092BB2B0772Bciscocom_" 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, 13 Dec 2017 20:25:12 -0000 --_000_42A2F0C452FD48948D08092BB2B0772Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaGFwcHkgdG8gaGF2ZSBhIHdheSB0byBhdHRhY2ggYW4gQUNMIGdsb2JhbGx5LCBidXQg dGhhdOKAmXMgb3J0aG9nb25hbCB0byBhdHRhY2hpbmcgdG8gYW4gaW50ZXJmYWNlLCBpc27igJl0 IGl0PyBBdHRhY2hpbmcgQUNMcyBkaXJlY3RseSB0byBhbiBpbnRlcmZhY2UgZG9lc27igJl0IHBy ZWNsdWRlIGdsb2JhbCBhdHRhY2htZW50IGluIGFueSB3YXkgYXMgZmFyIGFzIEkgY2FuIHNlZeKA pm9yIGhhdmUgSSBtaXNzZWQgc29tZXRoaW5nPyBJ4oCZbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQg d2h5IGNob2ljZXMgYXJlIGFuIGlzc3VlLiBUaGUgY3VycmVudCBwcm9wb3NhbCBoYXMgdGhpcyBj b250YWluZXI6DQoNCm1vZHVsZTogaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0DQogICAgKy0tcncg YWNjZXNzLWxpc3RzDQogICAgICAgKy0tcncgYXR0YWNobWVudC1wb2ludHMNCiAgICAgICAgICAr LS1ydyBpbnRlcmZhY2UqIFtpbnRlcmZhY2UtaWRdIHtpbnRlcmZhY2UtYXR0YWNobWVudH0/DQog ICAgICAgICAgICAgKy0tcncgaW50ZXJmYWNlLWlkICAgIGlmOmludGVyZmFjZS1yZWYNCiAgICAg ICAgICAgICArLS1ydyBpbmdyZXNzDQogICAgICAgICAgICAgfCAgKy0tcncgYWNsLXNldHMNCiAg ICAgICAgICAgICB8ICAgICArLS1ydyBhY2wtc2V0KiBbbmFtZV0NCiAgICAgICAgICAgICB8ICAg ICAgICArLS1ydyBuYW1lICAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC9uYW1lDQogICAgICAg ICAgICAgfCAgICAgICAgKy0tcncgdHlwZT8gICAtPiAuLi8uLi8uLi8uLi8uLi8uLi9hY2wvdHlw ZQ0KICAgICAgICAgICAgIHwgICAgICAgICstLXJvIGFjZSogW25hbWVdIHtpbnRlcmZhY2Utc3Rh dHMgb3IgaW50ZXJmYWNlLWFjbC1hZ2dyZWdhdGV9Pw0KICAgICAgICAgICAgIHwgICAgICAgICAg ICstLXJvIG5hbWUgICAgICAgICAgICAgICAtPiAuLi8uLi8uLi8uLi8uLi8uLi8uLi9hY2wvYWNl cy9hY2UvbmFtZQ0KICAgICAgICAgICAgIHwgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0 cz8gICB5YW5nOmNvdW50ZXI2NA0KICAgICAgICAgICAgIHwgICAgICAgICAgICstLXJvIG1hdGNo ZWQtb2N0ZXRzPyAgICB5YW5nOmNvdW50ZXI2NA0KICAgICAgICAgICAgICstLXJ3IGVncmVzcw0K ICAgICAgICAgICAgICAgICstLXJ3IGFjbC1zZXRzDQogICAgICAgICAgICAgICAgICAgKy0tcncg YWNsLXNldCogW25hbWVdDQogICAgICAgICAgICAgICAgICAgICAgKy0tcncgbmFtZSAgICAtPiAu Li8uLi8uLi8uLi8uLi8uLi9hY2wvbmFtZQ0KICAgICAgICAgICAgICAgICAgICAgICstLXJ3IHR5 cGU/ICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vYWNsL3R5cGUNCiAgICAgICAgICAgICAgICAgICAg ICArLS1ybyBhY2UqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzIG9yIGludGVyZmFjZS1hY2wtYWdn cmVnYXRlfT8NCiAgICAgICAgICAgICAgICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAg ICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vLi4vYWNsL2FjZXMvYWNlL25hbWUNCiAgICAgICAgICAg ICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAg ICAgICAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3Vu dGVyNjQNCg0KSWYgd2UgYWRkZWQgc29tZSBmb3JtIG9mIGdsb2JhbCBhdHRhY2htZW50IHBvaW50 cywgdGhhdCBtaWdodCBiZSBhIHBlZXIgd2l0aCB0aGUgbGlzdCBvZiBpbnRlcmZhY2UgYXR0YWNo bWVudHMsIHJpZ2h0PyBCZWNhdXNlIHdl4oCZZCBuZWVkIHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCd IGFuZCBtdWx0aXBsZSDigJxpbnRlcmZhY2XigJ0gYXR0YWNobWVudHMuIEl04oCZcyBub3QgYW4g 4oCcb3LigJ0sIGl04oCZcyBhbiDigJxhbmTigJ0uIE9yIGhhdmUgSSBtaXNzZWQgc29tZXRoaW5n Pw0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCk9uIDEzIERlYyAyMDE3LCBhdCAyMDoxMCwgTWFoZXNo IEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCldlIHdhbnQgdG8gc3VwcG9ydCDigJxnbG9iYWzigJ0g YXR0YWNobWVudCBwb2ludCBkb3duIHRoZSBsaW5lLCBhbmQgdGhhdCDigJxnbG9iYWzigJ0gYXR0 YWNobWVudCBwb2ludCB3aWxsIGJlIG9uZSBvZiB0aGUgY2hvaWNlcyAodGhlIG90aGVyIGJlaW5n IHRoZSBpbnRlcmZhY2UpLCB3aGF0IHdvdWxkIHRoaXMgYXVnbWVudCBsb29rIGxpa2UuIE5vdGUs IGFzIGZhciBhcyBJIGtub3csIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUgYSBjaG9pY2Ugbm9k ZS4NCg0KT24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAo ZWluYXJubikgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdy b3RlOg0KDQpQZXJoYXBzIGxpa2UgdGhpcywgYXMgYW4gYXVnbWVudGF0aW9uIHRvIHRoZSBpbnRl cmZhY2U6DQoNCiAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6DQogICAgKy0t cncgaW5ncmVzcy1hY2xzDQogICAgfCAgKy0tcncgYWNsLXNldHMNCiAgICB8ICAgICArLS1ydyBh Y2wtc2V0KiBbbmFtZV0NCiAgICB8ICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAtPiAv YWNjZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgfCAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAg ICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgIHwgICAgICAgICstLXJvIGFjZS1zdGF0 aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgfCAgICAgICAgICAgKy0tcm8g bmFtZSAgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUNCiAg ICB8ICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAg ICB8ICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCiAg ICArLS1ydyBlZ3Jlc3MtYWNscw0KICAgICAgICstLXJ3IGFjbC1zZXRzDQogICAgICAgICAgKy0t cncgYWNsLXNldCogW25hbWVdDQogICAgICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAg LT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgICAgICAgICAgICstLXJ3IHR5cGU/ICAgICAg ICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICAgICAgICAgICArLS1ybyBhY2Ut c3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgICAgICAgICAgICAgICst LXJvIG5hbWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1l DQogICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0 DQogICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0 DQoNCkNvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFpbmVyIGFib3ZlIGJvdGggdGhl c2UgJiByZW5hbWUg4oCcaW5ncmVzcy1hY2xzIiB0byDigJxpbmdyZXNz4oCdLCBldGMuIHRvIGdp dmUgYSBzaW5nbGUgcm9vdCBmb3IgdGhlIGF1Z21lbnRhdGlvbiBpZiBwcmVmZXJyZWQuDQoNCkNo ZWVycywNCg0KRWluYXINCg0KDQpPbiA2IERlYyAyMDE3LCBhdCAxOTo0MywgRWxpb3QgTGVhciA8 bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KDQpPbiAx Mi82LzE3IDc6MjMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6DQpIb3cgZG9lcyBvbmUg bW92ZSB0aGUgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsIGN1cnJlbnRseSBhbg0KJ2ludGVy ZmFjZS1yZWYnLCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlIGlmOmludGVyZmFjZXMvaW50ZXJm YWNlLA0KaW5zaWRlIG9mIHRoZSDigJhhY2zigJkgIGNvbnRhaW5lcj8gRG93biB0aGUgbGluZSB3 ZSBtaWdodCBuZWVkIHRvIGhhdmUgYW4NCmNvbnRhaW5lciBmb3IgImF0dGFjaG1lbnQgcG9pbnRz IiB0byBhY2NvbW1vZGF0ZSB0aGUgcG9zc2liaWxpdHkgb2YNCmF0dGFjaGluZyBhbiBBQ0wgZWl0 aGVyIHRvIGFuIGludGVyZmFjZSBvciDigJxnbG9iYWxseeKAnS4NCg0KDQpLZWVwaW5nIGluIG1p bmQgdGhhdCBvbmUgdXNlIGlzIHRoYXQgYW4gQUNMIGRvZXNuJ3QgYXR0YWNoIHRvIGFuDQppbnRl cmZhY2UgYXQgYWxsLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQo= --_000_42A2F0C452FD48948D08092BB2B0772Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8CA81806B7477146A974CF5D8B88B205@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCknigJltIGhhcHB5IHRvIGhhdmUgYSB3YXkgdG8g YXR0YWNoIGFuIEFDTCBnbG9iYWxseSwgYnV0IHRoYXTigJlzIG9ydGhvZ29uYWwgdG8gYXR0YWNo aW5nIHRvIGFuIGludGVyZmFjZSwgaXNu4oCZdCBpdD8gQXR0YWNoaW5nIEFDTHMgZGlyZWN0bHkg dG8gYW4gaW50ZXJmYWNlIGRvZXNu4oCZdCBwcmVjbHVkZSBnbG9iYWwgYXR0YWNobWVudCBpbiBh bnkgd2F5IGFzIGZhciBhcyBJIGNhbiBzZWXigKZvciBoYXZlIEkgbWlzc2VkIHNvbWV0aGluZz8g SeKAmW0gbm90IHN1cmUNCiBJIHVuZGVyc3RhbmQgd2h5IGNob2ljZXMgYXJlIGFuIGlzc3VlLiBU aGUgY3VycmVudCBwcm9wb3NhbCBoYXMgdGhpcyBjb250YWluZXI6DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg ZmFjZT0iQ291cmllciIgY2xhc3M9IiI+bW9kdWxlOiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2Nlc3MtbGlzdHM8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYXR0YWNobWVudC1w b2ludHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYj NDM7LS1ydyBpbnRlcmZhY2UqIFtpbnRlcmZhY2UtaWRdIHtpbnRlcmZhY2UtYXR0YWNobWVudH0/ PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JiM0MzstLXJ3IGludGVyZmFjZS1pZCAmbmJzcDsgJm5ic3A7aWY6aW50ZXJmYWNlLXJl ZjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyYjNDM7LS1ydyBpbmdyZXNzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgYWNsLXNldHM8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOy0mZ3Q7 IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC9uYW1lPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7IC0mZ3Q7IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC90 eXBlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlKiBbbmFt ZV0ge2ludGVyZmFjZS1zdGF0cyBvciBpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZX0/PGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAuLi8uLi8uLi8u Li8uLi8uLi8uLi9hY2wvYWNlcy9hY2UvbmFtZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3Vu dGVyNjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJv IG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8YnIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0t cncgZWdyZXNzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldHM8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7LSZndDsgLi4vLi4vLi4v Li4vLi4vLi4vYWNsL25hbWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyB0eXBlPyAmbmJzcDsgLSZndDsgLi4vLi4vLi4vLi4vLi4vLi4vYWNsL3R5cGU8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBhY2UqIFtuYW1lXSB7aW50ZXJm YWNlLXN0YXRzIG9yIGludGVyZmFjZS1hY2wtYWdncmVnYXRlfT88YnIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgLi4vLi4vLi4vLi4vLi4v Li4vLi4vYWNsL2FjZXMvYWNlL25hbWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3Vu dGVyNjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDxiciBjbGFz cz0iIj4NCjwvZm9udD48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgd2Ug YWRkZWQgc29tZSBmb3JtIG9mIGdsb2JhbCBhdHRhY2htZW50IHBvaW50cywgdGhhdCBtaWdodCBi ZSBhIHBlZXIgd2l0aCB0aGUgbGlzdCBvZiBpbnRlcmZhY2UgYXR0YWNobWVudHMsIHJpZ2h0PyBC ZWNhdXNlIHdl4oCZZCBuZWVkIHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGFuZCBtdWx0aXBsZSDi gJxpbnRlcmZhY2XigJ0gYXR0YWNobWVudHMuIEl04oCZcyBub3QgYW4g4oCcb3LigJ0sIGl04oCZ cyBhbiDigJxhbmTigJ0uIE9yIGhhdmUgSSBtaXNzZWQNCiBzb21ldGhpbmc/PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPk9uIDEzIERlYyAyMDE3LCBhdCAyMDoxMCwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFu YW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KV2Ugd2FudCB0byBzdXBwb3J0IOKA nGdsb2JhbOKAnSBhdHRhY2htZW50IHBvaW50IGRvd24gdGhlIGxpbmUsIGFuZCB0aGF0IOKAnGds b2JhbOKAnSBhdHRhY2htZW50IHBvaW50IHdpbGwgYmUgb25lIG9mIHRoZSBjaG9pY2VzICh0aGUg b3RoZXIgYmVpbmcgdGhlIGludGVyZmFjZSksIHdoYXQgd291bGQgdGhpcyBhdWdtZW50IGxvb2sg bGlrZS4gTm90ZSwgYXMgZmFyIGFzIEkga25vdywgeW91IGNhbm5vdCBhdWdtZW50IGluc2lkZSBh IGNob2ljZSBub2RlLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERl YyAxMywgMjAxNywgYXQgNjo1NyBBTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pICZs dDs8YSBocmVmPSJtYWlsdG86ZWluYXJubkBjaXNjby5jb20iIGNsYXNzPSIiPmVpbmFybm5AY2lz Y28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KUGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0 byB0aGUgaW50ZXJmYWNlOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGlu ZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjpp bnRlcmZhY2U6PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBpbmdyZXNzLWFjbHM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAm bmJzcDsmIzQzOy0tcncgYWNsLXNldHM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNv dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3 IHR5cGU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9h Y2Nlc3MtbGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlLXN0YXRpc3RpY3Mq IFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNw OyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBu YW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0 OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRl cjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBlZ3Jl c3MtYWNsczwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9 IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0t cm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWU8 L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7 IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVk LW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5Db3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBhYm92ZSBi b3RoIHRoZXNlICZhbXA7IHJlbmFtZSDigJxpbmdyZXNzLWFjbHMmcXVvdDsgdG8g4oCcaW5ncmVz c+KAnSwgZXRjLiB0byBnaXZlIGEgc2luZ2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50YXRpb24gaWYg cHJlZmVycmVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gNiBE ZWMgMjAxNywgYXQgMTk6NDMsIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNp c2NvLmNvbSIgY2xhc3M9IiI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxi ciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAxMi82LzE3IDc6MjMg UE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+SG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRh Y2htZW50IHBvaW50LCBjdXJyZW50bHkgYW48YnIgY2xhc3M9IiI+DQonaW50ZXJmYWNlLXJlZics IHRvIGFuIGF1Z21lbnRhdGlvbiBvZiB0aGUgaWY6aW50ZXJmYWNlcy9pbnRlcmZhY2UsPGJyIGNs YXNzPSIiPg0KaW5zaWRlIG9mIHRoZSDigJhhY2zigJkgJm5ic3A7Y29udGFpbmVyPyBEb3duIHRo ZSBsaW5lIHdlIG1pZ2h0IG5lZWQgdG8gaGF2ZSBhbjxiciBjbGFzcz0iIj4NCmNvbnRhaW5lciBm b3IgJnF1b3Q7YXR0YWNobWVudCBwb2ludHMmcXVvdDsgdG8gYWNjb21tb2RhdGUgdGhlIHBvc3Np YmlsaXR5IG9mPGJyIGNsYXNzPSIiPg0KYXR0YWNoaW5nIGFuIEFDTCBlaXRoZXIgdG8gYW4gaW50 ZXJmYWNlIG9yIOKAnGdsb2JhbGx54oCdLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCktlZXBpbmcgaW4gbWluZCB0aGF0IG9uZSB1c2Ug aXMgdGhhdCBhbiBBQ0wgZG9lc24ndCBhdHRhY2ggdG8gYW48YnIgY2xhc3M9IiI+DQppbnRlcmZh Y2UgYXQgYWxsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbmV0bW9kIG1haWxp bmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNs YXNzPSIiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgY2xhc3M9IiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xh c3M9IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_42A2F0C452FD48948D08092BB2B0772Bciscocom_-- From nobody Wed Dec 13 12:29:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD10E128BBB for ; Wed, 13 Dec 2017 12:29:40 -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 EJiwRCvru2mY for ; Wed, 13 Dec 2017 12:29:38 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 0EB1D126FDC for ; Wed, 13 Dec 2017 12:29:38 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id o2so1812142pgc.8 for ; Wed, 13 Dec 2017 12:29: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:message-id:references :to; bh=sUnaNq1/TdzpGdR+UZ/XaKfo3WsuT7Vc9qAg2BsdiTA=; b=dg9XvmYY7KLwLmdUFd20YD6Pjv56h/2V82rkJhkQAMbMPXsgULpBokr5qySP3bslxW IF+zYflI2X92tWpqA17eter44nRcIKPyrZbu/f6XZLAyGDqE3UjSLcWpg7VV6dCW3Rk6 M++4yZCmGMMPB3vE8Xi62gJ/JRbU/7z+maKvQk3iUDkXfeVJcUQRbi75FAJU9srE+NQq qpt/NepingmT043gVnubXS45XgTzw8qBZ8yBGfnT9hp8tSFbpdH5azOKsUXE5P1bcUBD aSlisdx8OJdbWYPJCHgTR49q1hx8lcgjESavEPPqDEhWd5tYNqtL2oHeXKpQmEnfncW9 0PmA== 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 :message-id:references:to; bh=sUnaNq1/TdzpGdR+UZ/XaKfo3WsuT7Vc9qAg2BsdiTA=; b=FX+RfoBpTBeejW7JzzVUQ/Or0/Msg+xJXSCgTN2XZ7a65BxoBNSwuBKn0gNWtRkbsq Sx60hNs8NPejFoBuBp/jC2tygtqxxyFNVD8cUjirqYMZj34O6eJ4hnoSEYe4T7e+0WZT c3BVGODjzRHMWJfz8x8oBWOZ22jmH4lJ5J3sQAS+9O209I40RgqM47e1cgf1ZHMfS3EC x5Sano3/F05lNCsFveuT+GEIYjK3l8PJqrTVXMKk6nlmmczhIPmYpeOSHQCDaljKwOF+ d+HQDvRa0Vx8N1KjZI6H9g/dQhzX7eazoGdFfhh02rhejGHX9E/6kQnj9FNHRE0/QPw6 68hg== X-Gm-Message-State: AKGB3mKmjiwJ1vSYRJqer2gntPUQ8Aqa/22QJTMb1QrMMuHNsugfUzeH iRBt2kg760B0F0eA/+jTlz8Fz80v X-Google-Smtp-Source: ACJfBoubNmI+2IzbN0Y7tZ8wqeP7DV0v8zJ2v/hR31/rYwMNz6SanWr/NPNgZ6hJ2+3a8p7VGFEDSA== X-Received: by 10.159.249.9 with SMTP id bf9mr6817842plb.86.1513196977578; Wed, 13 Dec 2017 12:29:37 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:4c65:acaa:7a67:d727]) by smtp.gmail.com with ESMTPSA id j62sm4562577pfc.18.2017.12.13.12.29.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Dec 2017 12:29:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_12CCA54D-8FDD-4A65-A7FE-2E935D0D1499" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> Date: Wed, 13 Dec 2017 12:29:31 -0800 Cc: Eliot Lear , Kristian Larsson , "netmod@ietf.org" 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> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> To: "Einar Nilsen-Nygaard (einarnn)" X-Mailer: Apple Mail (2.3124) 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, 13 Dec 2017 20:29:41 -0000 --Apple-Mail=_12CCA54D-8FDD-4A65-A7FE-2E935D0D1499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My understanding is that you would attach an ACL either to an interface = or globally. Not both. > On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) = wrote: >=20 > I=E2=80=99m happy to have a way to attach an ACL globally, but = that=E2=80=99s orthogonal to attaching to an interface, isn=E2=80=99t = it? Attaching ACLs directly to an interface doesn=E2=80=99t preclude = global attachment in any way as far as I can see=E2=80=A6or have I = missed something? I=E2=80=99m not sure I understand why choices are an = issue. The current proposal has this container: >=20 > module: ietf-access-control-list > +--rw access-lists > +--rw attachment-points > +--rw interface* [interface-id] {interface-attachment}? > +--rw interface-id if:interface-ref > +--rw ingress > | +--rw acl-sets > | +--rw acl-set* [name] > | +--rw name -> ../../../../../../acl/name > | +--rw type? -> ../../../../../../acl/type > | +--ro ace* [name] {interface-stats or = interface-acl-aggregate}? > | +--ro name -> = ../../../../../../../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 -> ../../../../../../acl/name > +--rw type? -> ../../../../../../acl/type > +--ro ace* [name] {interface-stats or = interface-acl-aggregate}? > +--ro name -> = ../../../../../../../acl/aces/ace/name > +--ro matched-packets? yang:counter64 > +--ro matched-octets? yang:counter64 >=20 > If we added some form of global attachment points, that might be a = peer with the list of interface attachments, right? Because we=E2=80=99d = need to support =E2=80=9Cglobal=E2=80=9D and multiple =E2=80=9Cinterface=E2= =80=9D attachments. It=E2=80=99s not an =E2=80=9Cor=E2=80=9D, it=E2=80=99s= an =E2=80=9Cand=E2=80=9D. Or have I missed something? >=20 > Cheers, >=20 > Einar >=20 >> On 13 Dec 2017, at 20:10, Mahesh Jethanandani = > wrote: >>=20 >> 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 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_12CCA54D-8FDD-4A65-A7FE-2E935D0D1499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My understanding is that you would attach an ACL either to an = interface or globally. Not both.

On = Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> = wrote:

I=E2=80=99m happy to have a way to attach an ACL globally, but that=E2=80=99= s orthogonal to attaching to an interface, isn=E2=80=99t it? Attaching = ACLs directly to an interface doesn=E2=80=99t preclude global attachment = in any way as far as I can see=E2=80=A6or have I missed something? I=E2=80= =99m not sure I understand why choices are an issue. The current proposal has this = container:

module: = ietf-access-control-list
    +--rw access-lists
       +--rw attachment-points
          +--rw interface* [interface-id] = {interface-attachment}?
             +--rw interface-id =    if:interface-ref
             +--rw ingress
             |  +--rw = acl-sets
             |     +--rw = acl-set* [name]
             |       =  +--rw name    -> ../../../../../../acl/name
             |       =  +--rw type?   -> ../../../../../../acl/type
             |       =  +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
             |       =     +--ro name             =   -> ../../../../../../../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    -> ../../../../../../acl/name
                    =   +--rw type?   -> ../../../../../../acl/type
                    =   +--ro ace* [name] {interface-stats or = interface-acl-aggregate}?
                    =      +--ro name             =   -> ../../../../../../../acl/aces/ace/name
                    =      +--ro matched-packets?   yang:counter64
                    =      +--ro matched-octets?    yang:counter64

If we added some form of global attachment points, that = might be a peer with the list of interface attachments, right? Because = we=E2=80=99d need to support =E2=80=9Cglobal=E2=80=9D and multiple = =E2=80=9Cinterface=E2=80=9D attachments. It=E2=80=99s not an =E2=80=9Cor=E2= =80=9D, it=E2=80=99s an =E2=80=9Cand=E2=80=9D. Or have I missed something?

Cheers,

Einar

On 13 Dec 2017, at 20:10, 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



Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_12CCA54D-8FDD-4A65-A7FE-2E935D0D1499-- From nobody Wed Dec 13 12:40:51 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3F12704B for ; Wed, 13 Dec 2017 12:40: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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJHYbLw6QCqx for ; Wed, 13 Dec 2017 12:40:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB130127867 for ; Wed, 13 Dec 2017 12:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25172; q=dns/txt; s=iport; t=1513197646; x=1514407246; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0diivG4KtEX3spJDQwnNIfM1wjci+k5bRDBklHIkFYg=; b=IMv6l5pVyMpRNebNPHrFAluCzyZZ83nbcXdEtmtXRh6f9dq+kosnc+DH jluyeuHU9cm4jPIeFeyraQ3BJohEU9dCsLyjMfahevnZ+q/FyOc7uIOxr WQUVoUAXDEK1lKS+ll1CxQeOXr/cegZGyI9tETHcuUG6PXfumJ/alB3IS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAACdjzFa/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPB4FXiR6OGYIVChgBCoRJTwIahHk/GAEBAQE?= =?us-ascii?q?BAQEBAWsohSQCBAEBIQRHCxACAQgOMQMCAgIfBgsUEQIEDgWJREwDFRCocIFtO?= =?us-ascii?q?oc7DYMbAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDYIILg2gLgneCakQBgW03gl8?= =?us-ascii?q?xgjIFkhSQTj0CkCiEfZNojU2FVoMWAhEZAYE6AR85gU5vFToqAYF+P4IUHIFne?= =?us-ascii?q?IkXgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208,217";a="335658725" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 20:40:45 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vBDKejCS003104 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 20:40:45 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; Wed, 13 Dec 2017 15:40:44 -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, 13 Dec 2017 15:40:44 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani CC: Eliot Lear , Kristian Larsson , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAABBMAgAABOICAAAMrAA== Date: Wed, 13 Dec 2017 20:40:44 +0000 Message-ID: <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@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> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.210.168] Content-Type: multipart/alternative; boundary="_000_70C53C475C0A4635BC98EBC9AD4130CBciscocom_" 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, 13 Dec 2017 20:40:50 -0000 --_000_70C53C475C0A4635BC98EBC9AD4130CBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgbmVlZCB0byBiZSBhYmxlIHRvIGF0dGFjaCBhbnkgb25lIEFDTCB0byBhIHdob2xlIHJhbmdl IG9mIGRpZmZlcmVudCBwbGFjZXMuIEp1c3Qgc3BlYWtpbmcgZnJvbSB0aGUgQ2lzY28gcGxhdGZv cm0gcGVyc3BlY3RpdmUsIEkgbWF5IGF0dGFjaCBhbiBBQ0wgdG86DQoNCg0KICAqICAgSW50ZXJm YWNlcw0KICAqICAgTkFUIGNvbmZpZ3VyYXRpb24NCiAgKiAgIENsYXNzIG1hcHMgZm9yIFFvUyBw b2xpY3kNCiAgKiAgIENsYXNzIG1hcHMgZm9yIEZXIHBvbGljeQ0KICAqICAg4oCmZXRj4oCmDQoN Ck5vdCBzdXJlIGlmIHdlIGhhdmUgYW55IGdsb2JhbCBhdHRhY2htZW50IHBvaW50cyB0b2RheSwg YnV0IGlmIHdlIGRpZCwgSeKAmWQgd2FudCB0byBiZSBhYmxlIHRvIHVzZSB0aGUgc2FtZSBBQ0wg ZGVmaW5pdGlvbiBhbnl3aGVyZSBJIG5lZWQgaXQsIG5vdCBpbiBqdXN0IG9uZSBvbiBOIHBsYWNl cy4NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQpPbiAxMyBEZWMgMjAxNywgYXQgMjA6MjksIE1haGVz aCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgeW91IHdv dWxkIGF0dGFjaCBhbiBBQ0wgZWl0aGVyIHRvIGFuIGludGVyZmFjZSBvciBnbG9iYWxseS4gTm90 IGJvdGguDQoNCk9uIERlYyAxMywgMjAxNywgYXQgMTI6MjUgUE0sIEVpbmFyIE5pbHNlbi1OeWdh YXJkIChlaW5hcm5uKSA8ZWluYXJubkBjaXNjby5jb208bWFpbHRvOmVpbmFybm5AY2lzY28uY29t Pj4gd3JvdGU6DQoNCknigJltIGhhcHB5IHRvIGhhdmUgYSB3YXkgdG8gYXR0YWNoIGFuIEFDTCBn bG9iYWxseSwgYnV0IHRoYXTigJlzIG9ydGhvZ29uYWwgdG8gYXR0YWNoaW5nIHRvIGFuIGludGVy ZmFjZSwgaXNu4oCZdCBpdD8gQXR0YWNoaW5nIEFDTHMgZGlyZWN0bHkgdG8gYW4gaW50ZXJmYWNl IGRvZXNu4oCZdCBwcmVjbHVkZSBnbG9iYWwgYXR0YWNobWVudCBpbiBhbnkgd2F5IGFzIGZhciBh cyBJIGNhbiBzZWXigKZvciBoYXZlIEkgbWlzc2VkIHNvbWV0aGluZz8gSeKAmW0gbm90IHN1cmUg SSB1bmRlcnN0YW5kIHdoeSBjaG9pY2VzIGFyZSBhbiBpc3N1ZS4gVGhlIGN1cnJlbnQgcHJvcG9z YWwgaGFzIHRoaXMgY29udGFpbmVyOg0KDQptb2R1bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlz dA0KICAgICstLXJ3IGFjY2Vzcy1saXN0cw0KICAgICAgICstLXJ3IGF0dGFjaG1lbnQtcG9pbnRz DQogICAgICAgICAgKy0tcncgaW50ZXJmYWNlKiBbaW50ZXJmYWNlLWlkXSB7aW50ZXJmYWNlLWF0 dGFjaG1lbnR9Pw0KICAgICAgICAgICAgICstLXJ3IGludGVyZmFjZS1pZCAgICBpZjppbnRlcmZh Y2UtcmVmDQogICAgICAgICAgICAgKy0tcncgaW5ncmVzcw0KICAgICAgICAgICAgIHwgICstLXJ3 IGFjbC1zZXRzDQogICAgICAgICAgICAgfCAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAg ICAgICAgICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAtPiAuLi8uLi8uLi8uLi8uLi8uLi9hY2wv bmFtZQ0KICAgICAgICAgICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAgLT4gLi4vLi4vLi4vLi4v Li4vLi4vYWNsL3R5cGUNCiAgICAgICAgICAgICB8ICAgICAgICArLS1ybyBhY2UqIFtuYW1lXSB7 aW50ZXJmYWNlLXN0YXRzIG9yIGludGVyZmFjZS1hY2wtYWdncmVnYXRlfT8NCiAgICAgICAgICAg ICB8ICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gLi4vLi4vLi4vLi4vLi4v Li4vLi4vYWNsL2FjZXMvYWNlL25hbWUNCiAgICAgICAgICAgICB8ICAgICAgICAgICArLS1ybyBt YXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICAgICAgICB8ICAgICAgICAg ICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICAgICAgICAr LS1ydyBlZ3Jlc3MNCiAgICAgICAgICAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAgICAgICAg ICAgICAgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICAgICAgICAgICstLXJ3 IG5hbWUgICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vYWNsL25hbWUNCiAgICAgICAgICAgICAgICAg ICAgICArLS1ydyB0eXBlPyAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC90eXBlDQogICAgICAg ICAgICAgICAgICAgICAgKy0tcm8gYWNlKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0cyBvciBpbnRl cmZhY2UtYWNsLWFnZ3JlZ2F0ZX0/DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbmFt ZSAgICAgICAgICAgICAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uLy4uL2FjbC9hY2VzL2FjZS9uYW1l DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6 Y291bnRlcjY0DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ ICAgIHlhbmc6Y291bnRlcjY0DQoNCklmIHdlIGFkZGVkIHNvbWUgZm9ybSBvZiBnbG9iYWwgYXR0 YWNobWVudCBwb2ludHMsIHRoYXQgbWlnaHQgYmUgYSBwZWVyIHdpdGggdGhlIGxpc3Qgb2YgaW50 ZXJmYWNlIGF0dGFjaG1lbnRzLCByaWdodD8gQmVjYXVzZSB3ZeKAmWQgbmVlZCB0byBzdXBwb3J0 IOKAnGdsb2JhbOKAnSBhbmQgbXVsdGlwbGUg4oCcaW50ZXJmYWNl4oCdIGF0dGFjaG1lbnRzLiBJ dOKAmXMgbm90IGFuIOKAnG9y4oCdLCBpdOKAmXMgYW4g4oCcYW5k4oCdLiBPciBoYXZlIEkgbWlz c2VkIHNvbWV0aGluZz8NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQpPbiAxMyBEZWMgMjAxNywgYXQg MjA6MTAsIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpXZSB3YW50IHRvIHN1cHBvcnQg 4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgZG93biB0aGUgbGluZSwgYW5kIHRoYXQg4oCc Z2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgd2lsbCBiZSBvbmUgb2YgdGhlIGNob2ljZXMgKHRo ZSBvdGhlciBiZWluZyB0aGUgaW50ZXJmYWNlKSwgd2hhdCB3b3VsZCB0aGlzIGF1Z21lbnQgbG9v ayBsaWtlLiBOb3RlLCBhcyBmYXIgYXMgSSBrbm93LCB5b3UgY2Fubm90IGF1Z21lbnQgaW5zaWRl IGEgY2hvaWNlIG5vZGUuDQoNCk9uIERlYyAxMywgMjAxNywgYXQgNjo1NyBBTSwgRWluYXIgTmls c2VuLU55Z2FhcmQgKGVpbmFybm4pIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBj aXNjby5jb20+PiB3cm90ZToNCg0KUGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlv biB0byB0aGUgaW50ZXJmYWNlOg0KDQogIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJm YWNlOg0KICAgICstLXJ3IGluZ3Jlc3MtYWNscw0KICAgIHwgICstLXJ3IGFjbC1zZXRzDQogICAg fCAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAg ICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgIHwgICAgICAgICstLXJ3IHR5 cGU/ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICB8ICAgICAgICAr LS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgIHwgICAg ICAgICAgICstLXJvIG5hbWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2Vz L2FjZS9uYW1lDQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6 Y291bnRlcjY0DQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6 Y291bnRlcjY0DQogICAgKy0tcncgZWdyZXNzLWFjbHMNCiAgICAgICArLS1ydyBhY2wtc2V0cw0K ICAgICAgICAgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICstLXJ3IG5hbWUg ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICAgICAgICArLS1y dyB0eXBlPyAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgICAg ICAgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAg ICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wv YWNlcy9hY2UvbmFtZQ0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5 YW5nOmNvdW50ZXI2NA0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5 YW5nOmNvdW50ZXI2NA0KDQpDb3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBh Ym92ZSBib3RoIHRoZXNlICYgcmVuYW1lIOKAnGluZ3Jlc3MtYWNscyIgdG8g4oCcaW5ncmVzc+KA nSwgZXRjLiB0byBnaXZlIGEgc2luZ2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50YXRpb24gaWYgcHJl ZmVycmVkLg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KT24gNiBEZWMgMjAxNywgYXQgMTk6NDMs IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3Rl Og0KDQoNCg0KT24gMTIvNi8xNyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0K SG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBvaW50LCBjdXJyZW50 bHkgYW4NCidpbnRlcmZhY2UtcmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZSBpZjppbnRl cmZhY2VzL2ludGVyZmFjZSwNCmluc2lkZSBvZiB0aGUg4oCYYWNs4oCZICBjb250YWluZXI/IERv d24gdGhlIGxpbmUgd2UgbWlnaHQgbmVlZCB0byBoYXZlIGFuDQpjb250YWluZXIgZm9yICJhdHRh Y2htZW50IHBvaW50cyIgdG8gYWNjb21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5IG9mDQphdHRhY2hp bmcgYW4gQUNMIGVpdGhlciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uDQoNCg0K S2VlcGluZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFj aCB0byBhbg0KaW50ZXJmYWNlIGF0IGFsbC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9y ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdt YWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQpNYWhlc2ggSmV0 aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20+DQoNCg0K --_000_70C53C475C0A4635BC98EBC9AD4130CBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <12DB4B0042823149BA1774A598630E72@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldlIG5lZWQgdG8gYmUgYWJsZSB0byBhdHRhY2gg YW55IG9uZSBBQ0wgdG8gYSB3aG9sZSByYW5nZSBvZiBkaWZmZXJlbnQgcGxhY2VzLiBKdXN0IHNw ZWFraW5nIGZyb20gdGhlIENpc2NvIHBsYXRmb3JtIHBlcnNwZWN0aXZlLCBJIG1heSBhdHRhY2gg YW4gQUNMIHRvOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8dWwgY2xhc3M9Ik1haWxPdXRsaW5lIj4NCjxsaSBjbGFzcz0iIj5JbnRlcmZhY2Vz PC9saT48bGkgY2xhc3M9IiI+TkFUIGNvbmZpZ3VyYXRpb248L2xpPjxsaSBjbGFzcz0iIj5DbGFz cyBtYXBzIGZvciBRb1MgcG9saWN5PC9saT48bGkgY2xhc3M9IiI+Q2xhc3MgbWFwcyBmb3IgRlcg cG9saWN5PC9saT48bGkgY2xhc3M9IiI+4oCmZXRj4oCmPC9saT48L3VsPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90IHN1cmUgaWYgd2UgaGF2 ZSBhbnkgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnRzIHRvZGF5LCBidXQgaWYgd2UgZGlkLCBJ4oCZ ZCB3YW50IHRvIGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIEFDTCBkZWZpbml0aW9uIGFueXdoZXJl IEkgbmVlZCBpdCwgbm90IGluIGp1c3Qgb25lIG9uIE4gcGxhY2VzLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIDEzIERlYyAyMDE3LCBhdCAyMDoyOSwgTWFoZXNoIEpldGhhbmFuZGFuaSAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KTXkgdW5kZXJzdGFuZGluZyBp cyB0aGF0IHlvdSB3b3VsZCBhdHRhY2ggYW4gQUNMIGVpdGhlciB0byBhbiBpbnRlcmZhY2UgPGIg Y2xhc3M9IiI+DQpvcjwvYj4gZ2xvYmFsbHkuIE5vdCBib3RoLg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxMywgMjAxNywgYXQgMTI6MjUgUE0sIEVpbmFyIE5p bHNlbi1OeWdhYXJkIChlaW5hcm5uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVpbmFybm5AY2lzY28u Y29tIiBjbGFzcz0iIj5laW5hcm5uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCknigJltIGhhcHB5IHRv IGhhdmUgYSB3YXkgdG8gYXR0YWNoIGFuIEFDTCBnbG9iYWxseSwgYnV0IHRoYXTigJlzIG9ydGhv Z29uYWwgdG8gYXR0YWNoaW5nIHRvIGFuIGludGVyZmFjZSwgaXNu4oCZdCBpdD8gQXR0YWNoaW5n IEFDTHMgZGlyZWN0bHkgdG8gYW4gaW50ZXJmYWNlIGRvZXNu4oCZdCBwcmVjbHVkZSBnbG9iYWwg YXR0YWNobWVudCBpbiBhbnkgd2F5IGFzIGZhciBhcyBJIGNhbiBzZWXigKZvciBoYXZlIEkgbWlz c2VkIHNvbWV0aGluZz8gSeKAmW0gbm90IHN1cmUNCiBJIHVuZGVyc3RhbmQgd2h5IGNob2ljZXMg YXJlIGFuIGlzc3VlLiBUaGUgY3VycmVudCBwcm9wb3NhbCBoYXMgdGhpcyBjb250YWluZXI6DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+bW9kdWxlOiBpZXRmLWFjY2Vz cy1jb250cm9sLWxpc3Q8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2Nl c3MtbGlzdHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0t cncgYXR0YWNobWVudC1wb2ludHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBpbnRlcmZhY2UqIFtpbnRlcmZhY2UtaWRdIHtpbnRlcmZh Y2UtYXR0YWNobWVudH0/PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGludGVyZmFjZS1pZCAmbmJzcDsgJm5ic3A7 aWY6aW50ZXJmYWNlLXJlZjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBpbmdyZXNzPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQz Oy0tcncgYWNsLXNldHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtu YW1lXTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5i c3A7ICZuYnNwOy0mZ3Q7IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC9uYW1lPGJyIGNsYXNzPSIiPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7IC0mZ3Q7IC4uLy4uLy4u Ly4uLy4uLy4uL2FjbC90eXBlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcm8gYWNlKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0cyBvciBpbnRlcmZhY2UtYWNsLWFnZ3Jl Z2F0ZX0/PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y byBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAt Jmd0OyAuLi8uLi8uLi8uLi8uLi8uLi8uLi9hY2wvYWNlcy9hY2UvbmFtZTxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAm bmJzcDsgeWFuZzpjb3VudGVyNjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVy NjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0tcncgZWdyZXNzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldHM8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7 LSZndDsgLi4vLi4vLi4vLi4vLi4vLi4vYWNsL25hbWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgLSZndDsgLi4vLi4vLi4vLi4vLi4vLi4v YWNsL3R5cGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBhY2Uq IFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzIG9yIGludGVyZmFjZS1hY2wtYWdncmVnYXRlfT88YnIg Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbmFt ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsg Li4vLi4vLi4vLi4vLi4vLi4vLi4vYWNsL2FjZXMvYWNlL25hbWU8YnIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAm bmJzcDsgeWFuZzpjb3VudGVyNjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNv dW50ZXI2NDxiciBjbGFzcz0iIj4NCjwvZm9udD48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SWYgd2UgYWRkZWQgc29tZSBmb3JtIG9mIGdsb2JhbCBhdHRhY2htZW50IHBvaW50 cywgdGhhdCBtaWdodCBiZSBhIHBlZXIgd2l0aCB0aGUgbGlzdCBvZiBpbnRlcmZhY2UgYXR0YWNo bWVudHMsIHJpZ2h0PyBCZWNhdXNlIHdl4oCZZCBuZWVkIHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCd IGFuZCBtdWx0aXBsZSDigJxpbnRlcmZhY2XigJ0gYXR0YWNobWVudHMuIEl04oCZcyBub3QgYW4g 4oCcb3LigJ0sIGl04oCZcyBhbiDigJxhbmTigJ0uIE9yIGhhdmUgSSBtaXNzZWQNCiBzb21ldGhp bmc/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEzIERlYyAyMDE3LCBhdCAyMDoxMCwg TWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIi Pg0KV2Ugd2FudCB0byBzdXBwb3J0IOKAnGdsb2JhbOKAnSBhdHRhY2htZW50IHBvaW50IGRvd24g dGhlIGxpbmUsIGFuZCB0aGF0IOKAnGdsb2JhbOKAnSBhdHRhY2htZW50IHBvaW50IHdpbGwgYmUg b25lIG9mIHRoZSBjaG9pY2VzICh0aGUgb3RoZXIgYmVpbmcgdGhlIGludGVyZmFjZSksIHdoYXQg d291bGQgdGhpcyBhdWdtZW50IGxvb2sgbGlrZS4gTm90ZSwgYXMgZmFyIGFzIEkga25vdywgeW91 IGNhbm5vdCBhdWdtZW50IGluc2lkZSBhIGNob2ljZSBub2RlLg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxMywgMjAxNywgYXQgNjo1NyBBTSwgRWluYXIgTmls c2VuLU55Z2FhcmQgKGVpbmFybm4pICZsdDs8YSBocmVmPSJtYWlsdG86ZWluYXJubkBjaXNjby5j b20iIGNsYXNzPSIiPmVpbmFybm5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBs aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KUGVyaGFwcyBsaWtlIHRo aXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgaW50ZXJmYWNlOg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQw cHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgYXVn bWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBpbmdyZXNzLWFjbHM8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsmIzQzOy0tcncgYWNsLXNldHM8L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNv dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBh Y2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9u YW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHR5cGU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm IzQzOy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9 IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1l PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFu Zzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8g Jm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBlZ3Jlc3MtYWNsczwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3Vy aWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlz dHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBl PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJm YWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3Mt bGlzdHMvYWNsL2FjZXMvYWNlL25hbWU8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJv IG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBj bGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRl cjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Db3VsZCBhbHNvIHB1dCBhbiDigJxh Y2Vz4oCdIGNvbnRhaW5lciBhYm92ZSBib3RoIHRoZXNlICZhbXA7IHJlbmFtZSDigJxpbmdyZXNz LWFjbHMmcXVvdDsgdG8g4oCcaW5ncmVzc+KAnSwgZXRjLiB0byBnaXZlIGEgc2luZ2xlIHJvb3Qg Zm9yIHRoZSBhdWdtZW50YXRpb24gaWYgcHJlZmVycmVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVy cyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+T24gNiBEZWMgMjAxNywgYXQgMTk6NDMsIEVsaW90IExlYXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSIgY2xhc3M9IiI+bGVhckBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpPbiAxMi82LzE3IDc6MjMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SG93IGRvZXMgb25l IG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBvaW50LCBjdXJyZW50bHkgYW48YnIgY2xh c3M9IiI+DQonaW50ZXJmYWNlLXJlZicsIHRvIGFuIGF1Z21lbnRhdGlvbiBvZiB0aGUgaWY6aW50 ZXJmYWNlcy9pbnRlcmZhY2UsPGJyIGNsYXNzPSIiPg0KaW5zaWRlIG9mIHRoZSDigJhhY2zigJkg Jm5ic3A7Y29udGFpbmVyPyBEb3duIHRoZSBsaW5lIHdlIG1pZ2h0IG5lZWQgdG8gaGF2ZSBhbjxi ciBjbGFzcz0iIj4NCmNvbnRhaW5lciBmb3IgJnF1b3Q7YXR0YWNobWVudCBwb2ludHMmcXVvdDsg dG8gYWNjb21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5IG9mPGJyIGNsYXNzPSIiPg0KYXR0YWNoaW5n IGFuIEFDTCBlaXRoZXIgdG8gYW4gaW50ZXJmYWNlIG9yIOKAnGdsb2JhbGx54oCdLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCktlZXBp bmcgaW4gbWluZCB0aGF0IG9uZSB1c2UgaXMgdGhhdCBhbiBBQ0wgZG9lc24ndCBhdHRhY2ggdG8g YW48YnIgY2xhc3M9IiI+DQppbnRlcmZhY2UgYXQgYWxsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy IGNsYXNzPSIiPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2Q8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5NYWhl c2ggSmV0aGFuYW5kYW5pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+ PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1haGVzaCBKZXRoYW5hbmRhbmk8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5t amV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_70C53C475C0A4635BC98EBC9AD4130CBciscocom_-- From nobody Wed Dec 13 13:09:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABE61242EA for ; Wed, 13 Dec 2017 13:09:14 -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 GucSdjVK8EzI for ; Wed, 13 Dec 2017 13:08:59 -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 C0C38127867 for ; Wed, 13 Dec 2017 13:08:59 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id j124so2026410pfc.2 for ; Wed, 13 Dec 2017 13:08:59 -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:message-id:references :to; bh=CsWpFQi8u698Su5KWpIa5cdrLX/PPSESFl1Buvnf4NM=; b=Xz4sZ6DGoUYy5Ufjox22ufhK06/HFMfqYD89oLD22KmnGwfMuW9M89xfDpzv1UDb9N vftW49O/rYI6H3DuqUZN4xBfVt+oF+W1KQJT9u3TG7CaFCCcfWflLg0V7ayvRhv9eVR7 8yd49aGaKWhIASTUW10kaQOLzw4Ekhw9gAACKd3PdWC+YR56TqvUpQQ9QMCwRBY+HIQq QiNlveZNtIP5m+2tdB1/0OZQn1HuSz+vofktY+iOqB6aTG2iXiDQNc0hggrh2fFjSj42 MWEFl1E2Q8YV86W+xdtk4DtzCIzpxxywVPcmm2dC8pBtvn6a+UdDeRmsZfcKfprDTf0v nQzQ== 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 :message-id:references:to; bh=CsWpFQi8u698Su5KWpIa5cdrLX/PPSESFl1Buvnf4NM=; b=O/unmm9A6H8ub2Ur2GZokfBZXysUD0ptS0Y5peAdXHCg2+JPKaTC8DBxmrkQWLrBQu oc42c7fiGtRxiLOuMza0n6M+kbAfeBjZqWwDDmyat7Wv3J6X8bUCy64oSipGT71NL9sf B60stg6+a9hH6QNCBPuSGkTOBCl4sWe3W07OKD4/unz9hlEW2V2ETvVbzVr6CKxHh6La D5cFI4aw+kY+Zbk/JUUafTdC9z/MkZj8qNIp6gYhPuFqs49dFImgEb56cykGKv/gqSYG WRd4Fmy9XC5iH5g7gmkU5duhOx9X2vW0kemcM1OeKD3z8hkZW10KWP4A2v/6g/GI5n7o eo5Q== X-Gm-Message-State: AKGB3mKsRq9TvlJrV+vfqLrAiVOggtPFBTlLA9fsQaD1Vng4udWjqhvj Q79vj+Mpif20OpCCRts8iro= X-Google-Smtp-Source: ACJfBostxLP2Xp3PNSdizXThtW1HjjC3XXRxDrJW35xDd5ZP+jsth7+YA2ZieDuhse+1919s19S9fg== X-Received: by 10.84.242.69 with SMTP id c5mr7105272pll.73.1513199339253; Wed, 13 Dec 2017 13:08:59 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id k197sm4011310pga.42.2017.12.13.13.08.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Dec 2017 13:08:58 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AE319B3B-1F56-44E0-802D-59E74A1B2AEC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@cisco.com> Date: Wed, 13 Dec 2017 13:08:56 -0800 Cc: Eliot Lear , Kristian Larsson , "netmod@ietf.org" Message-Id: <5CBC1C7B-FB4C-4313-9BE3-BEF618C62DA2@gmail.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> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@cisco.com> To: "Einar Nilsen-Nygaard (einarnn)" X-Mailer: Apple Mail (2.3124) 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, 13 Dec 2017 21:09:15 -0000 --Apple-Mail=_AE319B3B-1F56-44E0-802D-59E74A1B2AEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You can use the same ACL definition to attach to different points in the = system, provided they do not overlap. Otherwise, you are just wasting = CAM entries. Global and interface attachment points will overlap with = each other, because global means =E2=80=98any=E2=80=99 interface. > On Dec 13, 2017, at 12:40 PM, Einar Nilsen-Nygaard (einarnn) = wrote: >=20 > We need to be able to attach any one ACL to a whole range of different = places. Just speaking from the Cisco platform perspective, I may attach = an ACL to: >=20 > Interfaces > NAT configuration > Class maps for QoS policy > Class maps for FW policy > =E2=80=A6etc=E2=80=A6 >=20 > Not sure if we have any global attachment points today, but if we did, = I=E2=80=99d want to be able to use the same ACL definition anywhere I = need it, not in just one on N places. >=20 > Cheers, >=20 > Einar >=20 >> On 13 Dec 2017, at 20:29, Mahesh Jethanandani = > wrote: >>=20 >> My understanding is that you would attach an ACL either to an = interface or globally. Not both. >>=20 >>> On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>=20 >>> I=E2=80=99m happy to have a way to attach an ACL globally, but = that=E2=80=99s orthogonal to attaching to an interface, isn=E2=80=99t = it? Attaching ACLs directly to an interface doesn=E2=80=99t preclude = global attachment in any way as far as I can see=E2=80=A6or have I = missed something? I=E2=80=99m not sure I understand why choices are an = issue. The current proposal has this container: >>>=20 >>> module: ietf-access-control-list >>> +--rw access-lists >>> +--rw attachment-points >>> +--rw interface* [interface-id] {interface-attachment}? >>> +--rw interface-id if:interface-ref >>> +--rw ingress >>> | +--rw acl-sets >>> | +--rw acl-set* [name] >>> | +--rw name -> ../../../../../../acl/name >>> | +--rw type? -> ../../../../../../acl/type >>> | +--ro ace* [name] {interface-stats or = interface-acl-aggregate}? >>> | +--ro name -> = ../../../../../../../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 -> ../../../../../../acl/name >>> +--rw type? -> ../../../../../../acl/type >>> +--ro ace* [name] {interface-stats or = interface-acl-aggregate}? >>> +--ro name -> = ../../../../../../../acl/aces/ace/name >>> +--ro matched-packets? yang:counter64 >>> +--ro matched-octets? yang:counter64 >>>=20 >>> If we added some form of global attachment points, that might be a = peer with the list of interface attachments, right? Because we=E2=80=99d = need to support =E2=80=9Cglobal=E2=80=9D and multiple =E2=80=9Cinterface=E2= =80=9D attachments. It=E2=80=99s not an =E2=80=9Cor=E2=80=9D, it=E2=80=99s= an =E2=80=9Cand=E2=80=9D. Or have I missed something? >>>=20 >>> Cheers, >>>=20 >>> Einar >>>=20 >>>> On 13 Dec 2017, at 20:10, Mahesh Jethanandani = > wrote: >>>>=20 >>>> 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 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_AE319B3B-1F56-44E0-802D-59E74A1B2AEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You can use the same ACL definition to attach to different = points in the system, provided they do not overlap. Otherwise, you are = just wasting CAM entries. Global and interface attachment points will = overlap with each other, because global means =E2=80=98any=E2=80=99 = interface.

On Dec 13, 2017, at 12:40 PM, Einar = Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:

We need to be able to attach any one ACL to a whole range of different = places. Just speaking from the Cisco platform perspective, I may attach = an ACL to:

  • Interfaces
  • NAT configuration
  • Class maps for QoS policy
  • Class maps for = FW policy
  • =E2=80=A6etc=E2=80=A6

Not sure if we have any global attachment points today, = but if we did, I=E2=80=99d want to be able to use the same ACL = definition anywhere I need it, not in just one on N places.

Cheers,

Einar

On 13 Dec 2017, at 20:29, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

My understanding is that you would attach an ACL either to an interface = or globally. Not both.

On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard = (einarnn) <einarnn@cisco.com> wrote:

I=E2=80=99m happy to have a way to attach an ACL globally, but that=E2=80=99= s orthogonal to attaching to an interface, isn=E2=80=99t it? Attaching = ACLs directly to an interface doesn=E2=80=99t preclude global attachment = in any way as far as I can see=E2=80=A6or have I missed something? I=E2=80= =99m not sure I understand why choices are an issue. The current proposal has this = container:

module: = ietf-access-control-list
    +--rw access-lists
       +--rw attachment-points
          +--rw interface* [interface-id] = {interface-attachment}?
             +--rw interface-id =    if:interface-ref
             +--rw ingress
             |  +--rw = acl-sets
             |     +--rw = acl-set* [name]
             |       =  +--rw name    -> ../../../../../../acl/name
             |       =  +--rw type?   -> ../../../../../../acl/type
             |       =  +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
             |       =     +--ro name             =   -> ../../../../../../../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    -> ../../../../../../acl/name
                    =   +--rw type?   -> ../../../../../../acl/type
                    =   +--ro ace* [name] {interface-stats or = interface-acl-aggregate}?
                    =      +--ro name             =   -> ../../../../../../../acl/aces/ace/name
                    =      +--ro matched-packets?   yang:counter64
                    =      +--ro matched-octets?    yang:counter64

If we added some form of global attachment points, that = might be a peer with the list of interface attachments, right? Because = we=E2=80=99d need to support =E2=80=9Cglobal=E2=80=9D and multiple = =E2=80=9Cinterface=E2=80=9D attachments. It=E2=80=99s not an =E2=80=9Cor=E2= =80=9D, it=E2=80=99s an =E2=80=9Cand=E2=80=9D. Or have I missed something?

Cheers,

Einar

On 13 Dec 2017, at 20:10, 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



Mahesh Jethanandani
mjethanandani@gmail.com



Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_AE319B3B-1F56-44E0-802D-59E74A1B2AEC-- From nobody Wed Dec 13 13:15:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4BB128DF6 for ; Wed, 13 Dec 2017 13:15:36 -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, 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 3cqm-KcN-lM9 for ; Wed, 13 Dec 2017 13:15:33 -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 5C020126B7E for ; Wed, 13 Dec 2017 13:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29416; q=dns/txt; s=iport; t=1513199733; x=1514409333; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b/NNxtdNiIs/kJUyDOr2JB4gaA8/QUJ84AI0cSkutHU=; b=JunXdMCC/GYDaqEe9TPwwKjYTo39uW+lsvtxTLBtmyO4P1zGWEWoMPNI ITzvvasumreeAhs6teCLjPtEvvTKtkbipL4vHwjqu57qFhFiR0WpGuWFG 3gCTaioX+2G0nmZhfSIE9B5Lr6FmkwZQGvyW9lrArqo6XIn+vVwzSm1K8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAADqlzFa/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N7iiGPB4p1jhmCFQoYAQqESU8CGoR5PxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUkAgQBASEERwsQAgEIDjEDAgICHwYLFBECBA4FiURMAxUQqHGBbTqHO?= =?us-ascii?q?w2DGwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg2CCC4NogwKCakQBgW03gl8xgjI?= =?us-ascii?q?FkhSQTj0CkCiEfZNojU2FVoMWAhEZAYE6AR85gU5vFToqAYF+P4IUHIFneIkXg?= =?us-ascii?q?RUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208,217";a="332084954" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Dec 2017 21:15:31 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBDLFVsl027332 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Dec 2017 21:15: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; Wed, 13 Dec 2017 16:15: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; Wed, 13 Dec 2017 16:15:30 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Mahesh Jethanandani CC: Eliot Lear , Kristian Larsson , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAABBMAgAABOICAAAMrAIAAB9gAgAAB4IA= Date: Wed, 13 Dec 2017 21:15:29 +0000 Message-ID: <11BA5D15-8C55-419B-ACBC-3D2202031280@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> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@cisco.com> <5CBC1C7B-FB4C-4313-9BE3-BEF618C62DA2@gmail.com> In-Reply-To: <5CBC1C7B-FB4C-4313-9BE3-BEF618C62DA2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.210.168] Content-Type: multipart/alternative; boundary="_000_11BA5D158C55419BACBC3D2202031280ciscocom_" 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, 13 Dec 2017 21:15:36 -0000 --_000_11BA5D158C55419BACBC3D2202031280ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgd2UgaGF2ZSBhIGNsZWFyIGVub3VnaCBjb21tb24gdW5kZXJzdGFuZGlu ZyBvZiDigJxnbG9iYWzigJ0gYXMgeWV0IHRvIGJlIGFibGUgdG8gc2F5IHRoYXQgd2Ugc2hvdWxk IG1ha2UgdGhlIHByb3Zpc2lvbmluZyBvZiBhbiBBQ0wgb24gYW4gaW50ZXJmYWNlIG9yIOKAnGds b2JhbGx54oCdIG11dHVhbGx5IGV4Y2x1c2l2ZSBpbiB0aGUgbW9kZWwuIEkgdGhpbmsgYXR0YWNo aW5nIGFuIEFDTCB0byBhIHNwZWNpZmljIGludGVyZmFjZSBpbiBlaXRoZXIgdGhlIGluZ3Jlc3Mg b3IgZWdyZXNzIGRpcmVjdGlvbiBpcyB3ZWxsLXVuZGVyc3Rvb2QsIGFuZCB3aXRoIGEgc2hhcmVk IHVuZGVyc3RhbmRpbmcgYWNyb3NzIHZlbmRvcnMgYW5kIG9wZXJhdG9ycyBzdWNoIHRoYXQgZWl0 aGVyIGFuIGludGVyZmFjZSBhdWdtZW50YXRpb24gb3IgYSDigJxleHRlcm5hbOKAnSBsaXN0ICwg d2l0aCBubyBtZW50aW9uIG9mIGdsb2JhbCwgbWFrZXMgc2Vuc2UuDQoNCkNoZWVycywNCg0KRWlu YXINCg0KT24gMTMgRGVjIDIwMTcsIGF0IDIxOjA4LCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90 ZToNCg0KWW91IGNhbiB1c2UgdGhlIHNhbWUgQUNMIGRlZmluaXRpb24gdG8gYXR0YWNoIHRvIGRp ZmZlcmVudCBwb2ludHMgaW4gdGhlIHN5c3RlbSwgcHJvdmlkZWQgdGhleSBkbyBub3Qgb3Zlcmxh cC4gT3RoZXJ3aXNlLCB5b3UgYXJlIGp1c3Qgd2FzdGluZyBDQU0gZW50cmllcy4gR2xvYmFsIGFu ZCBpbnRlcmZhY2UgYXR0YWNobWVudCBwb2ludHMgd2lsbCBvdmVybGFwIHdpdGggZWFjaCBvdGhl ciwgYmVjYXVzZSBnbG9iYWwgbWVhbnMg4oCYYW554oCZIGludGVyZmFjZS4NCg0KT24gRGVjIDEz LCAyMDE3LCBhdCAxMjo0MCBQTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIDxlaW5h cm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+PiB3cm90ZToNCg0KV2UgbmVl ZCB0byBiZSBhYmxlIHRvIGF0dGFjaCBhbnkgb25lIEFDTCB0byBhIHdob2xlIHJhbmdlIG9mIGRp ZmZlcmVudCBwbGFjZXMuIEp1c3Qgc3BlYWtpbmcgZnJvbSB0aGUgQ2lzY28gcGxhdGZvcm0gcGVy c3BlY3RpdmUsIEkgbWF5IGF0dGFjaCBhbiBBQ0wgdG86DQoNCg0KICAqICAgSW50ZXJmYWNlcw0K ICAqICAgTkFUIGNvbmZpZ3VyYXRpb24NCiAgKiAgIENsYXNzIG1hcHMgZm9yIFFvUyBwb2xpY3kN CiAgKiAgIENsYXNzIG1hcHMgZm9yIEZXIHBvbGljeQ0KICAqICAg4oCmZXRj4oCmDQoNCk5vdCBz dXJlIGlmIHdlIGhhdmUgYW55IGdsb2JhbCBhdHRhY2htZW50IHBvaW50cyB0b2RheSwgYnV0IGlm IHdlIGRpZCwgSeKAmWQgd2FudCB0byBiZSBhYmxlIHRvIHVzZSB0aGUgc2FtZSBBQ0wgZGVmaW5p dGlvbiBhbnl3aGVyZSBJIG5lZWQgaXQsIG5vdCBpbiBqdXN0IG9uZSBvbiBOIHBsYWNlcy4NCg0K Q2hlZXJzLA0KDQpFaW5hcg0KDQpPbiAxMyBEZWMgMjAxNywgYXQgMjA6MjksIE1haGVzaCBKZXRo YW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgeW91IHdvdWxkIGF0 dGFjaCBhbiBBQ0wgZWl0aGVyIHRvIGFuIGludGVyZmFjZSBvciBnbG9iYWxseS4gTm90IGJvdGgu DQoNCk9uIERlYyAxMywgMjAxNywgYXQgMTI6MjUgUE0sIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChl aW5hcm5uKSA8ZWluYXJubkBjaXNjby5jb208bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4gd3Jv dGU6DQoNCknigJltIGhhcHB5IHRvIGhhdmUgYSB3YXkgdG8gYXR0YWNoIGFuIEFDTCBnbG9iYWxs eSwgYnV0IHRoYXTigJlzIG9ydGhvZ29uYWwgdG8gYXR0YWNoaW5nIHRvIGFuIGludGVyZmFjZSwg aXNu4oCZdCBpdD8gQXR0YWNoaW5nIEFDTHMgZGlyZWN0bHkgdG8gYW4gaW50ZXJmYWNlIGRvZXNu 4oCZdCBwcmVjbHVkZSBnbG9iYWwgYXR0YWNobWVudCBpbiBhbnkgd2F5IGFzIGZhciBhcyBJIGNh biBzZWXigKZvciBoYXZlIEkgbWlzc2VkIHNvbWV0aGluZz8gSeKAmW0gbm90IHN1cmUgSSB1bmRl cnN0YW5kIHdoeSBjaG9pY2VzIGFyZSBhbiBpc3N1ZS4gVGhlIGN1cnJlbnQgcHJvcG9zYWwgaGFz IHRoaXMgY29udGFpbmVyOg0KDQptb2R1bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdA0KICAg ICstLXJ3IGFjY2Vzcy1saXN0cw0KICAgICAgICstLXJ3IGF0dGFjaG1lbnQtcG9pbnRzDQogICAg ICAgICAgKy0tcncgaW50ZXJmYWNlKiBbaW50ZXJmYWNlLWlkXSB7aW50ZXJmYWNlLWF0dGFjaG1l bnR9Pw0KICAgICAgICAgICAgICstLXJ3IGludGVyZmFjZS1pZCAgICBpZjppbnRlcmZhY2UtcmVm DQogICAgICAgICAgICAgKy0tcncgaW5ncmVzcw0KICAgICAgICAgICAgIHwgICstLXJ3IGFjbC1z ZXRzDQogICAgICAgICAgICAgfCAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgICAgICAg ICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAtPiAuLi8uLi8uLi8uLi8uLi8uLi9hY2wvbmFtZQ0K ICAgICAgICAgICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4v YWNsL3R5cGUNCiAgICAgICAgICAgICB8ICAgICAgICArLS1ybyBhY2UqIFtuYW1lXSB7aW50ZXJm YWNlLXN0YXRzIG9yIGludGVyZmFjZS1hY2wtYWdncmVnYXRlfT8NCiAgICAgICAgICAgICB8ICAg ICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vLi4v YWNsL2FjZXMvYWNlL25hbWUNCiAgICAgICAgICAgICB8ICAgICAgICAgICArLS1ybyBtYXRjaGVk LXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICAgICAgICB8ICAgICAgICAgICArLS1y byBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICAgICAgICArLS1ydyBl Z3Jlc3MNCiAgICAgICAgICAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAgICAgICAgICAgICAg ICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICAgICAgICAgICstLXJ3IG5hbWUg ICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vYWNsL25hbWUNCiAgICAgICAgICAgICAgICAgICAgICAr LS1ydyB0eXBlPyAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC90eXBlDQogICAgICAgICAgICAg ICAgICAgICAgKy0tcm8gYWNlKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0cyBvciBpbnRlcmZhY2Ut YWNsLWFnZ3JlZ2F0ZX0/DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbmFtZSAgICAg ICAgICAgICAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uLy4uL2FjbC9hY2VzL2FjZS9uYW1lDQogICAg ICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRl cjY0DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlh bmc6Y291bnRlcjY0DQoNCklmIHdlIGFkZGVkIHNvbWUgZm9ybSBvZiBnbG9iYWwgYXR0YWNobWVu dCBwb2ludHMsIHRoYXQgbWlnaHQgYmUgYSBwZWVyIHdpdGggdGhlIGxpc3Qgb2YgaW50ZXJmYWNl IGF0dGFjaG1lbnRzLCByaWdodD8gQmVjYXVzZSB3ZeKAmWQgbmVlZCB0byBzdXBwb3J0IOKAnGds b2JhbOKAnSBhbmQgbXVsdGlwbGUg4oCcaW50ZXJmYWNl4oCdIGF0dGFjaG1lbnRzLiBJdOKAmXMg bm90IGFuIOKAnG9y4oCdLCBpdOKAmXMgYW4g4oCcYW5k4oCdLiBPciBoYXZlIEkgbWlzc2VkIHNv bWV0aGluZz8NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQpPbiAxMyBEZWMgMjAxNywgYXQgMjA6MTAs IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpXZSB3YW50IHRvIHN1cHBvcnQg4oCcZ2xv YmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgZG93biB0aGUgbGluZSwgYW5kIHRoYXQg4oCcZ2xvYmFs 4oCdIGF0dGFjaG1lbnQgcG9pbnQgd2lsbCBiZSBvbmUgb2YgdGhlIGNob2ljZXMgKHRoZSBvdGhl ciBiZWluZyB0aGUgaW50ZXJmYWNlKSwgd2hhdCB3b3VsZCB0aGlzIGF1Z21lbnQgbG9vayBsaWtl LiBOb3RlLCBhcyBmYXIgYXMgSSBrbm93LCB5b3UgY2Fubm90IGF1Z21lbnQgaW5zaWRlIGEgY2hv aWNlIG5vZGUuDQoNCk9uIERlYyAxMywgMjAxNywgYXQgNjo1NyBBTSwgRWluYXIgTmlsc2VuLU55 Z2FhcmQgKGVpbmFybm4pIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBjaXNjby5j b20+PiB3cm90ZToNCg0KUGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0 aGUgaW50ZXJmYWNlOg0KDQogIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0K ICAgICstLXJ3IGluZ3Jlc3MtYWNscw0KICAgIHwgICstLXJ3IGFjbC1zZXRzDQogICAgfCAgICAg Ky0tcncgYWNsLXNldCogW25hbWVdDQogICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAg ICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAg ICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICB8ICAgICAgICArLS1ybyBh Y2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgIHwgICAgICAgICAg ICstLXJvIG5hbWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9u YW1lDQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRl cjY0DQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRl cjY0DQogICAgKy0tcncgZWdyZXNzLWFjbHMNCiAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAg ICAgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAg ICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICAgICAgICArLS1ydyB0eXBl PyAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgICAgICAgKy0t cm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAgICAgICAg ICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9h Y2UvbmFtZQ0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNv dW50ZXI2NA0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNv dW50ZXI2NA0KDQpDb3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBhYm92ZSBi b3RoIHRoZXNlICYgcmVuYW1lIOKAnGluZ3Jlc3MtYWNscyIgdG8g4oCcaW5ncmVzc+KAnSwgZXRj LiB0byBnaXZlIGEgc2luZ2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50YXRpb24gaWYgcHJlZmVycmVk Lg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KT24gNiBEZWMgMjAxNywgYXQgMTk6NDMsIEVsaW90 IExlYXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoN Cg0KT24gMTIvNi8xNyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0KSG93IGRv ZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBvaW50LCBjdXJyZW50bHkgYW4N CidpbnRlcmZhY2UtcmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZSBpZjppbnRlcmZhY2Vz L2ludGVyZmFjZSwNCmluc2lkZSBvZiB0aGUg4oCYYWNs4oCZICBjb250YWluZXI/IERvd24gdGhl IGxpbmUgd2UgbWlnaHQgbmVlZCB0byBoYXZlIGFuDQpjb250YWluZXIgZm9yICJhdHRhY2htZW50 IHBvaW50cyIgdG8gYWNjb21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5IG9mDQphdHRhY2hpbmcgYW4g QUNMIGVpdGhlciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uDQoNCg0KS2VlcGlu ZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFjaCB0byBh bg0KaW50ZXJmYWNlIGF0IGFsbC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWls dG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNv bTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQpNYWhlc2ggSmV0aGFuYW5k YW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5j b20+DQoNCg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0K --_000_11BA5D158C55419BACBC3D2202031280ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCknigJltIG5vdCBzdXJlIHdlIGhhdmUgYSBjbGVh ciBlbm91Z2ggY29tbW9uIHVuZGVyc3RhbmRpbmcgb2Yg4oCcZ2xvYmFs4oCdIGFzIHlldCB0byBi ZSBhYmxlIHRvIHNheSB0aGF0IHdlIHNob3VsZCBtYWtlIHRoZSBwcm92aXNpb25pbmcgb2YgYW4g QUNMIG9uIGFuIGludGVyZmFjZSBvciDigJxnbG9iYWxseeKAnSBtdXR1YWxseSBleGNsdXNpdmUg aW4gdGhlIG1vZGVsLiBJIHRoaW5rIGF0dGFjaGluZyBhbiBBQ0wgdG8gYSBzcGVjaWZpYyBpbnRl cmZhY2UgaW4gZWl0aGVyDQogdGhlIGluZ3Jlc3Mgb3IgZWdyZXNzIGRpcmVjdGlvbiBpcyB3ZWxs LXVuZGVyc3Rvb2QsIGFuZCB3aXRoIGEgc2hhcmVkIHVuZGVyc3RhbmRpbmcgYWNyb3NzIHZlbmRv cnMgYW5kIG9wZXJhdG9ycyBzdWNoIHRoYXQgZWl0aGVyIGFuIGludGVyZmFjZSBhdWdtZW50YXRp b24gb3IgYSDigJxleHRlcm5hbOKAnSBsaXN0ICwgd2l0aCBubyBtZW50aW9uIG9mIGdsb2JhbCwg bWFrZXMgc2Vuc2UuDQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEzIERlYyAy MDE3LCBhdCAyMTowOCwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KWW91IGNhbiB1c2UgdGhlIHNhbWUgQUNMIGRlZmluaXRpb24gdG8g YXR0YWNoIHRvIGRpZmZlcmVudCBwb2ludHMgaW4gdGhlIHN5c3RlbSwgcHJvdmlkZWQgdGhleSBk byBub3Qgb3ZlcmxhcC4gT3RoZXJ3aXNlLCB5b3UgYXJlIGp1c3Qgd2FzdGluZyBDQU0gZW50cmll cy4gR2xvYmFsIGFuZCBpbnRlcmZhY2UgYXR0YWNobWVudCBwb2ludHMgd2lsbCBvdmVybGFwIHdp dGggZWFjaCBvdGhlciwgYmVjYXVzZSBnbG9iYWwgbWVhbnMg4oCYYW554oCZIGludGVyZmFjZS4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMgMTMsIDIwMTcsIGF0 IDEyOjQwIFBNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgJmx0OzxhIGhyZWY9Im1h aWx0bzplaW5hcm5uQGNpc2NvLmNvbSIgY2xhc3M9IiI+ZWluYXJubkBjaXNjby5jb208L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9 IiI+DQpXZSBuZWVkIHRvIGJlIGFibGUgdG8gYXR0YWNoIGFueSBvbmUgQUNMIHRvIGEgd2hvbGUg cmFuZ2Ugb2YgZGlmZmVyZW50IHBsYWNlcy4gSnVzdCBzcGVha2luZyBmcm9tIHRoZSBDaXNjbyBw bGF0Zm9ybSBwZXJzcGVjdGl2ZSwgSSBtYXkgYXR0YWNoIGFuIEFDTCB0bzoNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHVsIGNsYXNzPSJNYWls T3V0bGluZSI+DQo8bGkgY2xhc3M9IiI+SW50ZXJmYWNlczwvbGk+PGxpIGNsYXNzPSIiPk5BVCBj b25maWd1cmF0aW9uPC9saT48bGkgY2xhc3M9IiI+Q2xhc3MgbWFwcyBmb3IgUW9TIHBvbGljeTwv bGk+PGxpIGNsYXNzPSIiPkNsYXNzIG1hcHMgZm9yIEZXIHBvbGljeTwvbGk+PGxpIGNsYXNzPSIi PuKApmV0Y+KApjwvbGk+PC91bD4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPk5vdCBzdXJlIGlmIHdlIGhhdmUgYW55IGdsb2JhbCBhdHRhY2htZW50 IHBvaW50cyB0b2RheSwgYnV0IGlmIHdlIGRpZCwgSeKAmWQgd2FudCB0byBiZSBhYmxlIHRvIHVz ZSB0aGUgc2FtZSBBQ0wgZGVmaW5pdGlvbiBhbnl3aGVyZSBJIG5lZWQgaXQsIG5vdCBpbiBqdXN0 IG9uZSBvbiBOIHBsYWNlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAx MyBEZWMgMjAxNywgYXQgMjA6MjksIE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1h aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9IiI+bWpldGhhbmFuZGFuaUBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB5b3Ugd291 bGQgYXR0YWNoIGFuIEFDTCBlaXRoZXIgdG8gYW4gaW50ZXJmYWNlIDxiIGNsYXNzPSIiPg0Kb3I8 L2I+IGdsb2JhbGx5LiBOb3QgYm90aC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5PbiBEZWMgMTMsIDIwMTcsIGF0IDEyOjI1IFBNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAo ZWluYXJubikgJmx0OzxhIGhyZWY9Im1haWx0bzplaW5hcm5uQGNpc2NvLmNvbSIgY2xhc3M9IiI+ ZWluYXJubkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpJ4oCZbSBoYXBweSB0byBoYXZlIGEgd2F5IHRv IGF0dGFjaCBhbiBBQ0wgZ2xvYmFsbHksIGJ1dCB0aGF04oCZcyBvcnRob2dvbmFsIHRvIGF0dGFj aGluZyB0byBhbiBpbnRlcmZhY2UsIGlzbuKAmXQgaXQ/IEF0dGFjaGluZyBBQ0xzIGRpcmVjdGx5 IHRvIGFuIGludGVyZmFjZSBkb2VzbuKAmXQgcHJlY2x1ZGUgZ2xvYmFsIGF0dGFjaG1lbnQgaW4g YW55IHdheSBhcyBmYXIgYXMgSSBjYW4gc2Vl4oCmb3IgaGF2ZSBJIG1pc3NlZCBzb21ldGhpbmc/ IEnigJltIG5vdCBzdXJlDQogSSB1bmRlcnN0YW5kIHdoeSBjaG9pY2VzIGFyZSBhbiBpc3N1ZS4g VGhlIGN1cnJlbnQgcHJvcG9zYWwgaGFzIHRoaXMgY29udGFpbmVyOg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPm1vZHVsZTogaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0 PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNjZXNzLWxpc3RzPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGF0dGFjaG1lbnQt cG9pbnRzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcncgaW50ZXJmYWNlKiBbaW50ZXJmYWNlLWlkXSB7aW50ZXJmYWNlLWF0dGFjaG1lbnR9 PzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyYjNDM7LS1ydyBpbnRlcmZhY2UtaWQgJm5ic3A7ICZuYnNwO2lmOmludGVyZmFjZS1y ZWY8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0tcncgaW5ncmVzczxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRz PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDstJmd0 OyAuLi8uLi8uLi8uLi8uLi8uLi9hY2wvbmFtZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JiM0MzstLXJ3IHR5cGU/ICZuYnNwOyAtJmd0OyAuLi8uLi8uLi8uLi8uLi8uLi9hY2wv dHlwZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZSogW25h bWVdIHtpbnRlcmZhY2Utc3RhdHMgb3IgaW50ZXJmYWNlLWFjbC1hZ2dyZWdhdGV9PzxiciBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbmFtZSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgLi4vLi4vLi4v Li4vLi4vLi4vLi4vYWNsL2FjZXMvYWNlL25hbWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291 bnRlcjY0PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y byBtYXRjaGVkLW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PGJyIGNsYXNzPSIi Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzst LXJ3IGVncmVzczxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXRzPGJyIGNsYXNzPSIiPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOy0mZ3Q7IC4uLy4uLy4u Ly4uLy4uLy4uL2FjbC9uYW1lPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tcncgdHlwZT8gJm5ic3A7IC0mZ3Q7IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC90eXBlPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gYWNlKiBbbmFtZV0ge2ludGVy ZmFjZS1zdGF0cyBvciBpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZX0/PGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC4uLy4uLy4uLy4uLy4u Ly4uLy4uL2FjbC9hY2VzL2FjZS9uYW1lPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291 bnRlcjY0PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8YnIgY2xh c3M9IiI+DQo8L2ZvbnQ+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHdl IGFkZGVkIHNvbWUgZm9ybSBvZiBnbG9iYWwgYXR0YWNobWVudCBwb2ludHMsIHRoYXQgbWlnaHQg YmUgYSBwZWVyIHdpdGggdGhlIGxpc3Qgb2YgaW50ZXJmYWNlIGF0dGFjaG1lbnRzLCByaWdodD8g QmVjYXVzZSB3ZeKAmWQgbmVlZCB0byBzdXBwb3J0IOKAnGdsb2JhbOKAnSBhbmQgbXVsdGlwbGUg 4oCcaW50ZXJmYWNl4oCdIGF0dGFjaG1lbnRzLiBJdOKAmXMgbm90IGFuIOKAnG9y4oCdLCBpdOKA mXMgYW4g4oCcYW5k4oCdLiBPciBoYXZlIEkgbWlzc2VkDQogc29tZXRoaW5nPzwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiAxMyBEZWMgMjAxNywgYXQgMjA6MTAsIE1haGVzaCBKZXRoYW5h bmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9 IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldlIHdhbnQgdG8g c3VwcG9ydCDigJxnbG9iYWzigJ0gYXR0YWNobWVudCBwb2ludCBkb3duIHRoZSBsaW5lLCBhbmQg dGhhdCDigJxnbG9iYWzigJ0gYXR0YWNobWVudCBwb2ludCB3aWxsIGJlIG9uZSBvZiB0aGUgY2hv aWNlcyAodGhlIG90aGVyIGJlaW5nIHRoZSBpbnRlcmZhY2UpLCB3aGF0IHdvdWxkIHRoaXMgYXVn bWVudCBsb29rIGxpa2UuIE5vdGUsIGFzIGZhciBhcyBJIGtub3csIHlvdSBjYW5ub3QgYXVnbWVu dCBpbnNpZGUgYSBjaG9pY2Ugbm9kZS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5PbiBEZWMgMTMsIDIwMTcsIGF0IDY6NTcgQU0sIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChl aW5hcm5uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVpbmFybm5AY2lzY28uY29tIiBjbGFzcz0iIj5l aW5hcm5uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1p bnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClBlcmhhcHMgbGlrZSB0aGlzLCBhcyBhbiBhdWdt ZW50YXRpb24gdG8gdGhlIGludGVyZmFjZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5v bmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVy ZmFjZXMvaWY6aW50ZXJmYWNlOjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmIzQzOy0tcncgaW5ncmVzcy1hY2xzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW25hbWVd PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7LSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvbmFtZTwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1z dGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZTwvZm9udD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5 YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmIzQz Oy0tcncgZWdyZXNzLWFjbHM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBhY2wtc2V0czwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW25h bWVdPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvdHlwZTwvZm9udD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2Vz L2FjZS9uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLXBhY2tl dHM/ICZuYnNwOyB5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0t cm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q291bGQgYWxzbyBwdXQgYW4g4oCcYWNlc+KAnSBjb250YWlu ZXIgYWJvdmUgYm90aCB0aGVzZSAmYW1wOyByZW5hbWUg4oCcaW5ncmVzcy1hY2xzJnF1b3Q7IHRv IOKAnGluZ3Jlc3PigJ0sIGV0Yy4gdG8gZ2l2ZSBhIHNpbmdsZSByb290IGZvciB0aGUgYXVnbWVu dGF0aW9uIGlmIHByZWZlcnJlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk9uIDYgRGVjIDIwMTcsIGF0IDE5OjQzLCBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWls dG86bGVhckBjaXNjby5jb20iIGNsYXNzPSIiPmxlYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMTIv Ni8xNyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhvdyBkb2VzIG9uZSBtb3ZlIHRoZSBpbnRl cmZhY2UgYXR0YWNobWVudCBwb2ludCwgY3VycmVudGx5IGFuPGJyIGNsYXNzPSIiPg0KJ2ludGVy ZmFjZS1yZWYnLCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlIGlmOmludGVyZmFjZXMvaW50ZXJm YWNlLDxiciBjbGFzcz0iIj4NCmluc2lkZSBvZiB0aGUg4oCYYWNs4oCZICZuYnNwO2NvbnRhaW5l cj8gRG93biB0aGUgbGluZSB3ZSBtaWdodCBuZWVkIHRvIGhhdmUgYW48YnIgY2xhc3M9IiI+DQpj b250YWluZXIgZm9yICZxdW90O2F0dGFjaG1lbnQgcG9pbnRzJnF1b3Q7IHRvIGFjY29tbW9kYXRl IHRoZSBwb3NzaWJpbGl0eSBvZjxiciBjbGFzcz0iIj4NCmF0dGFjaGluZyBhbiBBQ0wgZWl0aGVy IHRvIGFuIGludGVyZmFjZSBvciDigJxnbG9iYWxseeKAnS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpLZWVwaW5nIGluIG1pbmQgdGhh dCBvbmUgdXNlIGlzIHRoYXQgYW4gQUNMIGRvZXNuJ3QgYXR0YWNoIHRvIGFuPGJyIGNsYXNzPSIi Pg0KaW50ZXJmYWNlIGF0IGFsbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5l dG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGll dGYub3JnIiBjbGFzcz0iIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TWFoZXNoIEpldGhhbmFuZGFu aTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb20iIGNsYXNzPSIiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwvZGl2Pg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9 Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9IiI+bWpldGhhbmFuZGFuaUBn bWFpbC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9 IiI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_11BA5D158C55419BACBC3D2202031280ciscocom_-- From nobody Wed Dec 13 13:30:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6E8126D73 for ; Wed, 13 Dec 2017 13:30:34 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.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 vhncOuko-zNz for ; Wed, 13 Dec 2017 13:30:31 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (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 3EFF71242EA for ; Wed, 13 Dec 2017 13:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1513200457; bh=0FSJGIaUvGeD1xsAogEX6/WsxPKu3UQmDu+tutLzW8E=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=tJ9J485nfWXDTb9lVJCRX9chh2UJvKvAJXKAyYjyym1vyABoychTqfJ63kpHYFZVS jODhn/Ihq47LyrkCbcp9aEv6pP8RdP613HhzXPXt8ZbmEqk/ltXzkQ1dEzJFpy5MkW LjGfHum6TkaFbO4AzOpa32KL99tt3PJffTE72v4c= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Thomas Nadeau Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F4823C4F-71CF-4210-976E-D46D0DDF7750" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 13 Dec 2017 16:30:22 -0500 In-Reply-To: <11BA5D15-8C55-419B-ACBC-3D2202031280@cisco.com> Cc: Mahesh Jethanandani , "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> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@cisco.com> <5CBC1C7B-FB4C-4313-9BE3-BEF618C62DA2@gmail.com> <11BA5D15-8C55-419B-ACBC-3D2202031280@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=White (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 944, in=7448, out=0, spam=0 Known=true ip=50.255.148.181 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, 13 Dec 2017 21:30:34 -0000 --Apple-Mail=_F4823C4F-71CF-4210-976E-D46D0DDF7750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Maybe it would help to say =E2=80=9Cto all interfaces=E2=80=9D = instead of =E2=80=9Cglobally=E2=80=9D?=20 =E2=80=94Tom > On Dec 13, 2017, at 4:15 PM, Einar Nilsen-Nygaard (einarnn) = wrote: >=20 > I=E2=80=99m not sure we have a clear enough common understanding of = =E2=80=9Cglobal=E2=80=9D as yet to be able to say that we should make = the provisioning of an ACL on an interface or =E2=80=9Cglobally=E2=80=9D = mutually exclusive in the model. I think attaching an ACL to a specific = interface in either the ingress or egress direction is well-understood, = and with a shared understanding across vendors and operators such that = either an interface augmentation or a =E2=80=9Cexternal=E2=80=9D list , = with no mention of global, makes sense. >=20 > Cheers, >=20 > Einar >=20 >> On 13 Dec 2017, at 21:08, Mahesh Jethanandani = > wrote: >>=20 >> You can use the same ACL definition to attach to different points in = the system, provided they do not overlap. Otherwise, you are just = wasting CAM entries. Global and interface attachment points will overlap = with each other, because global means =E2=80=98any=E2=80=99 interface. >>=20 >>> On Dec 13, 2017, at 12:40 PM, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>=20 >>> We need to be able to attach any one ACL to a whole range of = different places. Just speaking from the Cisco platform perspective, I = may attach an ACL to: >>>=20 >>> Interfaces >>> NAT configuration >>> Class maps for QoS policy >>> Class maps for FW policy >>> =E2=80=A6etc=E2=80=A6 >>>=20 >>> Not sure if we have any global attachment points today, but if we = did, I=E2=80=99d want to be able to use the same ACL definition anywhere = I need it, not in just one on N places. >>>=20 >>> Cheers, >>>=20 >>> Einar >>>=20 >>>> On 13 Dec 2017, at 20:29, Mahesh Jethanandani = > wrote: >>>>=20 >>>> My understanding is that you would attach an ACL either to an = interface or globally. Not both. >>>>=20 >>>>> On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) = > wrote: >>>>>=20 >>>>> I=E2=80=99m happy to have a way to attach an ACL globally, but = that=E2=80=99s orthogonal to attaching to an interface, isn=E2=80=99t = it? Attaching ACLs directly to an interface doesn=E2=80=99t preclude = global attachment in any way as far as I can see=E2=80=A6or have I = missed something? I=E2=80=99m not sure I understand why choices are an = issue. The current proposal has this container: >>>>>=20 >>>>> module: ietf-access-control-list >>>>> +--rw access-lists >>>>> +--rw attachment-points >>>>> +--rw interface* [interface-id] {interface-attachment}? >>>>> +--rw interface-id if:interface-ref >>>>> +--rw ingress >>>>> | +--rw acl-sets >>>>> | +--rw acl-set* [name] >>>>> | +--rw name -> ../../../../../../acl/name >>>>> | +--rw type? -> ../../../../../../acl/type >>>>> | +--ro ace* [name] {interface-stats or = interface-acl-aggregate}? >>>>> | +--ro name -> = ../../../../../../../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 -> ../../../../../../acl/name >>>>> +--rw type? -> ../../../../../../acl/type >>>>> +--ro ace* [name] {interface-stats or = interface-acl-aggregate}? >>>>> +--ro name -> = ../../../../../../../acl/aces/ace/name >>>>> +--ro matched-packets? yang:counter64 >>>>> +--ro matched-octets? yang:counter64 >>>>>=20 >>>>> If we added some form of global attachment points, that might be a = peer with the list of interface attachments, right? Because we=E2=80=99d = need to support =E2=80=9Cglobal=E2=80=9D and multiple =E2=80=9Cinterface=E2= =80=9D attachments. It=E2=80=99s not an =E2=80=9Cor=E2=80=9D, it=E2=80=99s= an =E2=80=9Cand=E2=80=9D. Or have I missed something? >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Einar >>>>>=20 >>>>>> On 13 Dec 2017, at 20:10, Mahesh Jethanandani = > wrote: >>>>>>=20 >>>>>> 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 >>>>=20 >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_F4823C4F-71CF-4210-976E-D46D0DDF7750 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Maybe it would help to say =E2=80=9C= to all interfaces=E2=80=9D instead of =E2=80=9Cglobally=E2=80=9D? 
= =E2=80=94Tom


On Dec = 13, 2017, at 4:15 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> = wrote:

I=E2=80=99m not sure we have a clear enough common understanding of = =E2=80=9Cglobal=E2=80=9D as yet to be able to say that we should make = the provisioning of an ACL on an interface or =E2=80=9Cglobally=E2=80=9D = mutually exclusive in the model. I think attaching an ACL to a specific = interface in either the ingress or egress direction is well-understood, and with a shared = understanding across vendors and operators such that either an interface = augmentation or a =E2=80=9Cexternal=E2=80=9D list , with no mention of = global, makes sense.

Cheers,

Einar

On 13 Dec 2017, at 21:08, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

You can use the same ACL definition to attach to different points in the = system, provided they do not overlap. Otherwise, you are just wasting = CAM entries. Global and interface attachment points will overlap with = each other, because global means =E2=80=98any=E2=80=99 interface.

On Dec 13, 2017, at 12:40 PM, Einar Nilsen-Nygaard = (einarnn) <einarnn@cisco.com> wrote:

We need to be able to attach any one ACL to a whole range of different = places. Just speaking from the Cisco platform perspective, I may attach = an ACL to:

  • Interfaces
  • NAT configuration
  • Class maps for QoS policy
  • Class maps for = FW policy
  • =E2=80=A6etc=E2=80=A6

Not sure if we have any global attachment points today, = but if we did, I=E2=80=99d want to be able to use the same ACL = definition anywhere I need it, not in just one on N places.

Cheers,

Einar

On 13 Dec 2017, at 20:29, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

My understanding is that you would attach an ACL either to an interface = or globally. Not both.

On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard = (einarnn) <einarnn@cisco.com> wrote:

I=E2=80=99m happy to have a way to attach an ACL globally, but that=E2=80=99= s orthogonal to attaching to an interface, isn=E2=80=99t it? Attaching = ACLs directly to an interface doesn=E2=80=99t preclude global attachment = in any way as far as I can see=E2=80=A6or have I missed something? I=E2=80= =99m not sure I understand why choices are an issue. The current proposal has this = container:

module: = ietf-access-control-list
    +--rw access-lists
       +--rw attachment-points
          +--rw interface* [interface-id] = {interface-attachment}?
             +--rw interface-id =    if:interface-ref
             +--rw ingress
             |  +--rw = acl-sets
             |     +--rw = acl-set* [name]
             |       =  +--rw name    -> ../../../../../../acl/name
             |       =  +--rw type?   -> ../../../../../../acl/type
             |       =  +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
             |       =     +--ro name             =   -> ../../../../../../../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    -> ../../../../../../acl/name
                    =   +--rw type?   -> ../../../../../../acl/type
                    =   +--ro ace* [name] {interface-stats or = interface-acl-aggregate}?
                    =      +--ro name             =   -> ../../../../../../../acl/aces/ace/name
                    =      +--ro matched-packets?   yang:counter64
                    =      +--ro matched-octets?    yang:counter64

If we added some form of global attachment points, that = might be a peer with the list of interface attachments, right? Because = we=E2=80=99d need to support =E2=80=9Cglobal=E2=80=9D and multiple = =E2=80=9Cinterface=E2=80=9D attachments. It=E2=80=99s not an =E2=80=9Cor=E2= =80=9D, it=E2=80=99s an =E2=80=9Cand=E2=80=9D. Or have I missed something?

Cheers,

Einar

On 13 Dec 2017, at 20:10, 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



Mahesh Jethanandani
mjethanandani@gmail.com



Mahesh Jethanandani
mjethanandani@gmail.com


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

= --Apple-Mail=_F4823C4F-71CF-4210-976E-D46D0DDF7750-- From nobody Wed Dec 13 16:02:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C571243FE for ; Wed, 13 Dec 2017 16:02:41 -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, 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 rC3ijnTvF2z9 for ; Wed, 13 Dec 2017 16:02:39 -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 714361201F8 for ; Wed, 13 Dec 2017 16:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49010; q=dns/txt; s=iport; t=1513209758; x=1514419358; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i7SKotB1qmmQWeXlCKWm2P6cr9Mz7dh0DX10RhIFlo4=; b=C+EobeuqDGDTWnks3mOscrDQKBTiKFq/rD0M+/JFdWlNVUolkduOTQmT DfaCxl5QojFfRJo+V+tTes8QmP5zkp81Li3RXHgrI7Gl5F0+Q2DkKWFxW D3pHhh+660Rqiww3nPCgbsbYaMqKY2zyaI0AJ36gl5Onue63QXF04EOVu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAABxvjFa/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0JweDe4ohjweKdY4ZghUKGAEKhElPAhqEeT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFJAIEAQEhBEcLEAIBCA4qAQYDAgICHwYLFBECBA4FiURMAxUQqR2Bb?= =?us-ascii?q?TqHOA2DGwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg2CCC4NogwKCakQBgW03gl8?= =?us-ascii?q?xgjIFkhSQTj0CkCiEfZNojU2FVoMWAhEZAYE6AR85gU5vFToqAYF+P4IUHIFne?= =?us-ascii?q?IkXgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,398,1508803200"; d="scan'208,217";a="321704999" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 00:02:37 +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 vBE02aTY014396 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 00:02:37 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; Wed, 13 Dec 2017 19:02:36 -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, 13 Dec 2017 19:02:36 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Thomas Nadeau CC: Mahesh Jethanandani , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAABBMAgAABOICAAAMrAIAAB9gAgAAB4ICAAAQdAIAAKpIA Date: Thu, 14 Dec 2017 00:02:35 +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> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com> <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@cisco.com> <5CBC1C7B-FB4C-4313-9BE3-BEF618C62DA2@gmail.com> <11BA5D15-8C55-419B-ACBC-3D2202031280@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.210.168] Content-Type: multipart/alternative; boundary="_000_B4AB3AB0A5B74B3D94C483768ACB723Dciscocom_" 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, 14 Dec 2017 00:02:42 -0000 --_000_B4AB3AB0A5B74B3D94C483768ACB723Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9tLA0KDQpJZiB3ZSB3ZXJlIHRvIGludHJvZHVjZSB0aGlzLCB5ZXMsIHRoYXQgKG9yIHNvbWUg c2ltaWxhciB0ZXJtKSBtYXkgaGVscCBjbGFyaWZ5LiBCdXQgSSB0aGluayB0aGF0IGF0IHRoZSBt b21lbnQgd2UgaGF2ZSBzdWdnZXN0ZWQgdGhhdCB3ZSBsZWF2ZSB0aGlzIGlzc3VlIG91dCBvZiB0 aGUgaW5pdGlhbCBkcmFmdCB1bnRpbCBpdCBpcyBiZXR0ZXIgdW5kZXJzdG9vZCB3aGF0IHdlIHNo b3VsZCBzcGVjaWZ5Lg0KDQpJIHRoaW5rIHRoZSBxdWVzdGlvbiBhdCB0aGlzIHBvaW50IGlzIHdo ZXRoZXIgZXhwbGljaXQgQUNMIHRvIGludGVyZmFjZSBiaW5kaW5nIHNob3VsZCBiZSBkb25lIHZp YSBpbnRlcmZhY2UgYXVnbWVudGF0aW9ucyBvciB2aWEgYSBsaXN0IG9mIGludGVyZmFjZSByZWZl cmVuY2VzIGluIHRoZSBBQ0wgbW9kZWwuIEJvdGggZXhhbXBsZXMgYXJlIHNob3duIGJlbG93LCBi dXQgSeKAmWxsIHB1bGwgdGhlbSB1cCBmb3IgY2xhcml0eToNCg0KIG1vZHVsZTogaWV0Zi1hY2Nl c3MtY29udHJvbC1saXN0DQogIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0K ICAgICstLXJ3IGluZ3Jlc3MtYWNscw0KICAgIHwgICstLXJ3IGFjbC1zZXRzDQogICAgfCAgICAg Ky0tcncgYWNsLXNldCogW25hbWVdDQogICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAg ICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAg ICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICB8ICAgICAgICArLS1ybyBh Y2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgIHwgICAgICAgICAg ICstLXJvIG5hbWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9u YW1lDQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRl cjY0DQogICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRl cjY0DQogICAgKy0tcncgZWdyZXNzLWFjbHMNCiAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAg ICAgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAg ICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICAgICAgICArLS1ydyB0eXBl PyAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgICAgICAgKy0t cm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAgICAgICAg ICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9h Y2UvbmFtZQ0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNv dW50ZXI2NA0KICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNv dW50ZXI2NA0KDQogbW9kdWxlOiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QNCiAgICArLS1ydyBh Y2Nlc3MtbGlzdHMNCiAgICAgICArLS1ydyBhdHRhY2htZW50LXBvaW50cw0KICAgICAgICAgICst LXJ3IGludGVyZmFjZSogW2ludGVyZmFjZS1pZF0ge2ludGVyZmFjZS1hdHRhY2htZW50fT8NCiAg ICAgICAgICAgICArLS1ydyBpbnRlcmZhY2UtaWQgICAgaWY6aW50ZXJmYWNlLXJlZg0KICAgICAg ICAgICAgICstLXJ3IGluZ3Jlc3MNCiAgICAgICAgICAgICB8ICArLS1ydyBhY2wtc2V0cw0KICAg ICAgICAgICAgIHwgICAgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgIHwgICAg ICAgICstLXJ3IG5hbWUgICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vYWNsL25hbWUNCiAgICAgICAg ICAgICB8ICAgICAgICArLS1ydyB0eXBlPyAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC90eXBl DQogICAgICAgICAgICAgfCAgICAgICAgKy0tcm8gYWNlKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0 cyBvciBpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZX0/DQogICAgICAgICAgICAgfCAgICAgICAgICAg Ky0tcm8gbmFtZSAgICAgICAgICAgICAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uLy4uL2FjbC9hY2Vz L2FjZS9uYW1lDQogICAgICAgICAgICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRz PyAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgICAgICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hl ZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgICAgICAgKy0tcncgZWdyZXNzDQog ICAgICAgICAgICAgICAgKy0tcncgYWNsLXNldHMNCiAgICAgICAgICAgICAgICAgICArLS1ydyBh Y2wtc2V0KiBbbmFtZV0NCiAgICAgICAgICAgICAgICAgICAgICArLS1ydyBuYW1lICAgIC0+IC4u Ly4uLy4uLy4uLy4uLy4uL2FjbC9uYW1lDQogICAgICAgICAgICAgICAgICAgICAgKy0tcncgdHlw ZT8gICAtPiAuLi8uLi8uLi8uLi8uLi8uLi9hY2wvdHlwZQ0KICAgICAgICAgICAgICAgICAgICAg ICstLXJvIGFjZSogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHMgb3IgaW50ZXJmYWNlLWFjbC1hZ2dy ZWdhdGV9Pw0KICAgICAgICAgICAgICAgICAgICAgICAgICstLXJvIG5hbWUgICAgICAgICAgICAg ICAtPiAuLi8uLi8uLi8uLi8uLi8uLi8uLi9hY2wvYWNlcy9hY2UvbmFtZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNvdW50ZXI2NA0KICAg ICAgICAgICAgICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNvdW50 ZXI2NA0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCk9uIDEzIERlYyAyMDE3LCBhdCAyMTozMCwgVGhv bWFzIE5hZGVhdSA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb208bWFpbHRvOnRuYWRlYXVAbHVjaWR2 aXNpb24uY29tPj4gd3JvdGU6DQoNCg0KTWF5YmUgaXQgd291bGQgaGVscCB0byBzYXkg4oCcdG8g YWxsIGludGVyZmFjZXPigJ0gaW5zdGVhZCBvZiDigJxnbG9iYWxseeKAnT8NCg0K4oCUVG9tDQoN Cg0KT24gRGVjIDEzLCAyMDE3LCBhdCA0OjE1IFBNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWlu YXJubikgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdyb3Rl Og0KDQpJ4oCZbSBub3Qgc3VyZSB3ZSBoYXZlIGEgY2xlYXIgZW5vdWdoIGNvbW1vbiB1bmRlcnN0 YW5kaW5nIG9mIOKAnGdsb2JhbOKAnSBhcyB5ZXQgdG8gYmUgYWJsZSB0byBzYXkgdGhhdCB3ZSBz aG91bGQgbWFrZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGFuIEFDTCBvbiBhbiBpbnRlcmZhY2Ugb3Ig 4oCcZ2xvYmFsbHnigJ0gbXV0dWFsbHkgZXhjbHVzaXZlIGluIHRoZSBtb2RlbC4gSSB0aGluayBh dHRhY2hpbmcgYW4gQUNMIHRvIGEgc3BlY2lmaWMgaW50ZXJmYWNlIGluIGVpdGhlciB0aGUgaW5n cmVzcyBvciBlZ3Jlc3MgZGlyZWN0aW9uIGlzIHdlbGwtdW5kZXJzdG9vZCwgYW5kIHdpdGggYSBz aGFyZWQgdW5kZXJzdGFuZGluZyBhY3Jvc3MgdmVuZG9ycyBhbmQgb3BlcmF0b3JzIHN1Y2ggdGhh dCBlaXRoZXIgYW4gaW50ZXJmYWNlIGF1Z21lbnRhdGlvbiBvciBhIOKAnGV4dGVybmFs4oCdIGxp c3QgLCB3aXRoIG5vIG1lbnRpb24gb2YgZ2xvYmFsLCBtYWtlcyBzZW5zZS4NCg0KQ2hlZXJzLA0K DQpFaW5hcg0KDQpPbiAxMyBEZWMgMjAxNywgYXQgMjE6MDgsIE1haGVzaCBKZXRoYW5hbmRhbmkg PG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+ IHdyb3RlOg0KDQpZb3UgY2FuIHVzZSB0aGUgc2FtZSBBQ0wgZGVmaW5pdGlvbiB0byBhdHRhY2gg dG8gZGlmZmVyZW50IHBvaW50cyBpbiB0aGUgc3lzdGVtLCBwcm92aWRlZCB0aGV5IGRvIG5vdCBv dmVybGFwLiBPdGhlcndpc2UsIHlvdSBhcmUganVzdCB3YXN0aW5nIENBTSBlbnRyaWVzLiBHbG9i YWwgYW5kIGludGVyZmFjZSBhdHRhY2htZW50IHBvaW50cyB3aWxsIG92ZXJsYXAgd2l0aCBlYWNo IG90aGVyLCBiZWNhdXNlIGdsb2JhbCBtZWFucyDigJhhbnnigJkgaW50ZXJmYWNlLg0KDQpPbiBE ZWMgMTMsIDIwMTcsIGF0IDEyOjQwIFBNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikg PGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpX ZSBuZWVkIHRvIGJlIGFibGUgdG8gYXR0YWNoIGFueSBvbmUgQUNMIHRvIGEgd2hvbGUgcmFuZ2Ug b2YgZGlmZmVyZW50IHBsYWNlcy4gSnVzdCBzcGVha2luZyBmcm9tIHRoZSBDaXNjbyBwbGF0Zm9y bSBwZXJzcGVjdGl2ZSwgSSBtYXkgYXR0YWNoIGFuIEFDTCB0bzoNCg0KDQogICogICBJbnRlcmZh Y2VzDQogICogICBOQVQgY29uZmlndXJhdGlvbg0KICAqICAgQ2xhc3MgbWFwcyBmb3IgUW9TIHBv bGljeQ0KICAqICAgQ2xhc3MgbWFwcyBmb3IgRlcgcG9saWN5DQogICogICDigKZldGPigKYNCg0K Tm90IHN1cmUgaWYgd2UgaGF2ZSBhbnkgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnRzIHRvZGF5LCBi dXQgaWYgd2UgZGlkLCBJ4oCZZCB3YW50IHRvIGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIEFDTCBk ZWZpbml0aW9uIGFueXdoZXJlIEkgbmVlZCBpdCwgbm90IGluIGp1c3Qgb25lIG9uIE4gcGxhY2Vz Lg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCk9uIDEzIERlYyAyMDE3LCBhdCAyMDoyOSwgTWFoZXNo IEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB5b3Ugd291 bGQgYXR0YWNoIGFuIEFDTCBlaXRoZXIgdG8gYW4gaW50ZXJmYWNlIG9yIGdsb2JhbGx5LiBOb3Qg Ym90aC4NCg0KT24gRGVjIDEzLCAyMDE3LCBhdCAxMjoyNSBQTSwgRWluYXIgTmlsc2VuLU55Z2Fh cmQgKGVpbmFybm4pIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+ PiB3cm90ZToNCg0KSeKAmW0gaGFwcHkgdG8gaGF2ZSBhIHdheSB0byBhdHRhY2ggYW4gQUNMIGds b2JhbGx5LCBidXQgdGhhdOKAmXMgb3J0aG9nb25hbCB0byBhdHRhY2hpbmcgdG8gYW4gaW50ZXJm YWNlLCBpc27igJl0IGl0PyBBdHRhY2hpbmcgQUNMcyBkaXJlY3RseSB0byBhbiBpbnRlcmZhY2Ug ZG9lc27igJl0IHByZWNsdWRlIGdsb2JhbCBhdHRhY2htZW50IGluIGFueSB3YXkgYXMgZmFyIGFz IEkgY2FuIHNlZeKApm9yIGhhdmUgSSBtaXNzZWQgc29tZXRoaW5nPyBJ4oCZbSBub3Qgc3VyZSBJ IHVuZGVyc3RhbmQgd2h5IGNob2ljZXMgYXJlIGFuIGlzc3VlLiBUaGUgY3VycmVudCBwcm9wb3Nh bCBoYXMgdGhpcyBjb250YWluZXI6DQoNCm1vZHVsZTogaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0 DQogICAgKy0tcncgYWNjZXNzLWxpc3RzDQogICAgICAgKy0tcncgYXR0YWNobWVudC1wb2ludHMN CiAgICAgICAgICArLS1ydyBpbnRlcmZhY2UqIFtpbnRlcmZhY2UtaWRdIHtpbnRlcmZhY2UtYXR0 YWNobWVudH0/DQogICAgICAgICAgICAgKy0tcncgaW50ZXJmYWNlLWlkICAgIGlmOmludGVyZmFj ZS1yZWYNCiAgICAgICAgICAgICArLS1ydyBpbmdyZXNzDQogICAgICAgICAgICAgfCAgKy0tcncg YWNsLXNldHMNCiAgICAgICAgICAgICB8ICAgICArLS1ydyBhY2wtc2V0KiBbbmFtZV0NCiAgICAg ICAgICAgICB8ICAgICAgICArLS1ydyBuYW1lICAgIC0+IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC9u YW1lDQogICAgICAgICAgICAgfCAgICAgICAgKy0tcncgdHlwZT8gICAtPiAuLi8uLi8uLi8uLi8u Li8uLi9hY2wvdHlwZQ0KICAgICAgICAgICAgIHwgICAgICAgICstLXJvIGFjZSogW25hbWVdIHtp bnRlcmZhY2Utc3RhdHMgb3IgaW50ZXJmYWNlLWFjbC1hZ2dyZWdhdGV9Pw0KICAgICAgICAgICAg IHwgICAgICAgICAgICstLXJvIG5hbWUgICAgICAgICAgICAgICAtPiAuLi8uLi8uLi8uLi8uLi8u Li8uLi9hY2wvYWNlcy9hY2UvbmFtZQ0KICAgICAgICAgICAgIHwgICAgICAgICAgICstLXJvIG1h dGNoZWQtcGFja2V0cz8gICB5YW5nOmNvdW50ZXI2NA0KICAgICAgICAgICAgIHwgICAgICAgICAg ICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNvdW50ZXI2NA0KICAgICAgICAgICAgICst LXJ3IGVncmVzcw0KICAgICAgICAgICAgICAgICstLXJ3IGFjbC1zZXRzDQogICAgICAgICAgICAg ICAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgICAgICAgICAgICAgICAgICAgKy0tcncg bmFtZSAgICAtPiAuLi8uLi8uLi8uLi8uLi8uLi9hY2wvbmFtZQ0KICAgICAgICAgICAgICAgICAg ICAgICstLXJ3IHR5cGU/ICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vYWNsL3R5cGUNCiAgICAgICAg ICAgICAgICAgICAgICArLS1ybyBhY2UqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzIG9yIGludGVy ZmFjZS1hY2wtYWdncmVnYXRlfT8NCiAgICAgICAgICAgICAgICAgICAgICAgICArLS1ybyBuYW1l ICAgICAgICAgICAgICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vLi4vYWNsL2FjZXMvYWNlL25hbWUN CiAgICAgICAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpj b3VudGVyNjQNCiAgICAgICAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8g ICAgeWFuZzpjb3VudGVyNjQNCg0KSWYgd2UgYWRkZWQgc29tZSBmb3JtIG9mIGdsb2JhbCBhdHRh Y2htZW50IHBvaW50cywgdGhhdCBtaWdodCBiZSBhIHBlZXIgd2l0aCB0aGUgbGlzdCBvZiBpbnRl cmZhY2UgYXR0YWNobWVudHMsIHJpZ2h0PyBCZWNhdXNlIHdl4oCZZCBuZWVkIHRvIHN1cHBvcnQg 4oCcZ2xvYmFs4oCdIGFuZCBtdWx0aXBsZSDigJxpbnRlcmZhY2XigJ0gYXR0YWNobWVudHMuIEl0 4oCZcyBub3QgYW4g4oCcb3LigJ0sIGl04oCZcyBhbiDigJxhbmTigJ0uIE9yIGhhdmUgSSBtaXNz ZWQgc29tZXRoaW5nPw0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCk9uIDEzIERlYyAyMDE3LCBhdCAy MDoxMCwgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCldlIHdhbnQgdG8gc3VwcG9ydCDi gJxnbG9iYWzigJ0gYXR0YWNobWVudCBwb2ludCBkb3duIHRoZSBsaW5lLCBhbmQgdGhhdCDigJxn bG9iYWzigJ0gYXR0YWNobWVudCBwb2ludCB3aWxsIGJlIG9uZSBvZiB0aGUgY2hvaWNlcyAodGhl IG90aGVyIGJlaW5nIHRoZSBpbnRlcmZhY2UpLCB3aGF0IHdvdWxkIHRoaXMgYXVnbWVudCBsb29r IGxpa2UuIE5vdGUsIGFzIGZhciBhcyBJIGtub3csIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUg YSBjaG9pY2Ugbm9kZS4NCg0KT24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBFaW5hciBOaWxz ZW4tTnlnYWFyZCAoZWluYXJubikgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNp c2NvLmNvbT4+IHdyb3RlOg0KDQpQZXJoYXBzIGxpa2UgdGhpcywgYXMgYW4gYXVnbWVudGF0aW9u IHRvIHRoZSBpbnRlcmZhY2U6DQoNCiAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZh Y2U6DQogICAgKy0tcncgaW5ncmVzcy1hY2xzDQogICAgfCAgKy0tcncgYWNsLXNldHMNCiAgICB8 ICAgICArLS1ydyBhY2wtc2V0KiBbbmFtZV0NCiAgICB8ICAgICAgICArLS1ydyBuYW1lICAgICAg ICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgfCAgICAgICAgKy0tcncgdHlw ZT8gICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgIHwgICAgICAgICst LXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgfCAgICAg ICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMv YWNlL25hbWUNCiAgICB8ICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpj b3VudGVyNjQNCiAgICB8ICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpj b3VudGVyNjQNCiAgICArLS1ydyBlZ3Jlc3MtYWNscw0KICAgICAgICstLXJ3IGFjbC1zZXRzDQog ICAgICAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgICAgICAgICAgKy0tcncgbmFtZSAg ICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgICAgICAgICAgICstLXJ3 IHR5cGU/ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICAgICAgICAg ICArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgICAg ICAgICAgICAgICstLXJvIG5hbWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9h Y2VzL2FjZS9uYW1lDQogICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlh bmc6Y291bnRlcjY0DQogICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlh bmc6Y291bnRlcjY0DQoNCkNvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFpbmVyIGFi b3ZlIGJvdGggdGhlc2UgJiByZW5hbWUg4oCcaW5ncmVzcy1hY2xzIiB0byDigJxpbmdyZXNz4oCd LCBldGMuIHRvIGdpdmUgYSBzaW5nbGUgcm9vdCBmb3IgdGhlIGF1Z21lbnRhdGlvbiBpZiBwcmVm ZXJyZWQuDQoNCkNoZWVycywNCg0KRWluYXINCg0KDQpPbiA2IERlYyAyMDE3LCBhdCAxOTo0Mywg RWxpb3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6 DQoNCg0KDQpPbiAxMi82LzE3IDc6MjMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6DQpI b3cgZG9lcyBvbmUgbW92ZSB0aGUgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsIGN1cnJlbnRs eSBhbg0KJ2ludGVyZmFjZS1yZWYnLCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlIGlmOmludGVy ZmFjZXMvaW50ZXJmYWNlLA0KaW5zaWRlIG9mIHRoZSDigJhhY2zigJkgIGNvbnRhaW5lcj8gRG93 biB0aGUgbGluZSB3ZSBtaWdodCBuZWVkIHRvIGhhdmUgYW4NCmNvbnRhaW5lciBmb3IgImF0dGFj aG1lbnQgcG9pbnRzIiB0byBhY2NvbW1vZGF0ZSB0aGUgcG9zc2liaWxpdHkgb2YNCmF0dGFjaGlu ZyBhbiBBQ0wgZWl0aGVyIHRvIGFuIGludGVyZmFjZSBvciDigJxnbG9iYWxseeKAnS4NCg0KDQpL ZWVwaW5nIGluIG1pbmQgdGhhdCBvbmUgdXNlIGlzIHRoYXQgYW4gQUNMIGRvZXNuJ3QgYXR0YWNo IHRvIGFuDQppbnRlcmZhY2UgYXQgYWxsLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0KDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCk1haGVzaCBKZXRo YW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdt YWlsLmNvbT4NCg0KDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg== --_000_B4AB3AB0A5B74B3D94C483768ACB723Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <28E4663508A4584DB7ACA7FA0CBC73A0@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRvbSwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHdlIHdlcmUgdG8gaW50cm9kdWNlIHRoaXMs IHllcywgdGhhdCAob3Igc29tZSBzaW1pbGFyIHRlcm0pIG1heSBoZWxwIGNsYXJpZnkuIEJ1dCBJ IHRoaW5rIHRoYXQgYXQgdGhlIG1vbWVudCB3ZSBoYXZlIHN1Z2dlc3RlZCB0aGF0IHdlIGxlYXZl IHRoaXMgaXNzdWUgb3V0IG9mIHRoZSBpbml0aWFsIGRyYWZ0IHVudGlsIGl0IGlzIGJldHRlciB1 bmRlcnN0b29kIHdoYXQgd2Ugc2hvdWxkIHNwZWNpZnkuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5rIHRoZSBxdWVzdGlvbiBhdCB0aGlz IHBvaW50IGlzIHdoZXRoZXIgZXhwbGljaXQgQUNMIHRvIGludGVyZmFjZSBiaW5kaW5nIHNob3Vs ZCBiZSBkb25lIHZpYSBpbnRlcmZhY2UgYXVnbWVudGF0aW9ucyBvciB2aWEgYSBsaXN0IG9mIGlu dGVyZmFjZSByZWZlcmVuY2VzIGluIHRoZSBBQ0wgbW9kZWwuIEJvdGggZXhhbXBsZXMgYXJlIHNo b3duIGJlbG93LCBidXQgSeKAmWxsIHB1bGwgdGhlbSB1cCBmb3IgY2xhcml0eTo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7 bW9kdWxlOiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7IGF1Z21lbnQg L2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyBpbmdyZXNzLWFjbHM8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1y dyBhY2wtc2V0czwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IENvdXJpZXI7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0t cncgYWNsLXNldCogW25hbWVdPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQ291cmllcjsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiIGNsYXNzPSIi PiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgdHlw ZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vz cy1saXN0cy9hY2wvdHlwZTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENvdXJpZXI7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1z dGF0c30/PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291 cmllcjsiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9z cGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ybyBtYXRjaGVkLXBhY2tldHM/ICZuYnNwOyB5YW5nOmNvdW50ZXI2NDwvc3Bhbj48 YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvc3Bhbj48 YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBlZ3Jlc3MtYWNsczwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXI7IiBjbGFzcz0iIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldHM8L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiIGNsYXNzPSIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1y dyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0m Z3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHR5cGU/ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGU8 L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/PC9zcGFu PjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllcjsiIGNsYXNz PSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWU8L3NwYW4+PGJy IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyOyIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L3NwYW4+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5n OmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+Jm5ic3A7bW9kdWxlOiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q8YnIg Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2Nlc3MtbGlzdHM8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYXR0YWNobWVudC1wb2lu dHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyBpbnRlcmZhY2UqIFtpbnRlcmZhY2UtaWRdIHtpbnRlcmZhY2UtYXR0YWNobWVudH0/PGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7JiM0MzstLXJ3IGludGVyZmFjZS1pZCAmbmJzcDsgJm5ic3A7aWY6aW50ZXJmYWNlLXJlZjxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyBpbmdyZXNzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgYWNsLXNldHM8YnIg Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOy0mZ3Q7IC4u Ly4uLy4uLy4uLy4uLy4uL2FjbC9uYW1lPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7IC0mZ3Q7IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC90eXBl PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlKiBbbmFtZV0g e2ludGVyZmFjZS1zdGF0cyBvciBpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZX0/PGJyIGNsYXNzPSIi Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAuLi8uLi8uLi8uLi8u Li8uLi8uLi9hY2wvYWNlcy9hY2UvbmFtZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVy NjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1h dGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncg ZWdyZXNzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldHM8YnIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7LSZndDsgLi4vLi4vLi4vLi4v Li4vLi4vYWNsL25hbWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyB0eXBlPyAmbmJzcDsgLSZndDsgLi4vLi4vLi4vLi4vLi4vLi4vYWNsL3R5cGU8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBhY2UqIFtuYW1lXSB7aW50ZXJmYWNl LXN0YXRzIG9yIGludGVyZmFjZS1hY2wtYWdncmVnYXRlfT88YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgLi4vLi4vLi4vLi4vLi4vLi4v Li4vYWNsL2FjZXMvYWNlL25hbWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVy NjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0t cm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWluYXI8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEzIERlYyAyMDE3LCBhdCAyMTozMCwgVGhv bWFzIE5hZGVhdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tIiBj bGFzcz0iIj50bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxl PSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5NYXliZSBpdCB3b3VsZCBoZWxwIHRvIHNheSDigJx0 byBhbGwgaW50ZXJmYWNlc+KAnSBpbnN0ZWFkIG9mIOKAnGdsb2JhbGx54oCdPyZuYnNwOw0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+4oCUVG9t PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pk9uIERlYyAxMywgMjAxNywgYXQgNDoxNSBQTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFy bm4pICZsdDs8YSBocmVmPSJtYWlsdG86ZWluYXJubkBjaXNjby5jb20iIGNsYXNzPSIiPmVpbmFy bm5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSeKAmW0gbm90IHN1cmUgd2UgaGF2ZSBhIGNsZWFyIGVu b3VnaCBjb21tb24gdW5kZXJzdGFuZGluZyBvZiDigJxnbG9iYWzigJ0gYXMgeWV0IHRvIGJlIGFi bGUgdG8gc2F5IHRoYXQgd2Ugc2hvdWxkIG1ha2UgdGhlIHByb3Zpc2lvbmluZyBvZiBhbiBBQ0wg b24gYW4gaW50ZXJmYWNlIG9yIOKAnGdsb2JhbGx54oCdIG11dHVhbGx5IGV4Y2x1c2l2ZSBpbiB0 aGUgbW9kZWwuIEkgdGhpbmsgYXR0YWNoaW5nIGFuIEFDTCB0byBhIHNwZWNpZmljIGludGVyZmFj ZSBpbiBlaXRoZXINCiB0aGUgaW5ncmVzcyBvciBlZ3Jlc3MgZGlyZWN0aW9uIGlzIHdlbGwtdW5k ZXJzdG9vZCwgYW5kIHdpdGggYSBzaGFyZWQgdW5kZXJzdGFuZGluZyBhY3Jvc3MgdmVuZG9ycyBh bmQgb3BlcmF0b3JzIHN1Y2ggdGhhdCBlaXRoZXIgYW4gaW50ZXJmYWNlIGF1Z21lbnRhdGlvbiBv ciBhIOKAnGV4dGVybmFs4oCdIGxpc3QgLCB3aXRoIG5vIG1lbnRpb24gb2YgZ2xvYmFsLCBtYWtl cyBzZW5zZS4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWluYXI8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTMgRGVjIDIwMTcsIGF0IDIxOjA4LCBN YWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb20iIGNsYXNzPSIiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQpZb3UgY2FuIHVzZSB0aGUgc2FtZSBBQ0wgZGVmaW5pdGlvbiB0byBhdHRhY2ggdG8gZGlmZmVy ZW50IHBvaW50cyBpbiB0aGUgc3lzdGVtLCBwcm92aWRlZCB0aGV5IGRvIG5vdCBvdmVybGFwLiBP dGhlcndpc2UsIHlvdSBhcmUganVzdCB3YXN0aW5nIENBTSBlbnRyaWVzLiBHbG9iYWwgYW5kIGlu dGVyZmFjZSBhdHRhY2htZW50IHBvaW50cyB3aWxsIG92ZXJsYXAgd2l0aCBlYWNoIG90aGVyLCBi ZWNhdXNlIGdsb2JhbCBtZWFucyDigJhhbnnigJkgaW50ZXJmYWNlLg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxMywgMjAxNywgYXQgMTI6NDAgUE0sIEVpbmFy IE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVpbmFybm5AY2lz Y28uY29tIiBjbGFzcz0iIj5laW5hcm5uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldlIG5lZWQgdG8g YmUgYWJsZSB0byBhdHRhY2ggYW55IG9uZSBBQ0wgdG8gYSB3aG9sZSByYW5nZSBvZiBkaWZmZXJl bnQgcGxhY2VzLiBKdXN0IHNwZWFraW5nIGZyb20gdGhlIENpc2NvIHBsYXRmb3JtIHBlcnNwZWN0 aXZlLCBJIG1heSBhdHRhY2ggYW4gQUNMIHRvOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9Ik1haWxPdXRsaW5lIj4NCjxsaSBj bGFzcz0iIj5JbnRlcmZhY2VzPC9saT48bGkgY2xhc3M9IiI+TkFUIGNvbmZpZ3VyYXRpb248L2xp PjxsaSBjbGFzcz0iIj5DbGFzcyBtYXBzIGZvciBRb1MgcG9saWN5PC9saT48bGkgY2xhc3M9IiI+ Q2xhc3MgbWFwcyBmb3IgRlcgcG9saWN5PC9saT48bGkgY2xhc3M9IiI+4oCmZXRj4oCmPC9saT48 L3VsPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Tm90IHN1cmUgaWYgd2UgaGF2ZSBhbnkgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnRzIHRvZGF5LCBi dXQgaWYgd2UgZGlkLCBJ4oCZZCB3YW50IHRvIGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIEFDTCBk ZWZpbml0aW9uIGFueXdoZXJlIEkgbmVlZCBpdCwgbm90IGluIGp1c3Qgb25lIG9uIE4gcGxhY2Vz LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDEzIERlYyAyMDE3LCBhdCAy MDoyOSwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNs YXNzPSIiPg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlvdSB3b3VsZCBhdHRhY2ggYW4gQUNM IGVpdGhlciB0byBhbiBpbnRlcmZhY2UgPGIgY2xhc3M9IiI+DQpvcjwvYj4gZ2xvYmFsbHkuIE5v dCBib3RoLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxMywg MjAxNywgYXQgMTI6MjUgUE0sIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmVpbmFybm5AY2lzY28uY29tIiBjbGFzcz0iIj5laW5hcm5uQGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCknigJltIGhhcHB5IHRvIGhhdmUgYSB3YXkgdG8gYXR0YWNoIGFuIEFDTCBn bG9iYWxseSwgYnV0IHRoYXTigJlzIG9ydGhvZ29uYWwgdG8gYXR0YWNoaW5nIHRvIGFuIGludGVy ZmFjZSwgaXNu4oCZdCBpdD8gQXR0YWNoaW5nIEFDTHMgZGlyZWN0bHkgdG8gYW4gaW50ZXJmYWNl IGRvZXNu4oCZdCBwcmVjbHVkZSBnbG9iYWwgYXR0YWNobWVudCBpbiBhbnkgd2F5IGFzIGZhciBh cyBJIGNhbiBzZWXigKZvciBoYXZlIEkgbWlzc2VkIHNvbWV0aGluZz8gSeKAmW0gbm90IHN1cmUN CiBJIHVuZGVyc3RhbmQgd2h5IGNob2ljZXMgYXJlIGFuIGlzc3VlLiBUaGUgY3VycmVudCBwcm9w b3NhbCBoYXMgdGhpcyBjb250YWluZXI6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIg Y2xhc3M9IiI+bW9kdWxlOiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Q8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2Nlc3MtbGlzdHM8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYXR0YWNobWVudC1wb2ludHM8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBpbnRlcmZh Y2UqIFtpbnRlcmZhY2UtaWRdIHtpbnRlcmZhY2UtYXR0YWNobWVudH0/PGJyIGNsYXNzPSIiPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3 IGludGVyZmFjZS1pZCAmbmJzcDsgJm5ic3A7aWY6aW50ZXJmYWNlLXJlZjxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1y dyBpbmdyZXNzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgYWNsLXNldHM8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOy0mZ3Q7IC4uLy4uLy4uLy4uLy4u Ly4uL2FjbC9uYW1lPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncg dHlwZT8gJm5ic3A7IC0mZ3Q7IC4uLy4uLy4uLy4uLy4uLy4uL2FjbC90eXBlPGJyIGNsYXNzPSIi Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlKiBbbmFtZV0ge2ludGVyZmFjZS1z dGF0cyBvciBpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZX0/PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAuLi8uLi8uLi8uLi8uLi8uLi8uLi9hY2wv YWNlcy9hY2UvbmFtZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRz PyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgZWdyZXNzPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcncgYWNsLXNldCogW25hbWVdPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7LSZndDsgLi4vLi4vLi4vLi4vLi4vLi4vYWNsL25h bWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyB0eXBlPyAmbmJz cDsgLSZndDsgLi4vLi4vLi4vLi4vLi4vLi4vYWNsL3R5cGU8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBhY2UqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzIG9yIGlu dGVyZmFjZS1hY2wtYWdncmVnYXRlfT88YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgLi4vLi4vLi4vLi4vLi4vLi4vLi4vYWNsL2FjZXMv YWNlL25hbWU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm IzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1v Y3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDxiciBjbGFzcz0iIj4NCjwvZm9udD48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgd2UgYWRkZWQgc29tZSBmb3Jt IG9mIGdsb2JhbCBhdHRhY2htZW50IHBvaW50cywgdGhhdCBtaWdodCBiZSBhIHBlZXIgd2l0aCB0 aGUgbGlzdCBvZiBpbnRlcmZhY2UgYXR0YWNobWVudHMsIHJpZ2h0PyBCZWNhdXNlIHdl4oCZZCBu ZWVkIHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGFuZCBtdWx0aXBsZSDigJxpbnRlcmZhY2XigJ0g YXR0YWNobWVudHMuIEl04oCZcyBub3QgYW4g4oCcb3LigJ0sIGl04oCZcyBhbiDigJxhbmTigJ0u IE9yIGhhdmUgSSBtaXNzZWQNCiBzb21ldGhpbmc/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pk9uIDEzIERlYyAyMDE3LCBhdCAyMDoxMCwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5p QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KV2Ugd2FudCB0byBzdXBwb3J0IOKAnGdsb2Jh bOKAnSBhdHRhY2htZW50IHBvaW50IGRvd24gdGhlIGxpbmUsIGFuZCB0aGF0IOKAnGdsb2JhbOKA nSBhdHRhY2htZW50IHBvaW50IHdpbGwgYmUgb25lIG9mIHRoZSBjaG9pY2VzICh0aGUgb3RoZXIg YmVpbmcgdGhlIGludGVyZmFjZSksIHdoYXQgd291bGQgdGhpcyBhdWdtZW50IGxvb2sgbGlrZS4g Tm90ZSwgYXMgZmFyIGFzIEkga25vdywgeW91IGNhbm5vdCBhdWdtZW50IGluc2lkZSBhIGNob2lj ZSBub2RlLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIERlYyAxMywg MjAxNywgYXQgNjo1NyBBTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pICZsdDs8YSBo cmVmPSJtYWlsdG86ZWluYXJubkBjaXNjby5jb20iIGNsYXNzPSIiPmVpbmFybm5AY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KUGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUg aW50ZXJmYWNlOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4 OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJD b3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZh Y2U6PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBpbmdy ZXNzLWFjbHM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsm IzQzOy0tcncgYWNsLXNldHM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIi IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHR5cGU/ ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3Mt bGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1l XSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNj ZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8g bWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBlZ3Jlc3MtYWNs czwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAt Jmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNl LXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWU8L2ZvbnQ+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9 IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6 Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0 cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5Db3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBhYm92ZSBib3RoIHRo ZXNlICZhbXA7IHJlbmFtZSDigJxpbmdyZXNzLWFjbHMmcXVvdDsgdG8g4oCcaW5ncmVzc+KAnSwg ZXRjLiB0byBnaXZlIGEgc2luZ2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50YXRpb24gaWYgcHJlZmVy cmVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gNiBEZWMgMjAx NywgYXQgMTk6NDMsIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNv bSIgY2xhc3M9IiI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAxMi82LzE3IDc6MjMgUE0sIE1h aGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+SG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2htZW50 IHBvaW50LCBjdXJyZW50bHkgYW48YnIgY2xhc3M9IiI+DQonaW50ZXJmYWNlLXJlZicsIHRvIGFu IGF1Z21lbnRhdGlvbiBvZiB0aGUgaWY6aW50ZXJmYWNlcy9pbnRlcmZhY2UsPGJyIGNsYXNzPSIi Pg0KaW5zaWRlIG9mIHRoZSDigJhhY2zigJkgJm5ic3A7Y29udGFpbmVyPyBEb3duIHRoZSBsaW5l IHdlIG1pZ2h0IG5lZWQgdG8gaGF2ZSBhbjxiciBjbGFzcz0iIj4NCmNvbnRhaW5lciBmb3IgJnF1 b3Q7YXR0YWNobWVudCBwb2ludHMmcXVvdDsgdG8gYWNjb21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5 IG9mPGJyIGNsYXNzPSIiPg0KYXR0YWNoaW5nIGFuIEFDTCBlaXRoZXIgdG8gYW4gaW50ZXJmYWNl IG9yIOKAnGdsb2JhbGx54oCdLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCktlZXBpbmcgaW4gbWluZCB0aGF0IG9uZSB1c2UgaXMgdGhh dCBhbiBBQ0wgZG9lc24ndCBhdHRhY2ggdG8gYW48YnIgY2xhc3M9IiI+DQppbnRlcmZhY2UgYXQg YWxsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbmV0bW9kIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIi Pm5ldG1vZEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgY2xhc3M9IiI+ bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk1haGVzaCBK ZXRoYW5hbmRhbmk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5h bmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk1haGVzaCBKZXRoYW5hbmRhbmk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJl Zj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5p QGdtYWlsLmNvbTwvYT48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B4AB3AB0A5B74B3D94C483768ACB723Dciscocom_-- From nobody Wed Dec 13 23:04:43 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A862B127011; Wed, 13 Dec 2017 23:04:41 -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, 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 TPfMiqrlJrmE; Wed, 13 Dec 2017 23:04:39 -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 87F4C124D37; Wed, 13 Dec 2017 23:04:39 -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 vBE74d3v030999; Wed, 13 Dec 2017 23:04:39 -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=bwPywVW0mvQ+8xQSTPOXNHTbgb87Po3HU7fMJsLZ+qQ=; b=xvly2jQUcALBNb8I0/MbAcrY4gZGZbO69XI2sgeOEUc/yWIlo6cGiAXBli0gAMS1Zoxc +VR0hgc1WCOd1mWzXCQ4mLNrMNEW7A57vNPyLToM7mtlfmVUWbURswzeMJ1Rb6IIr07M K9GUHbZFkVysb0sa0HRLJGRYSlPo3u8hgTteZqegdmo7ACQd5DLRVWqy+6RQ9P+qLKO4 qeKOyRX13yllZgIFE7Xm6GtPwuHEbeq/x1Mf4reIr9UVqQ8qF/5He1ieI+n6qAZHSJq9 cTh7P4zed+5WaUGwyiL/uLgSdL3+DKBA6ruh8B0y4yT/JcdnB+KQKhuOTnod5hK5OowT xg== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0176.outbound.protection.outlook.com [216.32.181.176]) by mx0a-00273201.pphosted.com with ESMTP id 2euk65g3y6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2017 23:04:38 -0800 Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Thu, 14 Dec 2017 07:04:04 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0323.011; Thu, 14 Dec 2017 07:04:03 +0000 From: Kent Watsen To: "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7277bis-00 Thread-Index: AQHTaH8uQPbcvjqNt0+Zr1pndKQN96NB/FkA Date: Thu, 14 Dec 2017 07:04:03 +0000 Message-ID: <37806728-9682-48C2-9FBA-391A89F6185F@juniper.net> References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net> In-Reply-To: <296363B7-40FF-4FAC-94F9-A7655CD0D111@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.239.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:brj8BWcNwdnouuJ/bWLG7xDrZeqE7BA1nK6ttb6gOiwN1E5OGP5Q9PBCr3iT+SRQOkW5X3UO521u9IJIoPPitgPAcTlVxHY8/Xo5XJ8xrAUWziK/vUIo2oEeiR+bZPVhnIETOKX6vJrU59q4ZcDwvrxqk1qc0s2a3UqK7KRnW/BuH1eqcKqrPaGKC61LfJkN1umjpKZsuTjpv0e1LolwL/dzM9VGM1zsIqGklnSixwQr4p73S9qDsZAofUn4p2RWMvDDJJgtCkGwkW5BqQ7OcYkZs1NOoDJC4LPXFJ3RiXYtMAmxO7th2XOBN3/tV2nVYLhovlg8Gr20eDU6z3cH6FxtqFTTX8q9OHZvWJBFwz0=; 5:JU8imzChZpKAkCTZ7HhJNRhYSMBMwTQxjVaYsmhbBPYwwSbBaqW5sJ5Bl4pCyLtjZzrr9ACTPWcB07/GrheYrNG2SUp7Vl60A92aUBMdh+LG7uB+J+Rwuazx35OcOG99gigB6pQpM4wk32oPRENa6XRRJfmn3M0kGWqUZ0yRKXQ=; 24:/MVThR9FFD4QxOf+OI0bfi/Rl+1IW8xKblV5oKxlZ7Srs/sOllcDIyozNseN7pcGDDg2JXGnIPu9qzHYBJFNYTNLdDznpc1lIXp3u4I9axE=; 7:Iwqfm397TFBGxTP4Og6O36wlRPDb3EN92+IIIozbJU0vZDZ/nEDbe4Fkjfzpn3zFOFN23MUjg+Any2V7qdloJOpk7qOMQjm6OXiFV92fMl4Yf1Nhq4DP2N/cD4TRpzqW4g3DTJO0OK3qhHWrlNdX9fVJOZuiGUzwLspupxfw09hVctI01I1GpreQK0a8AyC0Fe0WS1W6WkTHalTolN1OkneFVRyUHO3eecsh2XxXtYnmMTbODbC6vrwP5mIWBtck x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fcc2bd4d-78dc-47b9-4dd2-08d542c0dc4b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153051); SRVR:BLUPR05MB273; x-ms-traffictypediagnostic: BLUPR05MB273: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB273; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39860400002)(346002)(189003)(199004)(33656002)(5640700003)(97736004)(6512007)(2950100002)(229853002)(2351001)(58126008)(316002)(478600001)(105586002)(2501003)(83506002)(6916009)(77096006)(6486002)(36756003)(966005)(6306002)(6436002)(5660300001)(106356001)(66066001)(76176011)(86362001)(2900100001)(99286004)(8936002)(83716003)(230783001)(68736007)(82746002)(3846002)(6116002)(305945005)(14454004)(102836003)(7736002)(2906002)(81156014)(3660700001)(8676002)(3280700002)(81166006)(1730700003)(6246003)(59450400001)(53936002)(6506007)(25786009)(450100002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.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) 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: fcc2bd4d-78dc-47b9-4dd2-08d542c0dc4b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 07:04:03.9088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-14_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-1712140103 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2017 07:04:42 -0000 QWxsLCANCg0KICBUaGlzIGxhc3QgY2FsbCBpcyBub3cgY2xvc2VkLiAgU2luY2UgdGhlIGNvbW1l bnRzDQogIHdlcmUgbWlub3IsIHRoaXMgbGFzdCBjYWxsIGlzIGNvbnNpZGVyZWQgc3VjY2Vzc2Z1 bC4NCg0KQXV0aG9ycywNCg0KICBQbGVhc2UgYWRkcmVzcyBhbnkvYWxsIGNvbW1lbnRzIHJlY2Vp dmVkIGR1cmluZyANCiAgdGhlIExDLiAgT25jZSB5b3UndmUgcHVibGlzaGVkIHRoZSB2ZXJzaW9u IHRoYXQgDQogIHlvdSBiZWxpZXZlIGFkZHJlc3NlcyBhbGwgY29tbWVudHMvcGVuZGluZyBjaGFu Z2VzLA0KICBJJ2xsIHBlcmZvcm0gdGhlIFNoZXBoZXJkIHJldmlldy4NCg0KVGhhbmsgeW91LA0K S2VudA0KDQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KQWxsLA0KDQpUaGlzIHN0 YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1pZXRmLW5l dG1vZC1yZmM3Mjc3YmlzLTAwLiAgDQoNClBsZWFzZSByZWNhbGwgdGhhdCB0aGlzIHVwZGF0ZSdz IGludGVudGlvbiBpcyB0byANCm1vZGlmeSB0aGUgWUFORyBtb2R1bGUgdG8gYmUgaW4gbGluZSB3 aXRoIHRoZSBOTURBDQpndWlkZWxpbmVzIFsxXS4gIFJldmlld2luZyB0aGUgZGlmZiBiZXR3ZWVu IHRoZSB0d28NCmRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRoaXMuDQoNClRoZSB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIERlY2VtYmVyIDEyLg0KUGxlYXNlIHNlbmQgeW91 ciBjb21tZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCg0KUG9zaXRpdmUgY29tbWVu dHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQNCmFuZCBiZWxpZXZlIGl0IGlz IHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KVGhpcyBpcyB1c2VmdWwgYW5k IGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDENClsyXSBodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1yZmM3Mjc3YmlzLTAwLnR4 dA0KDQpUaGFuayB5b3UsDQpOZXRtb2QgQ2hhaXJzDQoNCg0KDQoNCg0K From nobody Wed Dec 13 23:04:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95294127011; Wed, 13 Dec 2017 23:04:43 -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, 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 wzeWsIOQWB2n; Wed, 13 Dec 2017 23:04:41 -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 5746C126DFE; Wed, 13 Dec 2017 23:04:41 -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 vBE74d40030999; Wed, 13 Dec 2017 23:04:41 -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=Z3YqlzqDMIA+iczhsP3Ul9i7c6HJkg+Uuze4mpcDgX0=; b=xEnWGWLux7ygG6CrmfjnfbSTf+L/u4UFmoxvhscaPtTWdmM/2Ej7RL7XO8mIlfbQb4B7 dnxFUPANa6UUEVJaxB2KUToO0lY5Fmvb6wrxiAcOs5P9CIAdGELVdbu3b5Xq4CxBbgAv PTzfSBFLJVFQj7F4qFOGjmbF4aYXotjj/NE6WdyPmNLPDJUfUuflnHD/mBZYBoaQ7VfG mE5Yhoxtb0mvmzefx/gD2+kz8vImJr4iYsZwaij0KB2P4LOP4w74GMULovvqipGFUtC6 P9xKohu2bg84DakTaOypgfWK93R8vehfE/GDYfnUlVm01WMoYoBPif+ScgeBJYcl5nHP yw== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0176.outbound.protection.outlook.com [216.32.181.176]) by mx0a-00273201.pphosted.com with ESMTP id 2euk65g3y6-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2017 23:04:40 -0800 Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Thu, 14 Dec 2017 07:04:04 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0323.011; Thu, 14 Dec 2017 07:04:04 +0000 From: Kent Watsen To: "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7223bis-00 Thread-Index: AQHTaH8mwis2iZPDB0aqvQnmsEUf+6NB/FqA Date: Thu, 14 Dec 2017 07:04:04 +0000 Message-ID: <2EEE9D3B-6B79-4F60-BEF0-82F8D3530603@juniper.net> References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net> In-Reply-To: <10B5698A-BC7B-432E-A931-9069FA7BB03C@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.239.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:T2tINktdHFOGYc1mRjTVgVPs+pVkPDvp2UnYBhxOa5KGzTHJD1DOvNM71dp8DUyd/8+AJDSZY4ws4A7wLQFlvVL12Obt76L2oLDkHs0jUzwUebtaaHkg/ahtyhpTf1bx6hqkWQMmY8/F1UDween4ibLpytk0M8HBINHjSD8T/Qev6Dl+RnomOiqWm9MR3nELrgcNYcRa5dr66ud4KngLtd7Jzm0bgoPotjLR0nSOYzHDdFGGP0maZWkmqN+n+X2/ws6j2U6Q+iOnpu6VLKTnyAtvHvZuGMuYeuzU9gG0bWY8Ctu44ZB5meqrKNtr/pOANZtZrBVqF/FR+roe/yy5Dg==; 5:YZSV4zbA+WuU2cP2M0Ps/1g9iA8HXpzLyGhMuTUS0iZ7efEwIL9OyIfzmaHQkV7VhF0v5BjR0nx9KuRyeS1PYadD1RAUKpmpIOxxMEL++q0wSJGES7Ut2bDdxDHJG9tmWsXVYTIgdEQli9NWBlq0yclyt6rdCLJnOgDehXouFU4=; 24:zfjzxgUpTiW/nDeX/UgtSjNIMinyxpDbLOO7NvLKMSjxtOdIPFJ/0CbBooWNe8jEsbSiMgdTwzNqmN1+HhvxRQ4EBMTBF87/7onWXmQ72dM=; 7:rnOPbJGNJXjEV14COovU1MP3bGR1Q9QfATwvJKJoLjsWyUKZRSbv4Xs+DdINFLtNdZa3JBl1vKEiata3zwDmOFLIuf87uupU20s3zLFFfrXIqqhgq+6SNSxT9pBiDvifuPf2s6aSdigadwHGi3S9SsX/GfnJSUCgpoF1BRZzE1AG/LFlqMt6zjEhx7UHYxxKr0tseiYlI2ldKYAX4V8Z8k4r/d++/FFtaOKOhRgPcPcs1AEPqaJEbJbK0BJp88Fr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d1ad5515-8dc3-48d6-0df3-08d542c0dcad x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153051); SRVR:BLUPR05MB273; x-ms-traffictypediagnostic: BLUPR05MB273: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB273; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39860400002)(346002)(189003)(199004)(33656002)(5640700003)(97736004)(6512007)(2950100002)(229853002)(2351001)(58126008)(316002)(478600001)(105586002)(2501003)(83506002)(6916009)(77096006)(6486002)(36756003)(966005)(6306002)(6436002)(5660300001)(106356001)(66066001)(76176011)(86362001)(2900100001)(99286004)(8936002)(83716003)(230783001)(68736007)(82746002)(3846002)(6116002)(305945005)(14454004)(102836003)(7736002)(2906002)(81156014)(3660700001)(8676002)(3280700002)(81166006)(1730700003)(6246003)(59450400001)(53936002)(6506007)(25786009)(450100002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.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) 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: d1ad5515-8dc3-48d6-0df3-08d542c0dcad X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 07:04:04.5494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-14_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=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-1712140103 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2017 07:04:44 -0000 QWxsLCANCg0KICBUaGlzIGxhc3QgY2FsbCBpcyBub3cgY2xvc2VkLiAgU2luY2UgdGhlIGNvbW1l bnRzDQogIHdlcmUgbWlub3IsIHRoaXMgbGFzdCBjYWxsIGlzIGNvbnNpZGVyZWQgc3VjY2Vzc2Z1 bC4NCg0KQXV0aG9ycywNCg0KICBQbGVhc2UgYWRkcmVzcyBhbnkvYWxsIGNvbW1lbnRzIHJlY2Vp dmVkIGR1cmluZyANCiAgdGhlIExDLiAgT25jZSB5b3UndmUgcHVibGlzaGVkIHRoZSB2ZXJzaW9u IHRoYXQgDQogIHlvdSBiZWxpZXZlIGFkZHJlc3NlcyBhbGwgY29tbWVudHMvcGVuZGluZyBjaGFu Z2VzLA0KICBJJ2xsIHBlcmZvcm0gdGhlIFNoZXBoZXJkIHJldmlldy4NCg0KU3BlY2lhbCB0aGFu a3MgdG8gVmxhZGltaXIgdGhlIGV4dGVuc2l2ZSBhbmFseXNpcyENCg0KS2VudCAvLyBzaGVwaGVy ZA0KDQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KQWxsLA0KDQpUaGlzIHN0YXJ0 cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1pZXRmLW5ldG1v ZC1yZmM3MjIzYmlzLTAwLg0KDQpQbGVhc2UgcmVjYWxsIHRoYXQgdGhpcyB1cGRhdGUncyBpbnRl bnRpb24gaXMgdG8gDQptb2RpZnkgdGhlIFlBTkcgbW9kdWxlIHRvIGJlIGluIGxpbmUgd2l0aCB0 aGUgTk1EQQ0KZ3VpZGVsaW5lcyBbMV0uICBSZXZpZXdpbmcgdGhlIGRpZmYgYmV0d2VlbiB0aGUg dHdvDQpkcmFmdHMgWzJdIHNob3VsZCByZXZlYWwganVzdCB0aGlzLg0KDQpUaGUgd29ya2luZyBn cm91cCBsYXN0IGNhbGwgZW5kcyBvbiBEZWNlbWJlciAxMi4NClBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QuDQoNClBvc2l0aXZlIGNvbW1lbnRzLCBl LmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50DQphbmQgYmVsaWV2ZSBpdCBpcyByZWFk eSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRoaXMgaXMgdXNlZnVsIGFuZCBpbXBv cnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzLTAxDQpbMl0gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzIyM2Jpcy0wMC50eHQNCg0K VGhhbmsgeW91LA0KTmV0bW9kIENoYWlycw0KDQoNCg0KDQoNCg0KDQo= From nobody Thu Dec 14 00:21:51 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242AE12708C for ; Thu, 14 Dec 2017 00:21:50 -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 lKNG3YX8rpZn for ; Thu, 14 Dec 2017 00:21:48 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 40AB5126E64 for ; Thu, 14 Dec 2017 00:21:48 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id f2so6986572qtj.4 for ; Thu, 14 Dec 2017 00:21:48 -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=rcehV3kulOI3gnRuXNsXaDUJR9lLst9HYCO/RBHnPVM=; b=f2aTehkfUnh8tzlR/mmH43ETl9iG8VefF1RLItBx9JXqk0jGqYGtiTGjxvpRX9FzCJ RTLfdo/zLu5BRE4NI41nWvAQ36Ner3sDqWzPWznrClFup3IcaSzrlgvX6AvSWUtYur+i nBIdt25JARnRb+QCONwpUI6ZSx1/0SmFoEfGaD8fN0qbzAEyCZTHONXqstRuWp+oJDt6 HCsCkTd+NVdTv1RfKctLwWxv7GNfXSXPJBV6AhxsJfJisJi41TBl1wnssz1kfKoXrdQ+ iILBraIN8oqa8XyaUvJnt8lfQHb65O+mbecQ8iD5rE8jC4cBaYTVvH7kRa6R0Vwj26Yq mIlA== 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=rcehV3kulOI3gnRuXNsXaDUJR9lLst9HYCO/RBHnPVM=; b=mW4jaWvUN+y/Cnw5Rhtv8D6g/hN1rXnfRSsjwQ5j/bBuGCE0VDUoyBHpSimuAYwCNL LSKkQS2APY6jRMAWJbTxB1kk3PHQF+F8D2KI7cQ8OLCBa3KurnN6dFy6MxKaUE5KOEQx puEA4GObCbiFb6SUSDkUlzTaFPnN4CiTUeY1+GVPu+kgeXtrcdvu2zmcSgMvIInvnXvx 79ihY2s85cwxVvWG4ZpByp2CZa2UiddAXhoAx7f09BQ0r8O1CaMsrNF2VhoNJ4pQAwx6 zBzoifxK2D8Ntx6vzbaFuVC/ccsU/4hFCwIqtJmfclgaoKttD4SSXf4Nc2A8w0znxlmb t/qg== X-Gm-Message-State: AKGB3mI2UNF+iEj1KIsPI+TVRa/x4reQaft1xeO5tIMEtKd//Tf7qPVK ynkhWzoiLnpSxdDBAUAWbJ3WnYb89F0StpSiT84= X-Google-Smtp-Source: ACJfBouBlUeUYnFTO2+tj08tpvG7mkxeRlO4fXPU0MAjRPJAl4SmytKQm492rvkrBGn4py0z9dTVIK07XwfoUkGotTk= X-Received: by 10.200.54.236 with SMTP id b41mr16105114qtc.280.1513239707411; Thu, 14 Dec 2017 00:21:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.109.139 with HTTP; Thu, 14 Dec 2017 00:21:46 -0800 (PST) In-Reply-To: <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.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> From: Sonal Agarwal Date: Thu, 14 Dec 2017 00:21:46 -0800 Message-ID: To: Mahesh Jethanandani Cc: "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a113d07583867d10560489356" 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, 14 Dec 2017 08:21:50 -0000 --001a113d07583867d10560489356 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. However, Kristian wants the global attachment point as well so that he can add the ACL to the linux tables. If an ACL is attached globally, does this mean it is per direction or does it mean it is across directions? 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. For (2), I am ok with removing icmp-off. 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. 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 lin= e, 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, yo= u > 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 & ren= ame > =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D, etc. to give a singl= e 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 ne= ed 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 > > --001a113d07583867d10560489356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 a= ttachment point for interfaces only. However, Kristian wants the global att= achment point as well so that he can add the ACL to the linux tables. If an= ACL is attached globally, does this mean it is per direction or does it me= an it is across directions? This global ACL may not be applicable to any of= Cisco's service provider routers as I don't see any platform actua= lly replicating the ACL to all line cards and attaching it in ingress and e= gress directions across all interfaces.

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

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


On Wed, Dec 13, 2017 at 12:10 PM, Mahesh= Jethanandani <mjethanandani@gmail.com> wrote:
We want to s= upport =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 o= ther 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, Ei= nar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> 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* [n= ame]
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--r= w 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+--r= w type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> /access-lists/acl/t= ype
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--r= o 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 -> /acce= ss-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:counter64
=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-se= t* [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-list= s/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:counter64

Could also put an =E2=80=9Caces=E2=80=9D container above both these &a= mp; rename =E2=80=9Cingress-acls" to =E2=80=9Cingress=E2=80=9D, etc. t= o 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=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


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

--001a113d07583867d10560489356-- From nobody Thu Dec 14 03:55:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08ADD126BF0; Thu, 14 Dec 2017 03:55:32 -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 1TfWs04l9sGl; Thu, 14 Dec 2017 03:55:28 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0091.outbound.protection.outlook.com [104.47.1.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 518D3128959; Thu, 14 Dec 2017 03:55:27 -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=X9feSYdBJgXNSHFA6BvyjrF5fQ9D3JWvOeMTERMROmw=; b=LPipBPXb/gCwRQHkikaAN8pHcowrCVQfUYknImr/qVu2SAx/cBwp+OBRyz8ILJx33aAV02aLPBrhmgrfJYQADu+WFuA1efDP5nl32vS7pYX3qgQ451Eo8IWnApNuGL7V/WBKYFbQZQ1V8lS/JMXVj20pxp5tQwpd8LCI//Qtwz4= 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.323.4; Thu, 14 Dec 2017 11:55:24 +0000 Message-ID: <004401d374d1$e1fb3540$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Clyde Wildes \(cwildes\)" , "Benoit Claise \(bclaise\)" , "Kent Watsen" , Cc: References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net> <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net> <5CE9EE07-D75D-4E5C-BC70-1F969732A526@juniper.net> <8e873d52-a6bd-87ee-9ff5-62c85eb5b6dc@cisco.com> <8015AC50-45CE-4813-B77B-8D1D3D3BC349@cisco.com> Date: Thu, 14 Dec 2017 11:51:12 -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: AM4PR0202CA0023.eurprd02.prod.outlook.com (2603:10a6:200:89::33) To AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 549a3a17-4a63-45bb-47dd-08d542e98f78 X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603307); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:UVnGEel7stGPGte4xi9GzwQO1QYJORlsKoqHdcOoI9OL/ft5JvNS2aPZGpTJekEhYeaXDOrQCE8k80Pe4qsdToXw5W6oLru/PLK7Vd60WNAIp7toMzYXLX5DZBBBo/mOu4wTl70hJPhQM04ZrgK8i10Wh2uEui6yiHALCRqhMP41c+B6+ID6aPVKfAeGU9eq/DC+Yp7pOBdTna54SDzLjuqndM4iwf/aydwG3NMA4jUUQcVOe4owWwC91SDCc1LcJr/0l5CgdSZJK1ncYYUcJUit/MaOX+b9jwv26EYFodY=; 25:/MDgCQOpVwyCrv/BM6ARIvFf9RsIAd/MpB6TJP4SJVMWqC7KJ5HPrwEZIaJsym2joDg97zevNLsOLv7Fa4P3KPzF7zB8L2sLOFl/OX9+Dy0kspAilYw3mgdyvBYx6dcimVptUBbvCvBf9DlsO9OY1QbggyLPTdn3zosy15uQUMwVXyaK1ooI/ZNLtNJrAU2YhHd3iIbznNUtp3IIPMPazmEtQFd9TvwmVB8kye5/TNzydATJ7UJkIWYcWlQ8/MmjKO7uGOn+u5nvQMBOWD2Qwp19zpl8FUKXUOrdl6ABqA00VoDz8dPSlbubJyT/uXUpo9oSCuocY6IH49y/pQTFi4nOBF+vM7lp3bvxisoZLqU=; 31:T9qNAN2+Sz68scmFfgvh6x13uEZjrZV+66QsPmRdDLw/SyEMiuiK0bSlm1bfvkfpyIzVO0R3X6y501tZKdVqM85QQQwZt5YmX3Xbg/6UZfhD1BLDr7NFLc/52gXaO8VyFfFmyyL85itCSBJFdA3E7M5BfTTQL/PjV2qJ154DhNzRRA78hn1yxhCNn9DBbupgs2X+UzJpdRWWl6RbCORHxfghjIY/UPFEux35U8T35h8= X-MS-TrafficTypeDiagnostic: AM5PR0701MB2993: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 4:I8ncE/dYva2xTvoJ38kwPTf8mT7cZYgQElwxP2pYzrAr65aK4xBW60V74PtfeeHLPH6F21t88Tcm65S4ke91eLPbwY3n4d674x3tTiRZBtGAoHi6egQrtG+pF4rzMxksKhP+PDoKPk6LizZ86gr0VGKhVKd3Ix0vTnFuogPxBEnPov6IOTMFUJImWO2qiUb6HlIlpYcbhfZFW4jc3prb4GY34OE+ObEOrDWxB6O7Hwz44IAsQGi9ULLJcqf+dZkJq/mZ8oUFYtWB7fUbbErsV7JY62GInswj6rRxL4XBCIWyLhXbXZ/sZ/081p5JcQi/i58h9Nqcf6/Sz/kjgSoIr0isaxgam3X4+PaMyF/XxcbaWJmkrVDyeKrfO2RyB2t+ X-Forefront-PRVS: 05214FD68E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(366004)(346002)(51444003)(57704003)(189003)(24454002)(199004)(13464003)(81816011)(76176011)(6116002)(7736002)(3846002)(81686011)(47776003)(305945005)(53936002)(4720700003)(68736007)(5660300001)(25786009)(84392002)(6666003)(4326008)(66066001)(62236002)(44716002)(6246003)(50226002)(23676004)(52116002)(8936002)(14496001)(6496006)(5820100001)(50466002)(61296003)(229853002)(33896004)(16526018)(93886005)(97736004)(9686003)(6306002)(6486002)(1456003)(8666007)(966005)(316002)(1941001)(53546011)(2906002)(386003)(116806002)(86362001)(2870700001)(81166006)(81156014)(575784001)(8676002)(230783001)(106356001)(110136005)(105586002)(478600001)(59450400001)(1556002)(44736005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; 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?MTtBTTVQUjA3MDFNQjI5OTM7MjM6c1J0Tk9zTlVDOFUyT3hwTkhPNDNSSUh4?= =?utf-8?B?a0dCSGowRFZIZE8xZmszYkhlSDVlZzJOYW9NL2ljU0x6UEhWaytWM1BPTzBG?= =?utf-8?B?ZVBxOExiQThiTytOYkpHTDhmL2ZZbTY3NzhkQnZid0VpZTd4ejl1UHpGeWlE?= =?utf-8?B?My9RMnBGYjhoTUp5Sjc2OGRJeFRMR3UwM3VYOTRpWTJKVXgwelpqTy9QUTd1?= =?utf-8?B?RnkzdnUyV2haYjF5cTFnbEhheHNWeis2M2Q4NjNRV2hzQWl5ZEpDRHlDWTJR?= =?utf-8?B?U094ZGk4ZDRiUUdQZTFYaVh3c2ljd0oxSElmSmI3OGI4elVaajJwMHkvZDV1?= =?utf-8?B?TGVEbXVvSlpHdkFNTlFGNTlvTnNnZUpzYm8vcTFBM2xMbElIOU9ocktkR2RG?= =?utf-8?B?MkM0WXlNa00wVzBEcWJQL0tyMGF6alB2eXE5TmYzOEhwZmR2RHByeDlSd3ZX?= =?utf-8?B?VGRmSW11eEx1MUJkUmRoUUVLQnRkTlpQWFhiNUVCdGlzTWtLVmdqMjZQazln?= =?utf-8?B?UDFDY2Q3M3pFL1V4NS9MTXlHSDhSQ0xwSVN5NWhUY1hZWjc4N2pXT3FPVGpv?= =?utf-8?B?bjE4WUFzSmVtbXQ0a3NBYzBJOGI4amlEbFBHT3JDZ2ZoNmh6L21WWk9ZTjJ5?= =?utf-8?B?ekp2RVltek4vek1sUXhDZml3OHNsbHNCSHdjMEo5cnBJNUlnNE54MXQxUjNz?= =?utf-8?B?NmxOdDhlY1ZCMUIzRk1EUThFcGk3WUxORnNkaVNDM0xleWkwcHV6eDU3Q1Y3?= =?utf-8?B?NDhlUTV6dHl5aCtlRFNCRWt4V0wrYkFobWNuM1VDdFRTRGk2bDcwcGNzcW5q?= =?utf-8?B?Z1RJK2htREM1SlZVaHNZb1Jwc1VSakE3aWY5UDRUMEVVcjBXUk02dzRMOVZX?= =?utf-8?B?WHJIMUlMUnpKZlBXWUtOY0ZGS3hDUUlRV2RHVThObGRNSEpaa0pCeUN5Rk1i?= =?utf-8?B?QlVTNURoVXZtMkozN0htVjUyMlFVZ1VmRmkreVFWZmhzUDRkbEs5RFNoMjFH?= =?utf-8?B?a0l3YjQ3ZzZTV2VaK3ZWVkhscFlvczRXTWdHTDRTZjBLaURhUjBhdlBJZGw5?= =?utf-8?B?YjRqeEZGK2NvOTZsdVlGN0kvbzJBWWU4Yk1XMWpuYStYNzdPRlVXaytRRlJ3?= =?utf-8?B?NFVEaFBTSUFSakQ5OHZsdWFiZHFUTk1ETjdGRy9EUWJiUjJLd094ekdZcXo4?= =?utf-8?B?QXNqSEFsV3kzc294TXRHdmVONGI1UTJHVmlDR2RraldoNkJpUzRWRy85S20y?= =?utf-8?B?SG1kWmRoZ2tDQ242NGtiSDZjY1cySkRyWFM2QUJFUzE3QlVlVnVhb0tZNHp4?= =?utf-8?B?RnpJRXJaN0M2RHE0VEdMekNNUnJUVUk2VUNMVHIzUDdodjhmYzMxQ3p2aVBI?= =?utf-8?B?am85c2ZBcE1PS1VjN2VYRE9lYnVJQjdEV1ZUSE1IZVNYNzd1TjJabUhUdXhq?= =?utf-8?B?NkFkRk9FaFg0MGlEVjlwbGhadzQzMndwV0NsMitpaHJHWVo0ZVdUV1EzTnYw?= =?utf-8?B?azFoS2pmd1VaOS9TN05mL2NpYWVBYmJ4TXBOdk5GOFpXbWpodUJRbW9ObjFX?= =?utf-8?B?STVIcHNDc3FwNG9pN2pML1labW15TTZhV3F3WkFTdm9TSk9IbVAxUE9jSXpl?= =?utf-8?B?ay9LVHkvSVRXMHFSd2p5RjAvcytsaXNIck1kait6dDlyS0xBakZaSlNSVE1O?= =?utf-8?B?a0cxUmtKYndRQndvbWZ0QUo3YkZzTkc0dWdGK1V4M3JsR01Ud052S2dwU0w4?= =?utf-8?B?V1BNNVBBaWROMkdValBuL0VDb2lKM29sakRMb0VlMTdwbS9ncnpReVpNQzVx?= =?utf-8?B?N2k2SjI1OFlZMzVkM2pTYTlTQlRRV3AyL1dmSWlWWkNSbHFZSFJHWFd0YTR3?= =?utf-8?B?bDRmQTRscy8vSHc2ZWdFeWVCZ0U0MWhwSTZTU0YrR1c4V2wwYWRVakVCZHZZ?= =?utf-8?B?eHlNaDlFTmhxNE9XZVF5d05XclVMcE5LY0NKdWFnY2Q0MkhySjJkTUpyUWRW?= =?utf-8?B?eWNDVjZLQXFJVlV6MzlLL1dRRzNSOFBiemZmdzFKMkhmR1gzSnJWeGpPRXhU?= =?utf-8?B?cWJsdGgxTFRkZkNRYzB0M0pYR013QWJnb2M0K0trd1N1TVg1eDBYQ09GNmpv?= =?utf-8?B?VTQvUHRQZWhRL1V6d2EraDNPT29CVjJnaFN0NGgzcndJU3hDMXlHeXgwUVZm?= =?utf-8?Q?gbNtiUV0qtlzFpjEWq5YPAJrfayvqyxIVpzmgWXZSjUY=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:6nkc8K9vSyFGIkGv1U3Ga2HP9YtP/d5UX/Zw4Tt4/3BNJqxExsUahb0UeMF7tlraE88nexFw8F0yyi9ewlG81yh3gdBamP3zkPyvMxTp+tb9fCFsoqxAU8EaiEO3+9m/GffdMz0vg5HwwZ9XXzFW6i4yvHZZ6pCTsixMxOtAfIqWNSmv4MZMPzNwzLtpp8JDAgOkkOCtCe6Qe+o184+q+hbfmAxeErZl954oTQ4v6u9UIgdxG6iEn0PohOYR7etq+/bN+msp3bkk2RfEKLhmYC1aElec+GAAd4L4FuJ7PzwI9P/IETZL9KlzalSNbaoNLukE/49hBWXV5Xys8OyVuUd/h0w/QyhESgHu9+MqvLY=; 5:UTmkgJUhAQGhsOJZZ/d/M1hqbw158RpjtWNeSPcI2vKSCYDv4A6IsnuzGqK7VEYiTQfXcfJFU19/Ae0Rp+zVYgku5y0sAB58a3mYyi3R+yBQb34cwYQWAYqAitGffAlrq9yarTEP6LcVKdjLhfn0fYsib3cQ2isQZqZZkST0zec=; 24:NtYiVaKaHsnnZRkqQKA0hleTyV/i5AxXfdV/Z/XfGCzxKvPgHKjSzJ3j8MdhdtugNNQlxIuvf3QrtVYnZzcT15/3dyjXV16ClQFBn1CBGSo=; 7:dPwqwRQT5u6voarcVAiscluMuGmOwiCtqUfTpv16lG9CYmsWCxSfE0N5ZEHgnteAV7QN8Rg55dtSveR6kgpQthbPnrcYiOeJiFtvDacdjdMTb9yCFSCzKlPVuFmQUrreRZkfaqQDPcfgMHcyvO8mXC8yFV7EzFvO0L+2jzXEpX4xW/qpKrKB6q5iqYtEuLc2O9+ZHOgE6DqJohMr6f6yorsdM/EofB5gvsXvw/Q8j4K1WD3plI8rQkArBB8acKyN SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2017 11:55:24.0412 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 549a3a17-4a63-45bb-47dd-08d542e98f78 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] syslog-model-17 shepherd writeup issues -references X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2017 11:55:32 -0000 Clyde A quick glance at -18 shows that there is now a Normative Reference for Posix - good- but I do not see it referenced - not so good:-( I think that there needs to be a reference in 4.1 Tom Petch ----- Original Message ----- From: "Clyde Wildes (cwildes)" To: "Benoit Claise (bclaise)" ; "Kent Watsen" ; "t.petch" ; Cc: Sent: Wednesday, September 27, 2017 5:26 PM Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references > Benoit, > > There were approximately 24 changes requested from you, Kent, Robert Wilton, and Tom Petch. I have made approximately half of them and will try to finish another revision of the draft by Friday. > > Thanks, > > Clyde > > On 9/27/17, 3:24 AM, "Benoit Claise (bclaise)" wrote: > > Clyde, > > Do you know your next step to progress this document? > > Regards, Benoit > > I meant to say something about the .1 vs .2 difference. My comment > > assumes that it's supposed to be .1, but we of course should use > > whatever is correct. > > > > I also don't know much about that standards body. > > > > K. > > > > > > > > ----- Original Message ----- > > From: "Kent Watsen" > > Sent: Wednesday, September 13, 2017 6:08 PM > > > >> Hi Tom, > >> > >> Thanks. The fix I'm looking for is for the 'pattern-match' leaf > >> to have a 'reference' statement to Std-1003.1-2008, and for S4.1 > >> to also list Std-1003.1-2008 as a draft-level reference. > > and I am unfamiliar with that standards body so am looking for a little > > more. > > > > Is STD-nnnn always Posix or do we need to say Posix 1003 or Posix > > Std-1003 or is Std-1003 completely unrelated to Posix 1003? > > > > Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the > > .1 or .2 significant? You want Std-1003.1; the description contains > > Posix 1003.2; the normative Reference is to Std-1003.1-2008. > > > > You pointed out that the Normative Reference is not used; well if we can > > sort out what the standard is and get the right label in Normative > > References then we can - must - include this in Section 4.1 which will > > resolve that comment of yours. > > > > The discussions last July had Clyde saying he wants Posix 1003.2 so if > > Std-1003 and Posix 1003 are the same but .1 and.2 are different, then > > you are asking for a semantic change against Clyde's wishes. > > > > I hope my confusion is sufficiently clear, at least to Clyde! > > > > Tom Petch > > > >> I was going to point out the typo "the the" as well, but figured > >> that the RFC Editor would get it. > >> > >> K. // shepherd > >> > >> > >> -- > >> > >> Kent > >> > >> You flag Std-1003.1-2008 as listed as a normative reference but not > > used > >> anywhere in the document. In the Descriptions, but not in the s.4.1 > >> references, I see > >> > >> This leaf describes a Posix 1003.2 regular expression ... > >> > >> twice, which may, or may not, relate to this issue. > >> > >> Back in July, clyde said > >> "I will insert a normative reference to POSIX 1003.2 in the next > >> revision of the draft." > >> > >> In a similar vein, RFC6991 appears in a reference statement but > > nowhere > >> else. > >> > >> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so > >> should not be. > >> > >> And in a slightly different vein, > >> > >> registry [RFC7895]/>. Following the format in [RFC7950]/>, the the > >> > >> looks odd for plain text and for the repetition of 'the'.. > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "Kent Watsen" > >> To: > >> Cc: > >> Sent: Tuesday, September 12, 2017 10:50 PM > >> Subject: [netmod] syslog-model-17 shepherd writeup issues > >> > >> > >>> Clyde, all, > >>> > >>> In reviewing the draft for Shepherd writeup, I found the following > >> issues that I think need to be addressed before the document can be > > sent > >> to Benoit for AD review: > >>> > >>> 1. Idnits found the following: > >>> > >>> Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment > >> (--). > >>> ** There are 2 instances of too long lines in the document, the > >> longest one > >>> being 3 characters in excess of 72. > >>> > >>> ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC > > 6991) > >>> ** Downref: Normative reference to an Historic RFC: RFC 6587 > >>> > >>> == Missing Reference: 'RFC5425' is mentioned on line 359, but > > not > >> defined > >>> '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]....' > >>> > >>> == Unused Reference: 'RFC7895' is defined on line 1406, but no > >> explicit > >>> reference was found in the text > >>> '[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, > > "YANG > >> Module L...' > >>> == Unused Reference: 'RFC6242' is defined on line 1435, but no > >> explicit > >>> reference was found in the text > >>> '[RFC6242] Wasserman, M., "Using the NETCONF Protocol > > over > >> Secure Sh...' > >>> > >>> 2. `rfcstrip` extracted "ietf-syslog.yang", which is missing > >> "@yyyy-mm-dd" in its name > >>> 3. neither `pyang` nor `yanglint` found any errors with > >> ietf-syslog.yang. pyang says > >>> for vendor-syslog-types-example: statement "identity" must > > have > >> a "description" > >>> substatement. > >>> > >>> 4. testing the examples in the draft against yanglint: > >>> - for both examples: Missing element's "namespace". (/config) > >>> - just removing the "" element envelop resolves this > >> error. > >>> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this > >> SHOULD be a > >>> domain name (e.g., foo.example.com) > >>> > >>> 6. in the YANG module, anywhere you have an RFC listed in a > >> 'description' statement, > >>> there should be a 'reference' statement for that RFC. > >>> > >>> 7. in the tree diagram, the leafrefs no longer indicate what they > >> point at, they now all > >>> just say "leafref". Did you do this on purpose, or are you > > using > >> a different tree > >>> output generator from -15? > >>> > >>> 8. RFC6536 is listed as a normative reference, but it probably > > should > >> be informative. > >>> 9. Std-1003.1-2008 is listed as a normative reference, but it is not > >> used anywhere in the document. > >>> 10. RFC6242 is listed as an informative reference, but it is not > > used > >> anywhere in the document. > >>> 11. the document fails to declare its normative references to > >> ietf-keystore and ietf-tls-client-server. > >>> Note: you manually entered the "[RFC yyyy], and [RFC xxxx]" > >> references… > >>> 12. The IANA considerations section seems asymmetric. Either put > >> both registry insertions into > >>> subsections, or keep them both at the top-level… > >>> > >>> 13. reviewing the final document against my original YD review, I > > have > >> the following responses. Let's be sure to close out these items as > >> well. Ref: > > https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11 > >> s-0gOfCe8NSE > >>> 1. ok > >>> 2. better > >>> 3. should be: s/the message/these messages/ [RFC Editor might've > >> caught this] > >>> 4. better > >>> 5. still feel the same way, but no biggee > >>> 6. better, but from 8174, you should add the part "when, and only > >> when, they appear in all capitals, as shown here." > >>> 7. fixed > >>> 8. fixed > >>> 9. you did what I asked, but the result still isn't satisfying... > >>> 10. some improvements made in this area, but my ask wasn't among > > them > >>> 11. better > >>> 12. better, but I think the 4th line should be indented too, right? > >>> 13. better, but I wish you called S1.3 "Tree Diagram Notation" > >>> 14. fixed > >>> 15. fixed > >>> 16. fixed > >>> 17. fine > >>> 18. still a weird line brake here. try putting the quoted string on > >> the next line. > >>> 19. fixed > >>> 20. fixed > >>> 21. not fixed (re: yang-security-guidelines) > >>> 22. fine > >>> > >>> > >>> PS: please also be sure to follow-up with Benoit on his AD review. > >>> > >>> Thanks, > >>> Kent // shepherd & yang doctor > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 Dec 14 04:49:08 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D812D128DE5 for ; Thu, 14 Dec 2017 04:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, 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 Xs-VvnzsldzQ for ; Thu, 14 Dec 2017 04:49:05 -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 1197A1275FD for ; Thu, 14 Dec 2017 04:49:05 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id CDC8B1E0996 for ; Thu, 14 Dec 2017 05:49:03 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id looz1w00a2SSUrH01op2X3; Thu, 14 Dec 2017 05:49:03 -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=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=IqadLysyOOLTYUzSG-EA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=pILNOxqGKmIA:10 a=cAcMbU7R10T-QSRYIcO_: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:To:References: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=EFUv3sSHAAZtW4oIn4/nlpsbiyZpkiIkDQGxN1TLNVE=; b=Omc/nXY/HJrnqPF3DVVXlnsaA6 qMesCIkvRboPXaRtOXmY20E9aaPzclMUQh+ZgyDSIDakpuRUp7plHOlQPVVv8aIOfeIEAKHuMTICh p1+2GJvACKMz0ePoYftY7Maoy; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:36842 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePSwd-003A4Q-Ob for netmod@ietf.org; Thu, 14 Dec 2017 05:48:59 -0700 References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> To: NetMod WG From: Lou Berger X-Forwarded-Message-Id: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> Message-ID: <2583136f-447b-f56e-d617-c8f1708e5188@labn.net> Date: Thu, 14 Dec 2017 07:48:56 -0500 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: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: 1ePSwd-003A4Q-Ob 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]:36842 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] Fwd: [Netconf] Virtual Interim Results X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2017 12:49:07 -0000 FYI - keep in mind that the discussion on rfc7895bis is taking place in *netconf*... -------- Forwarded Message -------- Subject: [Netconf] Virtual Interim Results Date: Thu, 14 Dec 2017 06:20:28 +0000 From: Kent Watsen To: netconf@ietf.org This meeting concluded with an [anonymous] poll with the following results: Which option do you prefer? Most favored: Alt B Should licensing be considered now? 80% no Should h/w insertion/removal be considered now? 80% no Should sem-ver be considered now? 80% no Note: Alt B is described on the slide #5 posted here: https://datatracker.ietf.org/meeting/interim-2017-netconf-01/materials/slides-interim-2017-netconf-01-sessa-yang-library-options These selections now need to be confirmed on the list. Since it's assumed that all interested parties attended the meeting, these decisions will be final unless there are any objections raised in a week's time. Thanks, Kent & Mahesh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Dec 14 04:49:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ECA128D64 for ; Thu, 14 Dec 2017 04:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 kO1s1NEWNSEc for ; Thu, 14 Dec 2017 04:49:26 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 D126F1275FD for ; Thu, 14 Dec 2017 04:49:26 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 74478140482 for ; Thu, 14 Dec 2017 05:49:26 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id lopP1w0072SSUrH01opSQh; Thu, 14 Dec 2017 05:49:26 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=w6YVLcpeieyKU4KX1JwA:9 a=pILNOxqGKmIA:10 a=gUXmQ8eWAGYA:10 a=WjxH0HA_5Shvu8aFslQA:9 a=hkZQ0kMWZQuYznqZ:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:To: References:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding: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=JTKezwjLhpCzNEZqGxXZSDn1C0laCAF8JK/VUwSQQRI=; b=XzY/od5Kl1MXXRbLOoHcCidTfK Hlsz7vieN/TNrGqk7YvWoeklDulIl4xwU101YzSXnVAyAVBS4p+8+GZLv8cndggKvLuj03IOL9V6J peVyww4t3GOmiZB5SLxW4NOB6; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:36888 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePSx1-003AED-9L for netmod@ietf.org; Thu, 14 Dec 2017 05:49:23 -0700 References: To: NetMod WG From: Lou Berger X-Forwarded-Message-Id: Message-ID: <43e95153-be2d-734a-31c8-ae307396c4a6@labn.net> Date: Thu, 14 Dec 2017 07:49:20 -0500 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="------------281BFD92D0DD5BB1320995F1" 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: 1ePSx1-003AED-9L 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]:36888 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] Fwd: [Netconf] Virtual Interim meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2017 12:49:28 -0000 This is a multi-part message in MIME format. --------------281BFD92D0DD5BB1320995F1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit FYI - keep in mind that the discussion on rfc7895bis is taking place in *netconf*... -------- Forwarded Message -------- Subject: [Netconf] Virtual Interim meeting minutes Date: Wed, 13 Dec 2017 22:25:25 -0800 From: Mahesh Jethanandani To: netconf NETCONF held an interim meeting today. The rough notes from the minutes are recordedhere in the etherpad. If you attended the meeting, please review these minutes. A link to the recording is included in the etherpad. Thanks Mahesh & Kent --------------281BFD92D0DD5BB1320995F1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

FYI - keep in mind that the discussion on rfc7895bis is taking place in *netconf*...



-------- Forwarded Message --------
Subject: [Netconf] Virtual Interim meeting minutes
Date: Wed, 13 Dec 2017 22:25:25 -0800
From: Mahesh Jethanandani <mjethanandani@gmail.com>
To: netconf <netconf@ietf.org>


NETCONF held an interim meeting today. The rough notes from the minutes are recordedherein the etherpad. If you attended the meeting, please review these minutes. A link to the recording is included in the etherpad.

Thanks

Mahesh & Kent

--------------281BFD92D0DD5BB1320995F1-- From nobody Thu Dec 14 05:56:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D34812420B for ; Thu, 14 Dec 2017 05:56:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 trsOFzMlxosd for ; Thu, 14 Dec 2017 05:56:14 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20097.outbound.protection.outlook.com [40.107.2.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA589120721 for ; Thu, 14 Dec 2017 05:56:13 -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=btlxFRujXSW0ysR+uN8SuYDJmGhtWErGNZDraesLXDE=; b=pnlEvTULLNY0hnfr90B+b1W0JCZDV+o93xZx9G6rLbXtCJ36aXo+NsxM2aybKFwIpHpBQ/t3iEA7ncPN+623rBtKsv9SOpyWp4cj0sgoGVNokCkYHn3x8MLicBA1W+qSJCU9Q4PN0sjNIjDV/EKW4xA64nKZT7E7cx7xovMKL8E= Received: from VI1PR07MB3069.eurprd07.prod.outlook.com (10.175.242.143) by VI1PR07MB3069.eurprd07.prod.outlook.com (10.175.242.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Thu, 14 Dec 2017 13:56:11 +0000 Received: from VI1PR07MB3069.eurprd07.prod.outlook.com ([fe80::1eb:10d1:9548:ef11]) by VI1PR07MB3069.eurprd07.prod.outlook.com ([fe80::1eb:10d1:9548:ef11%13]) with mapi id 15.20.0323.011; Thu, 14 Dec 2017 13:56:11 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: NetMod WG Thread-Topic: Question regarding YANG model revision (in context of submodules) Thread-Index: AdN04wVjlelMQ2pASoi2ZuvaUXsjQg== Date: Thu, 14 Dec 2017 13:56:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.245.212.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3069; 6:xhxztRZzWax2LzjnTKFMtNl8PRZsCQIZdxPRRY1Ac5qo05wruC8CiueIqRpH3iCU6sLKcAhU/nm60sduR+II9osgJaY7SsYaU1icb5flgI9UMbZCaiaRrUZGdRePmyYIJzBqCNs580li0sjeIk1KlNZO7l3N7sfBKcsCgQGc3kGL1xVyaQBFflDIELt6oygzmEJgKZyV9SdJ7MdkZf3rHAw/dnLnIBGVtJyV4N59pjAOYrMl2hGRo9GxP3HK7Aium4n4LJUbKM5jiT3GBuQgXpxDiK6JynnFxe1+lOyWI9/CIx0S/6fa/NnAAE0jk2MNHaT+1IGxikBk42An8aIRLJBzZA/Kykxoya52/G1RXoc=; 5:DP4bfRgTh4bQsoF2btNiQwx54xyzydoHfyj2ESmr3dllmLDxNgJPmWhiUQAAx989/0tL/c9JiLa8fQtLbAeo879/+whu5ew7GQ1nujUTYHNPaU/oP00i0DBq6okUh4KaGZC2YAAs88tlCv1BThz40S+admobxpKwCmHWFfk5jsc=; 24:nHwnA2k8ymtKzLCZf2dT64+aYAUUMWNapLlxzsI+hm38thE8e6Sm4GsEx/7o3DLjt+SxOoRiAUsJ44PTvp6OjgZFOKKuNhbpEf7RF12kjgA=; 7:aOOh6kMSH1YKvn/uSr9CRJRY9gp2qfLj2iXqFV7txz9McJFxepHbI3Tsp4+XL2oo+924t1bhZUJo1c+3tUON6VtStgru86BBT1qyNl991oVbY6KSdDXIiwsAqZ7AQ54XeuQaSBviw0drb6293NszEZf9Imkvz5GuK3kkmeY0vMfORW5jmRUzeUBXnhe+YrfZgZitrGTPnFMQJFYZpeLCn13SprJXEiAVGUvf9vL66+fUl+UZ/sadNN54w3ahdCNv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 793ae7cb-14ab-40fd-9ecc-08d542fa6ed4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(49563074); SRVR:VI1PR07MB3069; x-ms-traffictypediagnostic: VI1PR07MB3069: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231023)(11241501184)(806099)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011); SRVR:VI1PR07MB3069; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3069; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(366004)(189003)(199004)(9326002)(68736007)(478600001)(7696005)(106356001)(5250100002)(66066001)(33656002)(105586002)(99286004)(99936001)(7736002)(5660300001)(74316002)(81166006)(81156014)(8676002)(14454004)(8936002)(6436002)(55016002)(9686003)(6306002)(102836003)(790700001)(54896002)(316002)(6116002)(97736004)(3280700002)(6916009)(3846002)(3660700001)(53936002)(6506007)(86362001)(2900100001)(25786009)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3069; H:VI1PR07MB3069.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: fYQqaaEEugFyH4giKb2mca2onHQ+dLFN4pCU1SvD3gVBI3IRpIzVj7aE4d9tsx/qjTztVqHjYGjTqKbM3+GDRA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0149_01D374EB.AD3ABA00" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 793ae7cb-14ab-40fd-9ecc-08d542fa6ed4 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 13:56:11.0384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3069 Archived-At: Subject: [netmod] Question regarding YANG model revision (in context of submodules) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2017 13:56:16 -0000 ------=_NextPart_000_0149_01D374EB.AD3ABA00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_014A_01D374EB.AD3AE110" ------=_NextPart_001_014A_01D374EB.AD3AE110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I've been looking in various documents w.r.t. the usage of a model revision statement, especially in the case where the YANG model is split up in various submodules. Assume that one of the included submodules is changed and gets a new revision while the model this submodule belongs-to is not updated. How is a client supposed to know that there was a change? The YANG library does include a list of submodules for each YANG model but is it expected to scan that list? What in case there is no YANG library (this is only mandatory in the case of YANG 1.1)? In the hello, only the revision of the YANG model is announced, so in that case no change would be visible although there is one. Is there some explicit statement in RFC 7950 or 6087bis on this (meaning that if a submodule gets a new revision, the revision of the owning YANG model must also be updated)? There are statements that imply that this could be done (e.g. by specifying the revision-data when doing the include but if no revision data is specified the behavior is "undefined" meaning that the version of the submodule that is stored on the server will be used but still leaves room for uncertainty). Regards, Bart ------=_NextPart_001_014A_01D374EB.AD3AE110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve been looking in various documents w.r.t. the = usage of a model revision statement, especially in the case where the = YANG model is split up in various submodules.

Assume that one of the included = submodules is changed and gets a new revision while the model this = submodule belongs-to is not updated.  How is a client supposed to = know that there was a change?

The YANG library does include a = list of submodules for each YANG model but is it expected to scan that = list?  What in case there is no YANG library (this is only = mandatory in the case of YANG 1.1)?  In the hello, only the = revision of the YANG model is announced, so in that case no change would = be visible although there is one.

Is there some explicit statement in = RFC 7950 or 6087bis on this (meaning that if a submodule gets a new = revision, the revision of the owning YANG model must also be = updated)?  There are statements that imply that this could be done = (e.g. by specifying the revision-data when doing the include but if no = revision data is specified the behavior is “undefined” = meaning that the version of the submodule that is stored on the server = will be used but still leaves room for = uncertainty).

 

Regards, Bart

------=_NextPart_001_014A_01D374EB.AD3AE110-- ------=_NextPart_000_0149_01D374EB.AD3ABA00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEyMTQxMzU2MDlaMCMGCSqGSIb3DQEJBDEWBBTxmSYx Ba0Y5856z1j7KdvEeNWI3zCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAGuHgsFa5Utv4oAabKuCtGGQJvHKmE/IKh/4JjjzIDWqzqY+tbSctNFbJCRC snU7ef+UeZHuJmbwsJTzcJb4liYMag6wAcfODqL+pBDmH79xXXGkGGxhZRmKO2ymRhDJr8z5E/68 n2RyVvHmtKqHDKaebydoQgRjdRhV03dLW+fF4hzdvtx3bmmREkfga/z01I0+mYfIJFtf3wCQTkl2 rwv1R33Jck9T82lC6QKOV6SuFYyWXqITFktJHOQSvmntOvexfLBT7anLAEKp0gLyK3qDJHvQUriI HFn1pwFBUNoABuRG1HoR8/Wsq5oPGvfoWzOOdg+6WfjBpUPDKbw6GWYAAAAAAAA= ------=_NextPart_000_0149_01D374EB.AD3ABA00-- From nobody Thu Dec 14 09:05:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADD7128961; Thu, 14 Dec 2017 09:05:34 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 K1kEchhiMSCq; Thu, 14 Dec 2017 09:05:28 -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 48D69126C0F; Thu, 14 Dec 2017 09:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16160; q=dns/txt; s=iport; t=1513271128; x=1514480728; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HX+/CX5x5mNc07lvvkip6uhw+RXGx84lIkNi457CqRo=; b=GHq6ihdj0KDAbKwlX5kdgAWlyjfp+UwHn01SmcOQ922LzRJ57c83PgfM Zp205HU/5OBzLWGji4hAs2KAaU772eX7ZjU3y4SUv8UtQQJJHiseCdkQZ uROvNxBPpypDxyq0OKAANu08rVbdVHpwkaBTS53jwINIqqT6LmEH57DcD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAwAZrjJa/4YNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPmZ0JweDe5hzNIFXJpcWghUKGAuESU8CGoRdQBcBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQIBAQEhEToLDAQCAQgRBAEBAQICJgICAiULFQgIAgQBDQWKI?= =?us-ascii?q?ggQqRKCJ4peAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JWgg6BVoFpKQuCd4J?= =?us-ascii?q?QXgGBRBQWF4J+MYIyBZIVkRACh3uNLYIWhhKLRI0ViSsCERkBgToBIAE3gU5vF?= =?us-ascii?q?ToqAYF+glMcgWd4iUGBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,400,1508803200"; d="scan'208";a="326233291" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 17:05:26 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vBEH5RoF007204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 17:05:27 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 11:05:26 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 11:05:26 -0600 From: "Clyde Wildes (cwildes)" To: "t.petch" , "Benoit Claise (bclaise)" , Kent Watsen , "netmod@ietf.org" CC: "draft-ietf-netmod-syslog-model@ietf.org" Thread-Topic: [netmod] syslog-model-17 shepherd writeup issues -references Thread-Index: AQHTLHc0MtKErjQWME+Yl1a8S7HtcKKzYLeAgAEvaqSAAFV3AIAUCv4AgAAAaICAelr0EYAAuygA Date: Thu, 14 Dec 2017 17:05:26 +0000 Message-ID: <872D5B29-8411-44AE-BAD2-BAA7D1F50F7B@cisco.com> References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net> <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net> <5CE9EE07-D75D-4E5C-BC70-1F969732A526@juniper.net> <8e873d52-a6bd-87ee-9ff5-62c85eb5b6dc@cisco.com> <8015AC50-45CE-4813-B77B-8D1D3D3BC349@cisco.com> <004401d374d1$e1fb3540$4001a8c0@gateway.2wire.net> In-Reply-To: <004401d374d1$e1fb3540$4001a8c0@gateway.2wire.net> 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.154.131.70] Content-Type: text/plain; charset="utf-8" Content-ID: <0F88A3EB64A44A4A943920CDD67DDD0C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Dec 2017 17:05:34 -0000 VG9tLA0KDQpUaGlzIGRvZXMgbm90IHNhdGlzZnkgdGhlIHJlZmVyZW5jZSByZXF1aXJlbWVudD8N Cg0KICAgIGxlYWYgcGF0dGVybi1tYXRjaCB7DQogICAgICBpZi1mZWF0dXJlIHNlbGVjdC1tYXRj aDsNCiAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIlRoaXMg bGVhZiBkZXNjcmliZXMgYSBQb3NpeCAxMDAzLjIgcmVndWxhciBleHByZXNzaW9uIA0KICAgICAg ICAgc3RyaW5nIHRoYXQgY2FuIGJlIHVzZWQgdG8gc2VsZWN0IGEgc3lzbG9nIG1lc3NhZ2UgZm9y IA0KICAgICAgICAgbG9nZ2luZy4gVGhlIG1hdGNoIGlzIHBlcmZvcm1lZCBvbiB0aGUgU1lTTE9H LU1TRyBmaWVsZC4iOw0KICAgICAgcmVmZXJlbmNlDQogICAgICAgICJSRkMgNTQyNDogVGhlIFN5 c2xvZyBQcm90b2NvbA0KICAgICAgICAgU3RkLTEwMDMuMS0yMDA4IFJlZ3VsYXIgRXhwcmVzc2lv bnMiOw0KICAgIH0NCg0KUGxlYXNlIGhlbHAgbWUgdW5kZXJzdGFuZCB3aGF0IG1vcmUgeW91IHdh bnQuDQoNClRoYW5rcywNCg0KQ2x5ZGUNCg0KT24gMTIvMTQvMTcsIDM6NTUgQU0sICJ0LnBldGNo IiA8aWV0ZmNAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQoNCiAgICBDbHlkZQ0KICAgIA0KICAgIEEg cXVpY2sgZ2xhbmNlIGF0IC0xOCBzaG93cyB0aGF0IHRoZXJlIGlzIG5vdyBhIE5vcm1hdGl2ZSBS ZWZlcmVuY2UgZm9yDQogICAgUG9zaXggLSBnb29kLSBidXQgSSBkbyBub3Qgc2VlIGl0IHJlZmVy ZW5jZWQgLSBub3Qgc28gZ29vZDotKA0KICAgIA0KICAgIEkgdGhpbmsgdGhhdCB0aGVyZSBuZWVk cyB0byBiZSBhIHJlZmVyZW5jZSBpbiA0LjENCiAgICANCiAgICBUb20gUGV0Y2gNCiAgICANCiAg ICANCiAgICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQogICAgRnJvbTogIkNseWRlIFdp bGRlcyAoY3dpbGRlcykiIDxjd2lsZGVzQGNpc2NvLmNvbT4NCiAgICBUbzogIkJlbm9pdCBDbGFp c2UgKGJjbGFpc2UpIiA8YmNsYWlzZUBjaXNjby5jb20+OyAiS2VudCBXYXRzZW4iDQogICAgPGt3 YXRzZW5AanVuaXBlci5uZXQ+OyAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+Ow0KICAg IDxuZXRtb2RAaWV0Zi5vcmc+DQogICAgQ2M6IDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9k ZWxAaWV0Zi5vcmc+DQogICAgU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTcgNToy NiBQTQ0KICAgIFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBzeXNsb2ctbW9kZWwtMTcgc2hlcGhlcmQg d3JpdGV1cA0KICAgIGlzc3VlcyAtcmVmZXJlbmNlcw0KICAgIA0KICAgIA0KICAgID4gQmVub2l0 LA0KICAgID4NCiAgICA+IFRoZXJlIHdlcmUgYXBwcm94aW1hdGVseSAyNCBjaGFuZ2VzIHJlcXVl c3RlZCBmcm9tIHlvdSwgS2VudCwgUm9iZXJ0DQogICAgV2lsdG9uLCBhbmQgVG9tIFBldGNoLiBJ IGhhdmUgbWFkZSBhcHByb3hpbWF0ZWx5IGhhbGYgb2YgdGhlbSBhbmQgd2lsbA0KICAgIHRyeSB0 byBmaW5pc2ggYW5vdGhlciByZXZpc2lvbiBvZiB0aGUgZHJhZnQgYnkgRnJpZGF5Lg0KICAgID4N CiAgICA+IFRoYW5rcywNCiAgICA+DQogICAgPiBDbHlkZQ0KICAgID4NCiAgICA+IE9uIDkvMjcv MTcsIDM6MjQgQU0sICJCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKSIgPGJjbGFpc2VAY2lzY28uY29t Pg0KICAgIHdyb3RlOg0KICAgID4NCiAgICA+ICAgICBDbHlkZSwNCiAgICA+DQogICAgPiAgICAg RG8geW91IGtub3cgeW91ciBuZXh0IHN0ZXAgdG8gcHJvZ3Jlc3MgdGhpcyBkb2N1bWVudD8NCiAg ICA+DQogICAgPiAgICAgUmVnYXJkcywgQmVub2l0DQogICAgPiAgICAgPiBJIG1lYW50IHRvIHNh eSBzb21ldGhpbmcgYWJvdXQgdGhlIC4xIHZzIC4yIGRpZmZlcmVuY2UuICBNeQ0KICAgIGNvbW1l bnQNCiAgICA+ICAgICA+IGFzc3VtZXMgdGhhdCBpdCdzIHN1cHBvc2VkIHRvIGJlIC4xLCBidXQg d2Ugb2YgY291cnNlIHNob3VsZCB1c2UNCiAgICA+ICAgICA+IHdoYXRldmVyIGlzIGNvcnJlY3Qu DQogICAgPiAgICAgPg0KICAgID4gICAgID4gSSBhbHNvIGRvbid0IGtub3cgbXVjaCBhYm91dCB0 aGF0IHN0YW5kYXJkcyBib2R5Lg0KICAgID4gICAgID4NCiAgICA+ICAgICA+IEsuDQogICAgPiAg ICAgPg0KICAgID4gICAgID4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQogICAgPiAgICAgPiBGcm9tOiAiS2VudCBXYXRzZW4iIDxrd2F0c2Vu QGp1bmlwZXIubmV0Pg0KICAgID4gICAgID4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTMs IDIwMTcgNjowOCBQTQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+PiBIaSBUb20sDQogICAgPiAg ICAgPj4NCiAgICA+ICAgICA+PiBUaGFua3MuICBUaGUgZml4IEknbSBsb29raW5nIGZvciBpcyBm b3IgdGhlICdwYXR0ZXJuLW1hdGNoJw0KICAgIGxlYWYNCiAgICA+ICAgICA+PiB0byBoYXZlIGEg J3JlZmVyZW5jZScgc3RhdGVtZW50IHRvIFN0ZC0xMDAzLjEtMjAwOCwgYW5kIGZvcg0KICAgIFM0 LjENCiAgICA+ICAgICA+PiB0byBhbHNvIGxpc3QgU3RkLTEwMDMuMS0yMDA4IGFzIGEgZHJhZnQt bGV2ZWwgcmVmZXJlbmNlLg0KICAgID4gICAgID4gYW5kIEkgYW0gdW5mYW1pbGlhciB3aXRoIHRo YXQgc3RhbmRhcmRzIGJvZHkgc28gYW0gbG9va2luZyBmb3IgYQ0KICAgIGxpdHRsZQ0KICAgID4g ICAgID4gbW9yZS4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBJcyBTVEQtbm5ubiBhbHdheXMg UG9zaXggb3IgZG8gd2UgbmVlZCB0byBzYXkgUG9zaXggMTAwMyBvcg0KICAgIFBvc2l4DQogICAg PiAgICAgPiBTdGQtMTAwMyBvciBpcyBTdGQtMTAwMyBjb21wbGV0ZWx5IHVucmVsYXRlZCB0byBQ b3NpeCAxMDAzPw0KICAgID4gICAgID4NCiAgICA+ICAgICA+IElzIHRoZXJlIGEgZGlmZmVyZW5j ZSBiZXR3ZWVuIFN0ZC0xMDAzLjEtMjAwOCBhbmQgUG9zaXggMTAwMy4yDQogICAgaWUgaXMgdGhl DQogICAgPiAgICAgPiAuMSBvciAuMiBzaWduaWZpY2FudD8gIFlvdSB3YW50IFN0ZC0xMDAzLjE7 IHRoZSBkZXNjcmlwdGlvbg0KICAgIGNvbnRhaW5zDQogICAgPiAgICAgPiBQb3NpeCAxMDAzLjI7 IHRoZSBub3JtYXRpdmUgUmVmZXJlbmNlIGlzIHRvIFN0ZC0xMDAzLjEtMjAwOC4NCiAgICA+ICAg ICA+DQogICAgPiAgICAgPiBZb3UgcG9pbnRlZCBvdXQgdGhhdCB0aGUgTm9ybWF0aXZlIFJlZmVy ZW5jZSBpcyBub3QgdXNlZDsgd2VsbA0KICAgIGlmIHdlIGNhbg0KICAgID4gICAgID4gc29ydCBv dXQgd2hhdCB0aGUgc3RhbmRhcmQgaXMgYW5kIGdldCB0aGUgcmlnaHQgbGFiZWwgaW4NCiAgICBO b3JtYXRpdmUNCiAgICA+ICAgICA+IFJlZmVyZW5jZXMgdGhlbiB3ZSBjYW4gLSBtdXN0IC0gaW5j bHVkZSB0aGlzIGluIFNlY3Rpb24gNC4xDQogICAgd2hpY2ggd2lsbA0KICAgID4gICAgID4gcmVz b2x2ZSB0aGF0IGNvbW1lbnQgb2YgeW91cnMuDQogICAgPiAgICAgPg0KICAgID4gICAgID4gVGhl IGRpc2N1c3Npb25zIGxhc3QgSnVseSBoYWQgQ2x5ZGUgc2F5aW5nIGhlIHdhbnRzIFBvc2l4IDEw MDMuMg0KICAgIHNvIGlmDQogICAgPiAgICAgPiBTdGQtMTAwMyBhbmQgUG9zaXggMTAwMyBhcmUg dGhlIHNhbWUgYnV0IC4xIGFuZC4yIGFyZSBkaWZmZXJlbnQsDQogICAgdGhlbg0KICAgID4gICAg ID4geW91IGFyZSBhc2tpbmcgZm9yIGEgc2VtYW50aWMgY2hhbmdlIGFnYWluc3QgQ2x5ZGUncyB3 aXNoZXMuDQogICAgPiAgICAgPg0KICAgID4gICAgID4gSSBob3BlIG15IGNvbmZ1c2lvbiBpcyBz dWZmaWNpZW50bHkgY2xlYXIsIGF0IGxlYXN0IHRvIENseWRlIQ0KICAgID4gICAgID4NCiAgICA+ ICAgICA+IFRvbSBQZXRjaA0KICAgID4gICAgID4NCiAgICA+ICAgICA+PiBJIHdhcyBnb2luZyB0 byBwb2ludCBvdXQgdGhlIHR5cG8gInRoZSB0aGUiIGFzIHdlbGwsIGJ1dA0KICAgIGZpZ3VyZWQN CiAgICA+ICAgICA+PiB0aGF0IHRoZSBSRkMgRWRpdG9yIHdvdWxkIGdldCBpdC4NCiAgICA+ICAg ICA+Pg0KICAgID4gICAgID4+IEsuIC8vIHNoZXBoZXJkDQogICAgPiAgICAgPj4NCiAgICA+ICAg ICA+Pg0KICAgID4gICAgID4+IC0tDQogICAgPiAgICAgPj4NCiAgICA+ICAgICA+PiBLZW50DQog ICAgPiAgICAgPj4NCiAgICA+ICAgICA+PiBZb3UgZmxhZyBTdGQtMTAwMy4xLTIwMDggYXMgbGlz dGVkIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBidXQNCiAgICBub3QNCiAgICA+ICAgICA+IHVz ZWQNCiAgICA+ICAgICA+PiBhbnl3aGVyZSBpbiB0aGUgZG9jdW1lbnQuICBJbiB0aGUgRGVzY3Jp cHRpb25zLCBidXQgbm90IGluIHRoZQ0KICAgIHMuNC4xDQogICAgPiAgICAgPj4gcmVmZXJlbmNl cywgSSBzZWUNCiAgICA+ICAgICA+Pg0KICAgID4gICAgID4+IFRoaXMgbGVhZiBkZXNjcmliZXMg YSBQb3NpeCAxMDAzLjIgcmVndWxhciBleHByZXNzaW9uIC4uLg0KICAgID4gICAgID4+DQogICAg PiAgICAgPj4gdHdpY2UsIHdoaWNoIG1heSwgb3IgbWF5IG5vdCwgcmVsYXRlIHRvIHRoaXMgaXNz dWUuDQogICAgPiAgICAgPj4NCiAgICA+ICAgICA+PiBCYWNrIGluIEp1bHksIGNseWRlIHNhaWQN CiAgICA+ICAgICA+PiAiSSB3aWxsIGluc2VydCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUE9T SVggMTAwMy4yIGluIHRoZQ0KICAgIG5leHQNCiAgICA+ICAgICA+PiByZXZpc2lvbiBvZiB0aGUg ZHJhZnQuIg0KICAgID4gICAgID4+DQogICAgPiAgICAgPj4gSW4gYSBzaW1pbGFyIHZlaW4sIFJG QzY5OTEgYXBwZWFycyBpbiBhIHJlZmVyZW5jZSBzdGF0ZW1lbnQgYnV0DQogICAgPiAgICAgPiBu b3doZXJlDQogICAgPiAgICAgPj4gZWxzZS4NCiAgICA+ICAgICA+Pg0KICAgID4gICAgID4+IEFz IHlvdSBwb2ludCBvdXQsIFJGQzYwMjEgaXMgcmVmZXJlbmNlZCBidXQgaXMgb2Jzb2xldGVkIGJ5 DQogICAgUkZDNjk5MSBzbw0KICAgID4gICAgID4+IHNob3VsZCBub3QgYmUuDQogICAgPiAgICAg Pj4NCiAgICA+ICAgICA+PiBBbmQgaW4gYSBzbGlnaHRseSBkaWZmZXJlbnQgdmVpbiwNCiAgICA+ ICAgICA+Pg0KICAgID4gICAgID4+ICAgICByZWdpc3RyeSBbUkZDNzg5NV0vPi4gIEZvbGxvd2lu ZyB0aGUgZm9ybWF0IGluIFtSRkM3OTUwXS8+LA0KICAgIHRoZSB0aGUNCiAgICA+ICAgICA+Pg0K ICAgID4gICAgID4+IGxvb2tzIG9kZCBmb3IgcGxhaW4gdGV4dCBhbmQgZm9yIHRoZSByZXBldGl0 aW9uIG9mICd0aGUnLi4NCiAgICA+ICAgICA+Pg0KICAgID4gICAgID4+IFRvbSBQZXRjaA0KICAg ID4gICAgID4+DQogICAgPiAgICAgPj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICAg ID4gICAgID4+IEZyb206ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+DQogICAg PiAgICAgPj4gVG86IDxuZXRtb2RAaWV0Zi5vcmc+DQogICAgPiAgICAgPj4gQ2M6IDxkcmFmdC1p ZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc+DQogICAgPiAgICAgPj4gU2VudDogVHVl c2RheSwgU2VwdGVtYmVyIDEyLCAyMDE3IDEwOjUwIFBNDQogICAgPiAgICAgPj4gU3ViamVjdDog W25ldG1vZF0gc3lzbG9nLW1vZGVsLTE3IHNoZXBoZXJkIHdyaXRldXAgaXNzdWVzDQogICAgPiAg ICAgPj4NCiAgICA+ICAgICA+Pg0KICAgID4gICAgID4+PiBDbHlkZSwgYWxsLA0KICAgID4gICAg ID4+Pg0KICAgID4gICAgID4+PiBJbiByZXZpZXdpbmcgdGhlIGRyYWZ0IGZvciBTaGVwaGVyZCB3 cml0ZXVwLCBJIGZvdW5kIHRoZQ0KICAgIGZvbGxvd2luZw0KICAgID4gICAgID4+IGlzc3VlcyB0 aGF0IEkgdGhpbmsgbmVlZCB0byBiZSBhZGRyZXNzZWQgYmVmb3JlIHRoZSBkb2N1bWVudA0KICAg IGNhbiBiZQ0KICAgID4gICAgID4gc2VudA0KICAgID4gICAgID4+IHRvIEJlbm9pdCBmb3IgQUQg cmV2aWV3Og0KICAgID4gICAgID4+Pg0KICAgID4gICAgID4+PiAxLiBJZG5pdHMgZm91bmQgdGhl IGZvbGxvd2luZzoNCiAgICA+ICAgICA+Pj4NCiAgICA+ICAgICA+Pj4gICAgU3VtbWFyeTogMyBl cnJvcnMgKCoqKSwgMCBmbGF3cyAofn4pLCAzIHdhcm5pbmdzICg9PSksIDENCiAgICBjb21tZW50 DQogICAgPiAgICAgPj4gKC0tKS4NCiAgICA+ICAgICA+Pj4gICAgICAqKiBUaGVyZSBhcmUgMiBp bnN0YW5jZXMgb2YgdG9vIGxvbmcgbGluZXMgaW4gdGhlDQogICAgZG9jdW1lbnQsIHRoZQ0KICAg ID4gICAgID4+IGxvbmdlc3Qgb25lDQogICAgPiAgICAgPj4+ICAgICAgICAgICBiZWluZyAzIGNo YXJhY3RlcnMgaW4gZXhjZXNzIG9mIDcyLg0KICAgID4gICAgID4+Pg0KICAgID4gICAgID4+PiAg ICAgICoqIE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6IFJGQyA2MDIxIChPYnNvbGV0ZWQg YnkNCiAgICBSRkMNCiAgICA+ICAgICA+IDY5OTEpDQogICAgPiAgICAgPj4+ICAgICAgKiogRG93 bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBIaXN0b3JpYyBSRkM6IFJGQw0KICAgIDY1 ODcNCiAgICA+ICAgICA+Pj4NCiAgICA+ICAgICA+Pj4gICAgICA9PSBNaXNzaW5nIFJlZmVyZW5j ZTogJ1JGQzU0MjUnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDM1OSwNCiAgICBidXQNCiAgICA+ICAg ICA+IG5vdA0KICAgID4gICAgID4+IGRlZmluZWQNCiAgICA+ICAgICA+Pj4gICAgICAgICAgICdb UkZDNTQyNV0sIFtSRkM1NDI2XSwgW1JGQzY1ODddLCBhbmQgW1JGQzU4NDhdLi4uLicNCiAgICA+ ICAgICA+Pj4NCiAgICA+ICAgICA+Pj4gICAgICAgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzc4 OTUnIGlzIGRlZmluZWQgb24gbGluZSAxNDA2LA0KICAgIGJ1dCBubw0KICAgID4gICAgID4+IGV4 cGxpY2l0DQogICAgPiAgICAgPj4+ICAgICAgICAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0 aGUgdGV4dA0KICAgID4gICAgID4+PiAgICAgICAgICAgICdbUkZDNzg5NV0gIEJpZXJtYW4sIEEu LCBCam9ya2x1bmQsIE0uLCBhbmQgSy4NCiAgICBXYXRzZW4sDQogICAgPiAgICAgPiAiWUFORw0K ICAgID4gICAgID4+IE1vZHVsZSBMLi4uJw0KICAgID4gICAgID4+PiAgICAgICA9PSBVbnVzZWQg UmVmZXJlbmNlOiAnUkZDNjI0MicgaXMgZGVmaW5lZCBvbiBsaW5lIDE0MzUsDQogICAgYnV0IG5v DQogICAgPiAgICAgPj4gZXhwbGljaXQNCiAgICA+ICAgICA+Pj4gICAgICAgICAgICByZWZlcmVu Y2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0DQogICAgPiAgICAgPj4+ICAgICAgICAgICAgJ1tSRkM2 MjQyXSAgV2Fzc2VybWFuLCBNLiwgIlVzaW5nIHRoZSBORVRDT05GDQogICAgUHJvdG9jb2wNCiAg ICA+ICAgICA+IG92ZXINCiAgICA+ICAgICA+PiBTZWN1cmUgU2guLi4nDQogICAgPiAgICAgPj4+ DQogICAgPiAgICAgPj4+IDIuIGByZmNzdHJpcGAgZXh0cmFjdGVkICJpZXRmLXN5c2xvZy55YW5n IiwgIHdoaWNoIGlzIG1pc3NpbmcNCiAgICA+ICAgICA+PiAiQHl5eXktbW0tZGQiIGluIGl0cyBu YW1lDQogICAgPiAgICAgPj4+IDMuICBuZWl0aGVyIGBweWFuZ2Agbm9yIGB5YW5nbGludGAgZm91 bmQgYW55IGVycm9ycyB3aXRoDQogICAgPiAgICAgPj4gaWV0Zi1zeXNsb2cueWFuZy4gICAgcHlh bmcgc2F5cw0KICAgID4gICAgID4+PiAgICAgICAgZm9yIHZlbmRvci1zeXNsb2ctdHlwZXMtZXhh bXBsZTogc3RhdGVtZW50ICJpZGVudGl0eSINCiAgICBtdXN0DQogICAgPiAgICAgPiBoYXZlDQog ICAgPiAgICAgPj4gYSAiZGVzY3JpcHRpb24iDQogICAgPiAgICAgPj4+ICAgICAgICBzdWJzdGF0 ZW1lbnQuDQogICAgPiAgICAgPj4+DQogICAgPiAgICAgPj4+IDQuIHRlc3RpbmcgdGhlIGV4YW1w bGVzIGluIHRoZSBkcmFmdCBhZ2FpbnN0IHlhbmdsaW50Og0KICAgID4gICAgID4+PiAgICAgICAg LSBmb3IgYm90aCBleGFtcGxlczogTWlzc2luZyBlbGVtZW50J3MgIm5hbWVzcGFjZSIuDQogICAg KC9jb25maWcpDQogICAgPiAgICAgPj4+ICAgICAgICAtIGp1c3QgcmVtb3ZpbmcgdGhlICI8Y29u ZmlnPiIgZWxlbWVudCBlbnZlbG9wIHJlc29sdmVzDQogICAgdGhpcw0KICAgID4gICAgID4+IGVy cm9yLg0KICAgID4gICAgID4+PiA1LiB0aGUgMm5kIGV4YW1wbGUgdXNlcyBJUCBhZGRyZXNzICIy MDAxOmRiODphMGI6MTJmMDo6MSIsIGJ1dA0KICAgIHRoaXMNCiAgICA+ICAgICA+PiBTSE9VTEQg YmUgYQ0KICAgID4gICAgID4+PiAgICAgICBkb21haW4gbmFtZSAoZS5nLiwgZm9vLmV4YW1wbGUu Y29tKQ0KICAgID4gICAgID4+Pg0KICAgID4gICAgID4+PiA2LiBpbiB0aGUgWUFORyBtb2R1bGUs IGFueXdoZXJlIHlvdSBoYXZlIGFuIFJGQyBsaXN0ZWQgaW4gYQ0KICAgID4gICAgID4+ICdkZXNj cmlwdGlvbicgc3RhdGVtZW50LA0KICAgID4gICAgID4+PiAgICAgICB0aGVyZSBzaG91bGQgYmUg YSAncmVmZXJlbmNlJyBzdGF0ZW1lbnQgZm9yIHRoYXQgUkZDLg0KICAgID4gICAgID4+Pg0KICAg ID4gICAgID4+PiA3LiBpbiB0aGUgdHJlZSBkaWFncmFtLCB0aGUgbGVhZnJlZnMgbm8gbG9uZ2Vy IGluZGljYXRlIHdoYXQNCiAgICB0aGV5DQogICAgPiAgICAgPj4gcG9pbnQgYXQsIHRoZXkgbm93 IGFsbA0KICAgID4gICAgID4+PiAgICAgICBqdXN0IHNheSAibGVhZnJlZiIuICBEaWQgeW91IGRv IHRoaXMgb24gcHVycG9zZSwgb3IgYXJlDQogICAgeW91DQogICAgPiAgICAgPiB1c2luZw0KICAg ID4gICAgID4+IGEgZGlmZmVyZW50IHRyZWUNCiAgICA+ICAgICA+Pj4gICAgICAgb3V0cHV0IGdl bmVyYXRvciBmcm9tIC0xNT8NCiAgICA+ICAgICA+Pj4NCiAgICA+ICAgICA+Pj4gOC4gUkZDNjUz NiBpcyBsaXN0ZWQgYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlLCBidXQgaXQgcHJvYmFibHkNCiAg ICA+ICAgICA+IHNob3VsZA0KICAgID4gICAgID4+IGJlIGluZm9ybWF0aXZlLg0KICAgID4gICAg ID4+PiA5LiBTdGQtMTAwMy4xLTIwMDggaXMgbGlzdGVkIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5j ZSwgYnV0IGl0DQogICAgaXMgbm90DQogICAgPiAgICAgPj4gdXNlZCBhbnl3aGVyZSBpbiB0aGUg ZG9jdW1lbnQuDQogICAgPiAgICAgPj4+IDEwLiBSRkM2MjQyIGlzIGxpc3RlZCBhcyBhbiBpbmZv cm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpdCBpcw0KICAgIG5vdA0KICAgID4gICAgID4gdXNlZA0K ICAgID4gICAgID4+IGFueXdoZXJlIGluIHRoZSBkb2N1bWVudC4NCiAgICA+ICAgICA+Pj4gMTEu IHRoZSBkb2N1bWVudCBmYWlscyB0byBkZWNsYXJlIGl0cyBub3JtYXRpdmUgcmVmZXJlbmNlcyB0 bw0KICAgID4gICAgID4+IGlldGYta2V5c3RvcmUgYW5kIGlldGYtdGxzLWNsaWVudC1zZXJ2ZXIu DQogICAgPiAgICAgPj4+ICAgICAgICAgIE5vdGU6IHlvdSBtYW51YWxseSBlbnRlcmVkIHRoZSAi W1JGQyB5eXl5XSwgYW5kIFtSRkMNCiAgICB4eHh4XSINCiAgICA+ICAgICA+PiByZWZlcmVuY2Vz 4oCmDQogICAgPiAgICAgPj4+IDEyLiAgVGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBz ZWVtcyBhc3ltbWV0cmljLiAgRWl0aGVyDQogICAgcHV0DQogICAgPiAgICAgPj4gYm90aCByZWdp c3RyeSBpbnNlcnRpb25zIGludG8NCiAgICA+ICAgICA+Pj4gICAgICAgICAgc3Vic2VjdGlvbnMs IG9yIGtlZXAgdGhlbSBib3RoIGF0IHRoZSB0b3AtbGV2ZWzigKYNCiAgICA+ICAgICA+Pj4NCiAg ICA+ICAgICA+Pj4gMTMuIHJldmlld2luZyB0aGUgZmluYWwgZG9jdW1lbnQgYWdhaW5zdCBteSBv cmlnaW5hbCBZRA0KICAgIHJldmlldywgSQ0KICAgID4gICAgID4gaGF2ZQ0KICAgID4gICAgID4+ IHRoZSBmb2xsb3dpbmcgcmVzcG9uc2VzLiAgTGV0J3MgYmUgc3VyZSB0byBjbG9zZSBvdXQgdGhl c2UNCiAgICBpdGVtcyBhcw0KICAgID4gICAgID4+IHdlbGwuICBSZWY6DQogICAgPiAgICAgPiBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC8xMGxvNDFVZDRBM1pO MTENCiAgICA+ICAgICA+PiBzLTBnT2ZDZThOU0UNCiAgICA+ICAgICA+Pj4gMS4gb2sNCiAgICA+ ICAgICA+Pj4gMi4gYmV0dGVyDQogICAgPiAgICAgPj4+IDMuIHNob3VsZCBiZTogcy90aGUgbWVz c2FnZS90aGVzZSBtZXNzYWdlcy8gIFtSRkMgRWRpdG9yDQogICAgbWlnaHQndmUNCiAgICA+ICAg ICA+PiBjYXVnaHQgdGhpc10NCiAgICA+ICAgICA+Pj4gNC4gYmV0dGVyDQogICAgPiAgICAgPj4+ IDUuIHN0aWxsIGZlZWwgdGhlIHNhbWUgd2F5LCBidXQgbm8gYmlnZ2VlDQogICAgPiAgICAgPj4+ IDYuIGJldHRlciwgYnV0IGZyb20gODE3NCwgeW91IHNob3VsZCBhZGQgdGhlIHBhcnQgIndoZW4s IGFuZA0KICAgIG9ubHkNCiAgICA+ICAgICA+PiB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwgY2Fw aXRhbHMsIGFzIHNob3duIGhlcmUuIg0KICAgID4gICAgID4+PiA3LiBmaXhlZA0KICAgID4gICAg ID4+PiA4LiBmaXhlZA0KICAgID4gICAgID4+PiA5LiB5b3UgZGlkIHdoYXQgSSBhc2tlZCwgYnV0 IHRoZSByZXN1bHQgc3RpbGwgaXNuJ3QNCiAgICBzYXRpc2Z5aW5nLi4uDQogICAgPiAgICAgPj4+ IDEwLiBzb21lIGltcHJvdmVtZW50cyBtYWRlIGluIHRoaXMgYXJlYSwgYnV0IG15IGFzayB3YXNu J3QNCiAgICBhbW9uZw0KICAgID4gICAgID4gdGhlbQ0KICAgID4gICAgID4+PiAxMS4gYmV0dGVy DQogICAgPiAgICAgPj4+IDEyLiBiZXR0ZXIsIGJ1dCBJIHRoaW5rIHRoZSA0dGggbGluZSBzaG91 bGQgYmUgaW5kZW50ZWQgdG9vLA0KICAgIHJpZ2h0Pw0KICAgID4gICAgID4+PiAxMy4gYmV0dGVy LCBidXQgSSB3aXNoIHlvdSBjYWxsZWQgUzEuMyAiVHJlZSBEaWFncmFtIE5vdGF0aW9uIg0KICAg ID4gICAgID4+PiAxNC4gZml4ZWQNCiAgICA+ICAgICA+Pj4gMTUuIGZpeGVkDQogICAgPiAgICAg Pj4+IDE2LiBmaXhlZA0KICAgID4gICAgID4+PiAxNy4gZmluZQ0KICAgID4gICAgID4+PiAxOC4g c3RpbGwgYSB3ZWlyZCBsaW5lIGJyYWtlIGhlcmUuICB0cnkgcHV0dGluZyB0aGUgcXVvdGVkDQog ICAgc3RyaW5nIG9uDQogICAgPiAgICAgPj4gdGhlIG5leHQgbGluZS4NCiAgICA+ICAgICA+Pj4g MTkuIGZpeGVkDQogICAgPiAgICAgPj4+IDIwLiBmaXhlZA0KICAgID4gICAgID4+PiAyMS4gbm90 IGZpeGVkIChyZTogeWFuZy1zZWN1cml0eS1ndWlkZWxpbmVzKQ0KICAgID4gICAgID4+PiAyMi4g ZmluZQ0KICAgID4gICAgID4+Pg0KICAgID4gICAgID4+Pg0KICAgID4gICAgID4+PiBQUzogcGxl YXNlIGFsc28gYmUgc3VyZSB0byBmb2xsb3ctdXAgd2l0aCBCZW5vaXQgb24gaGlzIEFEDQogICAg cmV2aWV3Lg0KICAgID4gICAgID4+Pg0KICAgID4gICAgID4+PiBUaGFua3MsDQogICAgPiAgICAg Pj4+IEtlbnQgIC8vIHNoZXBoZXJkICYgeWFuZyBkb2N0b3INCiAgICA+ICAgICA+Pj4NCiAgICA+ ICAgICA+Pj4NCiAgICA+ICAgICA+Pj4NCiAgICA+ICAgICA+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgICA+Pj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KICAgID4gICAgID4+PiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+ICAgICA+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+ICAgICA+Pj4N CiAgICA+ICAgICA+Pg0KICAgID4gICAgID4+DQogICAgPiAgICAgPj4NCiAgICA+ICAgICA+DQog ICAgPiAgICAgPg0KICAgID4gICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICA+ICAgICA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICA+ICAg ICA+IG5ldG1vZEBpZXRmLm9yZw0KICAgID4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQogICAgDQog ICAgDQoNCg== From nobody Thu Dec 14 10:50:29 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11BE12946F for ; Thu, 14 Dec 2017 10:50:21 -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, 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 rd6Zh8jbALiu for ; Thu, 14 Dec 2017 10:50:15 -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 B58D412946A for ; Thu, 14 Dec 2017 10:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22274; q=dns/txt; s=iport; t=1513277415; x=1514487015; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Su4NhFfeNbXJJhVdErogcSvejWXbJIC+jaSsFLvLWPw=; b=TQOPbc8LBJ5bK7tedjzqRVPGxae8hu99ywZdH91+K3kcu0fI38NQsqAf TZFRXpV+FCNaGSq79jop5tP+ahIHrqO6hG41yvYBq8F2UojiXcrsJ2u8F QSSBqGRavFZhedpMYjOYvLtohywatXBST5OfnD9h3kc3MGz8UZNbL2lPm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQDMxjJa/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0JweDe4ohjwaKeYhMhU6CFQoYAQqESU8CGoRdPxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUkAgEDAQEhBEcLEAIBCA4xAwICAh8GCxQRAgQOBYlGTAMVEKkxg?= =?us-ascii?q?W06hzYNgxsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNlgg6DPymDAoJqRAGBbYM?= =?us-ascii?q?WMYIyBZIVhz6JFT0Ch3uIL4R+k2yNFT6FV4MWAhEZAYE6AR85gU5vFToqAYF+P?= =?us-ascii?q?4Fbgjx4iUGBFQEBAQ?= X-IronPort-AV: E=Sophos; i="5.45,401,1508803200"; d="scan'208,217"; a="44698446" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 18:50:14 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBEIoEwr023110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 18:50:14 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; Thu, 14 Dec 2017 13:50:13 -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, 14 Dec 2017 13:50:13 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Sonal Agarwal CC: Mahesh Jethanandani , "netmod@ietf.org" , Kristian Larsson Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAAzEsAgACvpIA= Date: Thu, 14 Dec 2017 18:50:13 +0000 Message-ID: <2826EF6B-A6A6-4FDA-9F30-21830D748C51@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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.210.168] Content-Type: multipart/alternative; boundary="_000_2826EF6BA6A64FDA9F3021830D748C51ciscocom_" 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, 14 Dec 2017 18:50:23 -0000 --_000_2826EF6BA6A64FDA9F3021830D748C51ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIDE0IERlYyAyMDE3LCBhdCAwODoyMSwgU29uYWwgQWdhcndhbCA8c2FnYXJ3YWwxMkBn bWFpbC5jb208bWFpbHRvOnNhZ2Fyd2FsMTJAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIEVpbmFy LA0KDQpZb3UgaGFkIDMgcXVlc3Rpb25zIGZvciBtZSBvbiBhbGwgdGhlIHNldmVyYWwgZS1tYWls IHRocmVhZHMuDQoxLiBHbG9iYWwgYXR0YWNobWVudCBwb2ludA0KMi4gaWNtcC1vZmYNCjMuIGFj bC1hZ2dyZWdhdGUtaW50ZXJmYWNlIHN0YXRzLg0KDQpGb3IgKDEpLCBteSBmaXJzdCBwcmVmZXJl bmNlIGlzIHRvIGhhdmUgdGhlIG1vZGVsIGRlZmluZSBhdHRhY2htZW50IHBvaW50IGZvciBpbnRl cmZhY2VzIG9ubHkuDQoNCmVpbmFybm4+IEkgaGF2ZSBzb21lIGRpZmZzLCBsYXllcmVkIG9uIHRv cCBvZiBNYWhlc2jigJlzIFBSIHRvIG5ldG1vZC13Zy9hY2wtbW9kZWwgdGhhdCBkbyB0aGlzLiBO ZWFybHkgbGlrZSB0aGUgYXVnbWVudGF0aW9uIEkgaGF2ZSBiZWxvdy4gRmVlbCBmcmVlIHRvIHRh a2UgYSBsb29rIGF0Og0KDQpodHRwczovL2dpdGh1Yi5jb20vbWpldGhhbmFuZGFuaS9hY2wtbW9k ZWwvcHVsbC8zDQoNCkhvd2V2ZXIsIEtyaXN0aWFuIHdhbnRzIHRoZSBnbG9iYWwgYXR0YWNobWVu dCBwb2ludCBhcyB3ZWxsIHNvIHRoYXQgaGUgY2FuIGFkZCB0aGUgQUNMIHRvIHRoZSBsaW51eCB0 YWJsZXMuDQoNCmVpbmFybm4+IEkgdGhpbmsgS3Jpc3RpYW4gZG9lc27igJl0IGZlZWwgYSBnbG9i YWwgYXR0YWNobWVudCBwb2ludCBuZWVkcyB0byBiZSBpbiB0aGlzIGZpcnN0IHJldmlzaW9uLiBC dXQgaGUgY2FuIGNvbmZpcm0uDQoNCklmIGFuIEFDTCBpcyBhdHRhY2hlZCBnbG9iYWxseSwgZG9l cyB0aGlzIG1lYW4gaXQgaXMgcGVyIGRpcmVjdGlvbiBvciBkb2VzIGl0IG1lYW4gaXQgaXMgYWNy b3NzIGRpcmVjdGlvbnM/DQoNCmVpbmFybm4+IEkgZG9u4oCZdCBrbm93IHJpZ2h0IG5vdyA6LSkN Cg0KVGhpcyBnbG9iYWwgQUNMIG1heSBub3QgYmUgYXBwbGljYWJsZSB0byBhbnkgb2YgQ2lzY28n cyBzZXJ2aWNlIHByb3ZpZGVyIHJvdXRlcnMgYXMgSSBkb24ndCBzZWUgYW55IHBsYXRmb3JtIGFj dHVhbGx5IHJlcGxpY2F0aW5nIHRoZSBBQ0wgdG8gYWxsIGxpbmUgY2FyZHMgYW5kIGF0dGFjaGlu ZyBpdCBpbiBpbmdyZXNzIGFuZCBlZ3Jlc3MgZGlyZWN0aW9ucyBhY3Jvc3MgYWxsIGludGVyZmFj ZXMuDQoNCmVpbmFybm4+IFBlciBvdGhlciBlbWFpbHMsIEkgZG9u4oCZdCB0aGluayB3ZSB1bmRl cnN0YW5kIHRoaXMgZW5vdWdoIHlldCB0byBzcGVjaWZ5IGl0LCBzbyBJIHN1Z2dlc3Qgd2UganVz dCBsZWF2ZSBpdCBvdXQgZm9yIG5vdy4gTm90aGluZyBpbiB0aGUgbW9kZWwgcHJldmVudHMgYSDi gJxnbG9iYWwgYXR0YWNobWVudCBwb2ludOKAnSBiZWluZyBhZGRlZCBsYXRlciBvbmNlIHdlIHVu ZGVyc3RhbmQgd2hhdCBpdCByZWFsbHkgbWVhbnMuDQoNCkZvciAoMiksIEkgYW0gb2sgd2l0aCBy ZW1vdmluZyBpY21wLW9mZi4NCg0KZWluYXJubj4gRG9uZSBpbiBteSBQUiBhYm92ZS4NCg0KRm9y ICgzKSwgdGhpcyB3b3VsZCBoYXZlIHRvIGJlIGEgY29tYmluYXRpb24gb2YgQUNMIHN0YXRzIGFj cm9zcyBhbGwgaW50ZXJmYWNlcyBmb3IgYWxsIEFDTCdzLiBTb21ldGhpbmcgbGlrZSB0aGlzIGlz IHBvc3NpYmxlIG9uIGFuIFhSIGJveCB3aGVyZSBBQ0VTIGhhdmUgY291bnRlciBuYW1lcyBhc3Nv Y2lhdGVkIHdpdGggaXQuIExldCdzIGNoYXQgYWJvdXQgdGhpcyBvZmZsaW5lIHRvbW9ycm93Lg0K DQplaW5hcm5uPiBJ4oCZbGwgcGluZyB5b3UgdG8gY2xhcmlmeSwgYW5kIHdlIGNhbiBicmluZyBh bnkgY29uY2x1c2lvbiBiYWNrIHRvIHRoZSBsaXN0Lg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0K DQpTb25hbC4NCg0KDQpPbiBXZWQsIERlYyAxMywgMjAxNyBhdCAxMjoxMCBQTSwgTWFoZXNoIEpl dGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPj4gd3JvdGU6DQpXZSB3YW50IHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGF0dGFj aG1lbnQgcG9pbnQgZG93biB0aGUgbGluZSwgYW5kIHRoYXQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1l bnQgcG9pbnQgd2lsbCBiZSBvbmUgb2YgdGhlIGNob2ljZXMgKHRoZSBvdGhlciBiZWluZyB0aGUg aW50ZXJmYWNlKSwgd2hhdCB3b3VsZCB0aGlzIGF1Z21lbnQgbG9vayBsaWtlLiBOb3RlLCBhcyBm YXIgYXMgSSBrbm93LCB5b3UgY2Fubm90IGF1Z21lbnQgaW5zaWRlIGEgY2hvaWNlIG5vZGUuDQoN Ck9uIERlYyAxMywgMjAxNywgYXQgNjo1NyBBTSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFy bm4pIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+PiB3cm90ZToN Cg0KUGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgaW50ZXJmYWNl Og0KDQogIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOg0KICAgICstLXJ3IGlu Z3Jlc3MtYWNscw0KICAgIHwgICstLXJ3IGFjbC1zZXRzDQogICAgfCAgICAgKy0tcncgYWNsLXNl dCogW25hbWVdDQogICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vz cy1saXN0cy9hY2wvbmFtZQ0KICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+ IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICB8ICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGlj cyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgIHwgICAgICAgICAgICstLXJvIG5hbWUg ICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAgfCAg ICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgfCAg ICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQogICAgKy0t cncgZWdyZXNzLWFjbHMNCiAgICAgICArLS1ydyBhY2wtc2V0cw0KICAgICAgICAgICstLXJ3IGFj bC1zZXQqIFtuYW1lXQ0KICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgIC0+IC9h Y2Nlc3MtbGlzdHMvYWNsL25hbWUNCiAgICAgICAgICAgICArLS1ydyB0eXBlPyAgICAgICAgICAg ICAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlDQogICAgICAgICAgICAgKy0tcm8gYWNlLXN0YXRp c3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8NCiAgICAgICAgICAgICAgICArLS1ybyBu YW1lICAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQ0KICAg ICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gICB5YW5nOmNvdW50ZXI2NA0KICAg ICAgICAgICAgICAgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyAgICB5YW5nOmNvdW50ZXI2NA0KDQpD b3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBhYm92ZSBib3RoIHRoZXNlICYg cmVuYW1lIOKAnGluZ3Jlc3MtYWNscyIgdG8g4oCcaW5ncmVzc+KAnSwgZXRjLiB0byBnaXZlIGEg c2luZ2xlIHJvb3QgZm9yIHRoZSBhdWdtZW50YXRpb24gaWYgcHJlZmVycmVkLg0KDQpDaGVlcnMs DQoNCkVpbmFyDQoNCg0KT24gNiBEZWMgMjAxNywgYXQgMTk6NDMsIEVsaW90IExlYXIgPGxlYXJA Y2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gMTIvNi8x NyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0KSG93IGRvZXMgb25lIG1vdmUg dGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBvaW50LCBjdXJyZW50bHkgYW4NCidpbnRlcmZhY2Ut cmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZSBpZjppbnRlcmZhY2VzL2ludGVyZmFjZSwN Cmluc2lkZSBvZiB0aGUg4oCYYWNs4oCZICBjb250YWluZXI/IERvd24gdGhlIGxpbmUgd2UgbWln aHQgbmVlZCB0byBoYXZlIGFuDQpjb250YWluZXIgZm9yICJhdHRhY2htZW50IHBvaW50cyIgdG8g YWNjb21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5IG9mDQphdHRhY2hpbmcgYW4gQUNMIGVpdGhlciB0 byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uDQoNCg0KS2VlcGluZyBpbiBtaW5kIHRo YXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFjaCB0byBhbg0KaW50ZXJmYWNl IGF0IGFsbC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K DQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxt YWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg0KDQoNCg== --_000_2826EF6BA6A64FDA9F3021830D748C51ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IDE0IERlYyAyMDE3LCBhdCAwODoyMSwgU29uYWwgQWdhcndhbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNhZ2Fyd2FsMTJAZ21haWwuY29tIiBjbGFzcz0iIj5zYWdhcndhbDEyQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBFaW5hciwNCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPllvdSBoYWQgMyBx dWVzdGlvbnMgZm9yIG1lIG9uIGFsbCB0aGUgc2V2ZXJhbCBlLW1haWwgdGhyZWFkcy4mbmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gR2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQ8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Mi4gaWNtcC1vZmY8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+My4gYWNsLWFnZ3Jl Z2F0ZS1pbnRlcmZhY2Ugc3RhdHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Gb3IgKDEpLCBteSBmaXJzdCBwcmVmZXJlbmNlIGlzIHRv IGhhdmUgdGhlIG1vZGVsIGRlZmluZSBhdHRhY2htZW50IHBvaW50IGZvciBpbnRlcmZhY2VzIG9u bHkuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+ZWluYXJubiZndDsgSSBoYXZlIHNvbWUgZGlmZnMsIGxheWVyZWQg b24gdG9wIG9mIE1haGVzaOKAmXMgUFIgdG8gbmV0bW9kLXdnL2FjbC1tb2RlbCB0aGF0IGRvIHRo aXMuIE5lYXJseSBsaWtlIHRoZSBhdWdtZW50YXRpb24gSSBoYXZlIGJlbG93LiBGZWVsIGZyZWUg dG8gdGFrZSBhIGxvb2sgYXQ6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7 IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2PjxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9tamV0aGFuYW5kYW5pL2FjbC1tb2RlbC9wdWxsLzMiIGNsYXNzPSIi Pmh0dHBzOi8vZ2l0aHViLmNvbS9tamV0aGFuYW5kYW5pL2FjbC1tb2RlbC9wdWxsLzM8L2E+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+SG93ZXZlciwgS3Jpc3RpYW4gd2FudHMgdGhlIGdsb2JhbCBhdHRhY2ht ZW50IHBvaW50IGFzIHdlbGwgc28gdGhhdCBoZSBjYW4gYWRkIHRoZSBBQ0wgdG8gdGhlIGxpbnV4 IHRhYmxlcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5laW5hcm5uJmd0OyBJIHRoaW5rIEtyaXN0aWFuIGRvZXNu 4oCZdCBmZWVsIGEgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQgbmVlZHMgdG8gYmUgaW4gdGhpcyBm aXJzdCByZXZpc2lvbi4gQnV0IGhlIGNhbiBjb25maXJtLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPklmIGFuIEFDTCBpcyBhdHRhY2hlZCBn bG9iYWxseSwgZG9lcyB0aGlzIG1lYW4gaXQgaXMgcGVyIGRpcmVjdGlvbiBvciBkb2VzIGl0IG1l YW4gaXQgaXMgYWNyb3NzIGRpcmVjdGlvbnM/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ZWluYXJubiZndDsgSSBk b27igJl0IGtub3cgcmlnaHQgbm93IDotKTwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRoaXMgZ2xvYmFsIEFDTCBtYXkgbm90IGJlIGFwcGxp Y2FibGUgdG8gYW55IG9mIENpc2NvJ3Mgc2VydmljZSBwcm92aWRlciByb3V0ZXJzIGFzIEkgZG9u J3Qgc2VlIGFueSBwbGF0Zm9ybSBhY3R1YWxseSByZXBsaWNhdGluZyB0aGUgQUNMIHRvIGFsbCBs aW5lIGNhcmRzIGFuZCBhdHRhY2hpbmcgaXQgaW4gaW5ncmVzcyBhbmQgZWdyZXNzIGRpcmVjdGlv bnMgYWNyb3NzIGFsbCBpbnRlcmZhY2VzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmVpbmFybm4mZ3Q7IFBlciBv dGhlciBlbWFpbHMsIEkgZG9u4oCZdCB0aGluayB3ZSB1bmRlcnN0YW5kIHRoaXMgZW5vdWdoIHll dCB0byBzcGVjaWZ5IGl0LCBzbyBJIHN1Z2dlc3Qgd2UganVzdCBsZWF2ZSBpdCBvdXQgZm9yIG5v dy4gTm90aGluZyBpbiB0aGUgbW9kZWwgcHJldmVudHMgYSDigJxnbG9iYWwgYXR0YWNobWVudCBw b2ludOKAnSBiZWluZyBhZGRlZCBsYXRlciBvbmNlIHdlIHVuZGVyc3RhbmQgd2hhdCBpdCByZWFs bHkgbWVhbnMuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+Rm9yICgyKSwgSSBhbSBvayB3aXRoIHJlbW92aW5nIGljbXAtb2ZmLjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PmVpbmFybm4mZ3Q7IERvbmUgaW4gbXkgUFIgYWJvdmUuPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Rm9yICgzKSwgdGhpcyB3b3Vs ZCBoYXZlIHRvIGJlIGEgY29tYmluYXRpb24gb2YgQUNMIHN0YXRzIGFjcm9zcyBhbGwgaW50ZXJm YWNlcyBmb3IgYWxsIEFDTCdzLiBTb21ldGhpbmcgbGlrZSB0aGlzIGlzIHBvc3NpYmxlIG9uIGFu IFhSIGJveCB3aGVyZSBBQ0VTIGhhdmUgY291bnRlciBuYW1lcyBhc3NvY2lhdGVkIHdpdGggaXQu IExldCdzIGNoYXQgYWJvdXQgdGhpcyBvZmZsaW5lIHRvbW9ycm93LjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmVp bmFybm4mZ3Q7IEnigJlsbCBwaW5nIHlvdSB0byBjbGFyaWZ5LCBhbmQgd2UgY2FuIGJyaW5nIGFu eSBjb25jbHVzaW9uIGJhY2sgdG8gdGhlIGxpc3QuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+RWluYXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+U29uYWwuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdl ZCwgRGVjIDEzLCAyMDE3IGF0IDEyOjEwIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxzcGFuIGRp cj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwv YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk IiBjbGFzcz0iIj5XZSB3YW50IHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9p bnQgZG93biB0aGUgbGluZSwgYW5kIHRoYXQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQg d2lsbCBiZSBvbmUgb2YgdGhlIGNob2ljZXMgKHRoZSBvdGhlciBiZWluZyB0aGUgaW50ZXJmYWNl KSwgd2hhdCB3b3VsZCB0aGlzIGF1Z21lbnQgbG9vayBsaWtlLiBOb3RlLCBhcyBmYXIgYXMgSSBr bm93LA0KIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUgYSBjaG9pY2Ugbm9kZS4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iaDUiPjxiciBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAo ZWluYXJubikgJmx0OzxhIGhyZWY9Im1haWx0bzplaW5hcm5uQGNpc2NvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPmVpbmFybm5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 YnIgY2xhc3M9Im1fNzEwMjQwODkwNzUzMzAxNzUwMUFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2xpbmUt YnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiIGNsYXNzPSIiPlBlcmhhcHMgbGlrZSB0aGlzLCBhcyBh biBhdWdtZW50YXRpb24gdG8gdGhlIGludGVyZmFjZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVy Om5vbmU7cGFkZGluZzowcHgiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVy ZmFjZXMvaWY6aW50ZXJmYWNlOjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmIzQzOy0tcncgaW5ncmVzcy1hY2xzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW25hbWVd PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7LSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvbmFtZTwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1z dGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvPHdiciBjbGFzcz0iIj5uYW1l PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFu Zzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8g Jm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBlZ3Jlc3MtYWNsczwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3Vy aWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlz dHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBl PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJm YWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3Mt bGlzdHMvYWNsL2FjZXMvYWNlLzx3YnIgY2xhc3M9IiI+bmFtZTwvZm9udD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xh c3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2Zv bnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZh Y2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5i c3A7eWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNvdWxkIGFs c28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFpbmVyIGFib3ZlIGJvdGggdGhlc2UgJmFtcDsgcmVu YW1lIOKAnGluZ3Jlc3MtYWNscyZxdW90OyB0byDigJxpbmdyZXNz4oCdLCBldGMuIHRvIGdpdmUg YSBzaW5nbGUgcm9vdCBmb3IgdGhlIGF1Z21lbnRhdGlvbiBpZiBwcmVmZXJyZWQuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+RWluYXI8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA2IERlYyAyMDE3LCBhdCAxOTo0Mywg RWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0ibV83MTAyNDA4OTA3NTMzMDE3NTAxQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpPbiAxMi82LzE3IDc6MjMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SG93IGRvZXMgb25lIG1vdmUg dGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBvaW50LCBjdXJyZW50bHkgYW48YnIgY2xhc3M9IiI+ DQonaW50ZXJmYWNlLXJlZicsIHRvIGFuIGF1Z21lbnRhdGlvbiBvZiB0aGUgaWY6aW50ZXJmYWNl cy9pbnRlcmZhY2UsPGJyIGNsYXNzPSIiPg0KaW5zaWRlIG9mIHRoZSDigJhhY2zigJkgJm5ic3A7 Y29udGFpbmVyPyBEb3duIHRoZSBsaW5lIHdlIG1pZ2h0IG5lZWQgdG8gaGF2ZSBhbjxiciBjbGFz cz0iIj4NCmNvbnRhaW5lciBmb3IgJnF1b3Q7YXR0YWNobWVudCBwb2ludHMmcXVvdDsgdG8gYWNj b21tb2RhdGUgdGhlIHBvc3NpYmlsaXR5IG9mPGJyIGNsYXNzPSIiPg0KYXR0YWNoaW5nIGFuIEFD TCBlaXRoZXIgdG8gYW4gaW50ZXJmYWNlIG9yIOKAnGdsb2JhbGx54oCdLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCktlZXBpbmcgaW4g bWluZCB0aGF0IG9uZSB1c2UgaXMgdGhhdCBhbiBBQ0wgZG9lc24ndCBhdHRhY2ggdG8gYW48YnIg Y2xhc3M9IiI+DQppbnRlcmZhY2UgYXQgYWxsLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnIgY2xhc3M9IiI+X19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm5l dG1vZEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9uZXRtb2Q8 L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+ PGZvbnQgY29sb3I9IiM4ODg4ODgiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+TWFoZXNoIEpldGhhbmFuZGFuaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5t amV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9mb250Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fXzxiciBjbGFz cz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86 bmV0bW9kQGlldGYub3JnIiBjbGFzcz0iIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIi Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Qi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_2826EF6BA6A64FDA9F3021830D748C51ciscocom_-- From nobody Fri Dec 15 05:59:36 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541E6128B8F for ; Fri, 15 Dec 2017 05:59:34 -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 X1LX-tLGRrEl for ; Fri, 15 Dec 2017 05:59:20 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6792B126C25 for ; Fri, 15 Dec 2017 05:59:20 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 07B1E18215DE; Fri, 15 Dec 2017 14:58:33 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 251911820E6E for ; Fri, 15 Dec 2017 14:58:31 +0100 (CET) From: Ladislav Lhotka To: NETMOD WG In-Reply-To: <1512747137.3467.71.camel@nic.cz> References: <1512747137.3467.71.camel@nic.cz> Mail-Followup-To: NETMOD WG Date: Fri, 15 Dec 2017 14:59:16 +0100 Message-ID: <87zi6kay8b.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: Fri, 15 Dec 2017 13:59:34 -0000 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. 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? 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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Dec 15 06:03:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E151128ACA for ; Fri, 15 Dec 2017 06:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 JSj6LMNEhyas for ; Fri, 15 Dec 2017 06:03:53 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 D54A9126C25 for ; Fri, 15 Dec 2017 06:03:52 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vBFDv8UY006761 for ; Fri, 15 Dec 2017 09:03:50 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2evekjaprf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 15 Dec 2017 09:03:50 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBFE3nOP029507 for ; Fri, 15 Dec 2017 09:03:49 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBFE3fbB029361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Dec 2017 09:03:45 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Fri, 15 Dec 2017 14:03:28 GMT Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id C4852167F71 for ; Fri, 15 Dec 2017 14:03:28 +0000 (GMT) Received: from gbcdccas02.intl.att.com (unknown [135.76.180.10]) by zlp27125.vci.att.com (Service) with ESMTPS id 5C7C816A5A8 for ; Fri, 15 Dec 2017 14:03:28 +0000 (GMT) Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas02.intl.att.com ([135.76.180.10]) with mapi id 14.03.0361.001; Fri, 15 Dec 2017 14:03:27 +0000 From: "Ivory, William" To: "'netmod@ietf.org'" Thread-Topic: Query about augmenting 'config false' YANG Thread-Index: AdN1mjLksq4lef+RRXCK3AeBlJ13PA== Date: Fri, 15 Dec 2017 14:02:26 +0000 Deferred-Delivery: Fri, 15 Dec 2017 14:03:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.160.174.64] Content-Type: multipart/alternative; boundary="_000_E3378E0605547F4E854DEE0CB1116AB02B6F08gbcdcmbx03intlatt_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-15_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=636 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712150197 Archived-At: Subject: [netmod] Query about augmenting 'config false' YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2017 14:03:54 -0000 --_000_E3378E0605547F4E854DEE0CB1116AB02B6F08gbcdcmbx03intlatt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm running into a problem where my YANG is being rejected by a NETCONF cli= ent that claims it can't find the node being augmented. The YANG snippet b= elow shows the problem which relates specifically to augmenting a node that= is 'config false'. AFAICT from reading RFC 6020, this is valid YANG, but = I would appreciate confirmation from the experts! Pyang is quite happy with this. Thanks, William --- sample yang to show problem --- grouping state-grouping { container state { config false; leaf state-grp-state-leaf { type string= ; } } } container test { container state-cont { config false; leaf state-leaf { type string= ; } } } augment /test/state-cont { // Augment 'config false' container directl= y works. leaf augmented-state-leaf { type string; } } augment /test { uses state-grouping { // Augment here fails - 'st= ate' not found. augment state { leaf aug-st= ate-grp-leaf { = type string; } } } } --_000_E3378E0605547F4E854DEE0CB1116AB02B6F08gbcdcmbx03intlatt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m running into a proble= m where my YANG is being rejected by a NETCONF client that claims it can= 217;t find the node being augmented.  The YANG snippet below shows the= problem which relates specifically to augmenting a node that is ‘config false’.  AFAICT from reading RFC 6020, th= is is valid YANG, but I would appreciate confirmation from the experts!

 

Pyang is quite happy with this.=

 

Thanks,

 

William

 

--- sample yang to show problem= ---

 

     &= nbsp;          grouping state-= grouping {

     &= nbsp;           &nbs= p;            &= nbsp; container state {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     config false;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     leaf state-grp-state-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        type string;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

     &= nbsp;          container test = {

     &= nbsp;           &nbs= p;            &= nbsp; container state-cont {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     config false;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     leaf state-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        type string;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

     &= nbsp;          augment /test/s= tate-cont {

     &= nbsp;           &nbs= p;            &= nbsp; // Augment 'config false' container directly works.=

     &= nbsp;           &nbs= p;            &= nbsp; leaf augmented-state-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type string;

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

     &= nbsp;          augment /test {=

     &= nbsp;           &nbs= p;            &= nbsp; uses state-grouping {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     // Augment here fails - 'state' not found.<= /o:p>

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     augment state {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        leaf aug-state-grp-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            type s= tring;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        }

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

 

--_000_E3378E0605547F4E854DEE0CB1116AB02B6F08gbcdcmbx03intlatt_-- From nobody Fri Dec 15 09:01:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01698127241 for ; Fri, 15 Dec 2017 09:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 Y4VX3d2uQ3kh for ; Fri, 15 Dec 2017 09:01:21 -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 087C71200CF for ; Fri, 15 Dec 2017 09:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1941; q=dns/txt; s=iport; t=1513357281; x=1514566881; h=subject:references:to:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=K0W3Ia/cdyd1otKzT/nEIHVI6+sm7MUhmjHfEMuhTYs=; b=b/c+p8YKteMTeEsgMHbd/T4//z3nc+paTT3jEZASy9JZZqofcnry7Pcd xcBysSI3Dh+pbP0L/5ArS9zqn7F2twizRfA7/uiMZNO8AqSTQbDOSKmjG 3XD8PfYnGkhK9N6Z+H9yOEUHcjbV+TJSRbT2sxPjj0yxVGzRpDctgPRKN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AQAR/zNa/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnhAKKIY8IgVomlyCCFQolhRYChQA/GAEBAQEBAQEBAWs?= =?us-ascii?q?dC4UjAQYjVBIcAwECAwImAgJNAggGDQYCAQGKJhCpHIInilUBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBH4EPglqCDoFWghIMgneDLgEBF4RrgmMFkhqBFJAIh36NLYIWY4U?= =?us-ascii?q?wg2yHXIpKgk6JXYE7HzmBT0wjFRiCTQmEayM3AYpFAQEB?= X-IronPort-AV: E=Sophos;i="5.45,405,1508803200"; d="scan'208";a="44616588" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 17:01:20 +0000 Received: from [10.118.87.84] (rtp-jclarke-nitro3.cisco.com [10.118.87.84]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vBFH1J41018564 for ; Fri, 15 Dec 2017 17:01:20 GMT References: <151335705548.30342.6522755515168567555.idtracker@ietfa.amsl.com> To: "netmod@ietf.org" From: Joe Clarke Organization: Cisco X-Forwarded-Message-Id: <151335705548.30342.6522755515168567555.idtracker@ietfa.amsl.com> Message-ID: <38b3831e-c2d7-e7e5-0331-80c9ce2b6398@cisco.com> Date: Fri, 15 Dec 2017 12:01:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151335705548.30342.6522755515168567555.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-clacla-netmod-yang-model-update-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: Fri, 15 Dec 2017 17:01:23 -0000 This new version of the draft incorporates a large amount of text from Balazs (new co-author) specifically around the points of deprecation and obsolescence. It makes a proposal on how to deal with those items, as well as enumerates additional open discussion items. The YANG module has also been revised to provide augmentations to ietf-yang-library in addition to the definition of the extension. Joe (on behalf of co-authors) -------- Forwarded Message -------- Subject: New Version Notification for draft-clacla-netmod-yang-model-update-03.txt Date: Fri, 15 Dec 2017 08:57:35 -0800 From: internet-drafts@ietf.org To: Benoit Claise , Kevin D'Souza , Balazs Lengyel , Joe Clarke A new version of I-D, draft-clacla-netmod-yang-model-update-03.txt has been successfully submitted by Joe Clarke and posted to the IETF repository. Name: draft-clacla-netmod-yang-model-update Revision: 03 Title: New YANG Module Update Procedure Document date: 2017-12-15 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-clacla-netmod-yang-model-update-03.txt Status: https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/ Htmlized: https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-clacla-netmod-yang-model-update-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-clacla-netmod-yang-model-update-03 Abstract: This document specifies a new YANG module update procedure in case of backward-incompatible changes, as an alternative proposal to the YANG 1.1 specifications. This document updates RFC 7950. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Dec 15 09:21:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B344D12940F for ; Fri, 15 Dec 2017 09:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 Pn5fHfJ4hqt3 for ; Fri, 15 Dec 2017 09:21:29 -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 233191293EE for ; Fri, 15 Dec 2017 09:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=860; q=dns/txt; s=iport; t=1513358489; x=1514568089; h=to:from:subject:cc:message-id:date:mime-version: content-transfer-encoding; bh=CiiQ/qKN3SHOS7SO1KIfsnNw/VMBp69w6omveGgufLU=; b=TuVQ4mTY8rSbqfjcpmmhTvbM2H3e3UQ5Z9my4X4LHUeEa60OYZNHsbfl JMUuLcv4XKldYZu6H5JnioxppVPw8xqxCxm/cPgNWsOozExb/0tPoks/u zLxbgLRrV+M9I2PNEm/cDqFa5cV3u7nZEVxLKQEwYnXnrNXzFIGh502qG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAwDFAzRa/xbLJq1dGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYUYhCmLFY9ul1qCAQqFO4VEFQEBAQEBAQEBAWsohU0PAQVBLQgCJgJ?= =?us-ascii?q?LFA0IAQGKJqkjgieKbQEBAQEBBQEBAQEkgQ+CWoNkgWkpDIdcg02CYwWZXIlal?= =?us-ascii?q?SuCFoYTg2yHXI5xiASBOzUjgU8yGggbFYJmhFZAin0BAQE?= X-IronPort-AV: E=Sophos;i="5.45,405,1508803200"; d="scan'208";a="896620" 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; 15 Dec 2017 17:21:27 +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 vBFHLQtr001881; Fri, 15 Dec 2017 17:21:26 GMT To: NETMOD Working Group From: Benoit Claise Cc: Joel jaeggli Message-ID: Date: Fri, 15 Dec 2017 18:21:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2017 17:21:31 -0000 Dear all, A lot is happening these days in the world of data modeling-driven management at the IETF:     NMDA architecture, NETCONF, RESTCONF     NMDA-compliant YANG modules: some RFC bis modules but also new ones     Guidelines: RFC6087bis and the tree diagram     The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, telemetry     The interaction with routing, where many YANG modules come from.     etc. There are a lot of dependencies between all these tasks, which must take place in parallel, and, obviously, be completed ASAP. Kent and Lou have a lot on their shoulders these days. To help with the situation and proactively progress documents, I'm happy to announce that Joel Jaeggli accepted to serve as a third NETMOD co-chair. Thank you Joel. Please welcome Joel. Regards, Benoit From nobody Fri Dec 15 09:42:04 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF40126CC7 for ; Fri, 15 Dec 2017 09:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 5RrIs6eFOVGd for ; Fri, 15 Dec 2017 09:42:00 -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 2AAC912422F for ; Fri, 15 Dec 2017 09:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10243; q=dns/txt; s=iport; t=1513359720; x=1514569320; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=USJSwN9JBxDYIRzfQQI3LrCXkWhVe4IdRHjrXC4fs5I=; b=WYTCtFkKrAnnzE3VOVXtgr4eqeaeQ9/+M+KGbN5dMVrDJ5N8e9csM3zF ntFo70F1kkbodKZ4yIYEAYorBcNsk4GNrg+1mT8HKMFxME9xAYkpugd5n /N2xc0lIgRaxxhQ3yPvFqdnOzFbKA7B88PsZEo/TJ4NZcUm9XgRQPtdeG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQBCCDRa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKgVp0J48XkBSRUYdkChgBCoRJTwKFQhUBAQEBAQEBAQFrKIU?= =?us-ascii?q?kAQEEAQErPgMbCxguJzAGAQwGAgEBiiYQqzomikYBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYNpg2SCEoMDgy4Bh2YFimaJJoVQiVqVK4wVh1yOcYgEgTs1IyWBKjI?= =?us-ascii?q?aCBsVPIIphFZBN4pOAQEB?= X-IronPort-AV: E=Sophos;i="5.45,406,1508803200"; d="scan'208,217";a="943992" 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; 15 Dec 2017 17:41:58 +0000 Received: from [10.61.241.101] ([10.61.241.101]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBFHfv7O025568; Fri, 15 Dec 2017 17:41:58 GMT To: "Ivory, William" , "'netmod@ietf.org'" References: From: Robert Wilton Message-ID: <8480c009-538d-5b3e-61f6-c3776ee4ac5c@cisco.com> Date: Fri, 15 Dec 2017 17:41: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: multipart/alternative; boundary="------------24D61B1C609A08FC0A5F8DC5" Content-Language: en-US Archived-At: Subject: Re: [netmod] Query about augmenting 'config false' YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2017 17:42:03 -0000 This is a multi-part message in MIME format. --------------24D61B1C609A08FC0A5F8DC5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Looks valid to me. Thanks, Rob On 15/12/2017 14:02, Ivory, William wrote: > > Hi, > > Im running into a problem where my YANG is being rejected by a > NETCONF client that claims it cant find the node being augmented. > The YANG snippet below shows the problem which relates specifically to > augmenting a node that is config false. AFAICT from reading RFC > 6020, this is valid YANG, but I would appreciate confirmation from the > experts! > > Pyang is quite happy with this. > > Thanks, > > William > > --- sample yang to show problem --- > > grouping state-grouping { > > container state { > > config false; > > leaf state-grp-state-leaf { > > type string; > > } > > } > > } > > container test { > > container state-cont { > > config false; > > leaf state-leaf { > > type string; > > } > > } > > } > > augment /test/state-cont { > > // Augment 'config false' container directly works. > > leaf augmented-state-leaf { > > type string; > > } > > } > > augment /test { > > uses state-grouping { > > // Augment here fails - 'state' not found. > > augment state { > > leaf aug-state-grp-leaf { > > type string; > > } > > } > > } > > } > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------24D61B1C609A08FC0A5F8DC5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Looks valid to me.

Thanks,
Rob


On 15/12/2017 14:02, Ivory, William wrote:

Hi,

Im running into a problem where my YANG is being rejected by a NETCONF client that claims it cant find the node being augmented. The YANG snippet below shows the problem which relates specifically to augmenting a node that is config false. AFAICT from reading RFC 6020, this is valid YANG, but I would appreciate confirmation from the experts!

Pyang is quite happy with this.

Thanks,

William

--- sample yang to show problem ---

grouping state-grouping {

container state {

config false;

leaf state-grp-state-leaf {

type string;

}

}

}

container test {

container state-cont {

config false;

leaf state-leaf {

type string;

}

}

}

augment /test/state-cont {

// Augment 'config false' container directly works.

leaf augmented-state-leaf {

type string;

}

}

augment /test {

uses state-grouping {

// Augment here fails - 'state' not found.

augment state {

leaf aug-state-grp-leaf {

type string;

}

}

}

}



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

--------------24D61B1C609A08FC0A5F8DC5-- From nobody Fri Dec 15 09:45:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E176129409 for ; Fri, 15 Dec 2017 09:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg5XCHK6X5VN for ; Fri, 15 Dec 2017 09:45:17 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 7056A127522 for ; Fri, 15 Dec 2017 09:45:17 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBFHfKho014083; Fri, 15 Dec 2017 12:45:15 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2evhb7ud34-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Dec 2017 12:45:14 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBFHjDvG000952; Fri, 15 Dec 2017 12:45:13 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBFHj2KR000735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Dec 2017 12:45:06 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 15 Dec 2017 17:44:39 GMT Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 989C54000391; Fri, 15 Dec 2017 17:44:39 +0000 (GMT) Received: from gbcdccas02.intl.att.com (unknown [135.76.180.10]) by zlp27126.vci.att.com (Service) with ESMTPS id 0F1A54000364; Fri, 15 Dec 2017 17:44:39 +0000 (GMT) Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas02.intl.att.com ([135.76.180.10]) with mapi id 14.03.0361.001; Fri, 15 Dec 2017 17:44:37 +0000 From: "Ivory, William" To: "'Robert Wilton'" , "'netmod@ietf.org'" Thread-Topic: [netmod] Query about augmenting 'config false' YANG Thread-Index: AdN1mjLksq4lef+RRXCK3AeBlJ13PAAMc3aAAAAHTpA= Date: Fri, 15 Dec 2017 17:43:36 +0000 Deferred-Delivery: Fri, 15 Dec 2017 17:44:36 +0000 Message-ID: References: <8480c009-538d-5b3e-61f6-c3776ee4ac5c@cisco.com> In-Reply-To: <8480c009-538d-5b3e-61f6-c3776ee4ac5c@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.160.174.64] Content-Type: multipart/alternative; boundary="_000_E3378E0605547F4E854DEE0CB1116AB02B91F1gbcdcmbx03intlatt_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-15_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1712150245 Archived-At: Subject: Re: [netmod] Query about augmenting 'config false' YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2017 17:45:19 -0000 --_000_E3378E0605547F4E854DEE0CB1116AB02B91F1gbcdcmbx03intlatt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob, Thanks - that's what I thought but wanted a second opinion. Fortunately we= can expand the groupings in-place to work around this, but obviously at th= e cost of lower maintainability and with the risk of divergence if the grou= ping content ever changes. William From: Robert Wilton [mailto:rwilton@cisco.com] Sent: 15 December 2017 17:42 To: Ivory, William ; 'netmod@ietf.org' Subject: Re: [netmod] Query about augmenting 'config false' YANG Looks valid to me. Thanks, Rob On 15/12/2017 14:02, Ivory, William wrote: Hi, I'm running into a problem where my YANG is being rejected by a NETCONF cli= ent that claims it can't find the node being augmented. The YANG snippet b= elow shows the problem which relates specifically to augmenting a node that= is 'config false'. AFAICT from reading RFC 6020, this is valid YANG, but = I would appreciate confirmation from the experts! Pyang is quite happy with this. Thanks, William --- sample yang to show problem --- grouping state-grouping { container state { config false; leaf state-grp-state-leaf { type string= ; } } } container test { container state-cont { config false; leaf state-leaf { type string= ; } } } augment /test/state-cont { // Augment 'config false' container directl= y works. leaf augmented-state-leaf { type string; } } augment /test { uses state-grouping { // Augment here fails - 'st= ate' not found. augment state { leaf aug-st= ate-grp-leaf { = type string; } } } } _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_E3378E0605547F4E854DEE0CB1116AB02B91F1gbcdcmbx03intlatt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi R= ob,

 

Than= ks – that’s what I thought but wanted a second opinion.  F= ortunately we can expand the groupings in-place to work around this, but ob= viously at the cost of lower maintainability and with the risk of divergence if the grouping content ever changes.=

 

Will= iam

 

From: Robert Wilton [mailto:rwilton@ci= sco.com]
Sent: 15 December 2017 17:42
To: Ivory, William <william.ivory@intl.att.com>; 'netmod@ietf.= org' <netmod@ietf.org>
Subject: Re: [netmod] Query about augmenting 'config false' YANG

 

Looks valid to me.=

Thanks,
Rob

 

On 15/12/2017 14:02, Ivory, William wrote:

Hi,

 

I’m running into a proble= m where my YANG is being rejected by a NETCONF client that claims it can= 217;t find the node being augmented.  The YANG snippet below shows the= problem which relates specifically to augmenting a node that is ‘config false’.  AFAICT from reading RFC 6020, th= is is valid YANG, but I would appreciate confirmation from the experts!

 

Pyang is quite happy with this.=

 

Thanks,

 

William

 

--- sample yang to show problem= ---

 

     &= nbsp;          grouping state-= grouping {

     &= nbsp;           &nbs= p;            &= nbsp; container state {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     config false;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     leaf state-grp-state-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        type string;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

     &= nbsp;          container test = {

     &= nbsp;           &nbs= p;            &= nbsp; container state-cont {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     config false;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     leaf state-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        type string;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

     &= nbsp;          augment /test/s= tate-cont {

     &= nbsp;           &nbs= p;            &= nbsp; // Augment 'config false' container directly works.=

     &= nbsp;           &nbs= p;            &= nbsp; leaf augmented-state-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type string;

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

     &= nbsp;          augment /test {=

     &= nbsp;           &nbs= p;            &= nbsp; uses state-grouping {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     // Augment here fails - 'state' not found.

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     augment state {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        leaf aug-state-grp-leaf {

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            type s= tring;

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        }

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

     &= nbsp;           &nbs= p;            &= nbsp; }

     &= nbsp;          }

 

 




_______________________________________________
netmod mailing list
netmod@ietf.org

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

&nbs= p;

--_000_E3378E0605547F4E854DEE0CB1116AB02B91F1gbcdcmbx03intlatt_-- From nobody Fri Dec 15 12:18:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A63124F57 for ; Fri, 15 Dec 2017 12:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, 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 NBQu_K9i4wek for ; Fri, 15 Dec 2017 12:18:21 -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 D1FCD124D6C for ; Fri, 15 Dec 2017 12:18:21 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 6F29E140546 for ; Fri, 15 Dec 2017 13:18:19 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id mLJF1w00U2SSUrH01LJJft; Fri, 15 Dec 2017 13:18:19 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=1Qc1JRBs84A_rUiI8ewA: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=Jl2xGmKfG0VadtOuYiHDuxEVqMMFgxb6YtXXirZ/2Jk=; b=OKSy9Y4UOJ+caoHRxRSfPAxbbO qrFFEZtqBf3zzzx+nonqGJZWutW5lNn6ZJWnC+Wk5mYQAtxYCcHBXQ9w/RornZfVoZXWOPRnvy6z6 wXLInfrZn9bA0r0z5gbsUpms9; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:44846 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePwQx-0001CA-BP; Fri, 15 Dec 2017 13:18:15 -0700 To: Benoit Claise , NETMOD Working Group Cc: Joel jaeggli References: From: Lou Berger Message-ID: <47fc9556-97c9-8451-cdc3-c5da3b44cdf7@labn.net> Date: Fri, 15 Dec 2017 15:18:14 -0500 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 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: 1ePwQx-0001CA-BP 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]:44846 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2017 20:18:24 -0000 Joel,     Welcome aboard! Lou On 12/15/2017 12:21 PM, Benoit Claise wrote: > Dear all, > > A lot is happening these days in the world of data modeling-driven > management at the IETF: >     NMDA architecture, NETCONF, RESTCONF >     NMDA-compliant YANG modules: some RFC bis modules but also new ones >     Guidelines: RFC6087bis and the tree diagram >     The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, > telemetry >     The interaction with routing, where many YANG modules come from. >     etc. > There are a lot of dependencies between all these tasks, which must take > place in parallel, and, obviously, be completed ASAP. > > Kent and Lou have a lot on their shoulders these days. > To help with the situation and proactively progress documents, I'm happy > to announce that Joel Jaeggli accepted to serve as a third NETMOD > co-chair. Thank you Joel. > > Please welcome Joel. > > Regards, Benoit > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Dec 15 12:34:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92362129420 for ; Fri, 15 Dec 2017 12:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=unavailable 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 ChPQfJ_qZdPl for ; Fri, 15 Dec 2017 12:34:54 -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 AE0DD12941C for ; Fri, 15 Dec 2017 12:34:54 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 436FC140444 for ; Fri, 15 Dec 2017 13:34:54 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id mLar1w00G2SSUrH01Laurr; Fri, 15 Dec 2017 13:34:54 -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=ocR9PWop10UA:10 a=uWfppLon2OAbg-feVKsA: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:References:Cc:To:From: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=nDR2Cb3cXS0greE1z8ggYXLCfo6h9z65sgTpo4Ji5pE=; b=AWRWLOv1et8uhSQkuIP776VYZJ fuE8RG+J2Ej3is02UUmVf80qHbQoxqKki+qu/URG7J3mM81SG6LsGn2lKS7DtMrNdN+cV0E4osmqN NgvRSjyw2EjthsPdCJsMlTN+Z; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:46332 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePwh1-000AF2-2G; Fri, 15 Dec 2017 13:34:51 -0700 From: Lou Berger To: NetMod WG Cc: NetMod WG Chairs References: Message-ID: <24b29684-3102-2ce7-1a83-e10d7a93c037@labn.net> Date: Fri, 15 Dec 2017 15:34:49 -0500 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 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: 1ePwh1-000AF2-2G 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]:46332 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-entity-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, 15 Dec 2017 20:34:56 -0000 All,     This last call is closed.  Authors, Please resolve all LC comments and publish an updated version of the draft.  Once published, please also summarize how all LC comments have been addressed. Also, When doing your update please ensure the upload fully passes idnits, and also use the new boiler plate from rfc8174:       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. Thank you Lou (and co-chairs) On 11/29/2017 12:35 PM, Lou Berger wrote: > All, > > This starts a two-week working group last call on > draft-ietf-netmod-entity-05. > > The working group last call ends on December 13. > 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. > > Thank you, > Netmod Chairs > > From nobody Fri Dec 15 12:55:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F416129423 for ; Fri, 15 Dec 2017 12:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable 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 eMGyS4feVGVV for ; Fri, 15 Dec 2017 12:55:27 -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 175A9129420 for ; Fri, 15 Dec 2017 12:55:27 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id B8F971E080A for ; Fri, 15 Dec 2017 13:55:24 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id mLvL1w00W2SSUrH01LvPtA; Fri, 15 Dec 2017 13:55:24 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=AtmwtPhdRoHx8-B5ccwA: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=YyYvspMRO9E0rvLcg03U5IV+43ZHOnUIs8aDw7q4wpY=; b=1SQfceU+py1WdLLmpdStORrZsY X0CIg813AQKXw+iITiM2hyiEM5qGP1CHPcIdYdan34yIARiQ7kogHA9fFAk9aOwpKLw0cKPcxF8cj aWflaM8Oy6ZploURAl+dX0Rf4; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47948 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePx0q-000IRp-Pr; Fri, 15 Dec 2017 13:55:20 -0700 To: NetMod WG Cc: NetMod WG Chairs References: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net> From: Lou Berger Message-ID: <44e5318a-4157-b825-b688-5185ab2458cb@labn.net> Date: Fri, 15 Dec 2017 15:55:19 -0500 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: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net> 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: 1ePx0q-000IRp-Pr 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]:47948 X-Source-Auth: lberger@labn.net X-Email-Count: 12 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-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: Fri, 15 Dec 2017 20:55:29 -0000 All, This last call is closed. We note that there was an update during the LC and that no comments were received during the LC period. As this is simply a mechanical update that has been discussed in the WG we plan to proceed with the publication process. Authors, Please let/us the WG know when you have published a version ready for publication. Also please let the WG know what has changed in the document since the start of LC (rev -01) Thank you, NetMod Chairs On 11/29/2017 12:26 PM, Lou Berger wrote: > All, > > This starts a two-week working group last call on > draft-ietf-netmod-rfc8022bis-01. > > Please recall that this update's intention is to > modify the YANG module to be in line with the NMDA > guidelines [1]. Reviewing the diff between the two > drafts [2] should reveal just this. > > The working group last call ends on December 13. > 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. > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > [2] https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=rfc8022.txt&url2=draft-ietf-netmod-rfc8022bis-01.txt > > Thank you, > Netmod Chairs > From nobody Fri Dec 15 13:03:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27417129427 for ; Fri, 15 Dec 2017 13:03:48 -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, HTML_MESSAGE=0.001, 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 EJY_O9uPrStx for ; Fri, 15 Dec 2017 13:03:45 -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 77C49129423 for ; Fri, 15 Dec 2017 13:03:45 -0800 (PST) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBFKxnCr012399; Fri, 15 Dec 2017 13:03:42 -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=LHP8NO1JSwG8uLp3TxSS5CgwQllMjHSh28Q7HQPLalE=; b=kiXDJaR2eXgukJnSV/BPVuUZ/iQqv0a5GBsIsz+LBKcF1UY0mGhLJ8YY2rYUchlTPBW0 VvuoAsJVNHGuTws6pUjRf9DPwwgiAwTevQHp2+inYJBNQDWqQgrCy9lvHMuetzN8Xcum Pd3wguAZHgBAdVIYB+wY78pRvZLhDc7rR1tGoYc6OsHfp3Ok3yB3MohWURKgojVAyzfU yYvRrmVLSSwrqNKD12J3kqyVfz7OGKUNinOvbWMhfWAA4h6Rs1bmFGQbX2ePS7H0qXe6 QTydcuwYe7SQH6MSdcWA3ordlsaq132DpCWx9bR/HEUXaix8KAiOZd+HPMCXiIgcNeNx Hg== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0015.outbound.protection.outlook.com [207.46.163.15]) by mx0b-00273201.pphosted.com with ESMTP id 2evng9r22q-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 15 Dec 2017 13:03:42 -0800 Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB276.namprd05.prod.outlook.com (10.141.22.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Fri, 15 Dec 2017 21:03:39 +0000 Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0323.015; Fri, 15 Dec 2017 21:03:39 +0000 From: Kent Watsen To: Lou Berger CC: Benoit Claise , NETMOD Working Group , "EXT - joelja@bogus.com" Thread-Topic: [netmod] Joel Jaeggli as a third NETMOD co-chair Thread-Index: AQHTdck6saQNfj8hwEeIuNvSc+nTWKNE2BkAgAAMsM0= Date: Fri, 15 Dec 2017 21:03:39 +0000 Message-ID: References: , <47fc9556-97c9-8451-cdc3-c5da3b44cdf7@labn.net> In-Reply-To: <47fc9556-97c9-8451-cdc3-c5da3b44cdf7@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2600:1010:b02b:95dc:e814:bfee:a547:5a08] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:8n8YQmF9/liup3je4x8oSBm4rPxBFGil1+JorarY8RDGQigkiKRuM1FCKKeLcoLGkdkUYZTIMoZWQSBRJbpkirzrYKIqdKR9drCJ0jbeId1GmJCAUjX5oulmnq3Neh5y/Qsauy/l/epta4GychJUle8pNGZW8K74kwfY5pFwokaK2XTzHdE0VYG9f3azDe1OOcN/IhPhFksZd3bmoUvwN6lY8CmyhO40fE+2qtcbUtRQH7OHX2SfUggdNO9kQcaA+sz4jdmCGOFuc13QNuGV2P2YztafYkMydLXB2W2esXR+oTSGfL97Rp41M2LmvW8bACtqv7HFk4GK131c9EaXSeK+wz0loh2qANeRArbUQSY=; 5:FQNMDABj519KQCCraKxlga1j7ULRcM18b2cxA/Sl65Eqp0aGLspoeazw5X73DETkBG40qFpdMElvhdgQsLxbhRHKI+b3/fJg0SA1b+t8SMMBvnn/d3HxdBYnY6E7wYfvJtkJh7bu+a6xM754g5iK2P14JGGArF1I8lcJJokC6vo=; 24:HooIsbcvCWmPWu2ziCYtlyK0E6sZm216aVmxUaouAiqYEfNakOdx0P5LlvzT/0bGZyPzOzFjaFGToh/oLtnsE9T6rd9pleGeZLAHTPPv3Is=; 7:haJHKP50K7ygaED0o8BUUKYCtAUmvy/L3SoFkYEg9PuKa2BAxoOmA8/QWzBUlMe6RQEsDBZJrIuLAEdPsb+H5Q069qvK+Z3SVH96Mavkn6PxQiSnwFb6rUTlUe3VI7qVmiJWisHQ47YL+G3eEIbWzAlmOe78njwh2uYTioXBsG9H2w0N8bVWQuVL859CqmGWjqnD7p2L90aIIUIkXafQ5wCfxSquhWMz3DGQCi+L22gda0uYV0PDpw8k0x+S9izk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a5d93d48-4292-4ed9-4cff-08d543ff50c6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153051); SRVR:BLUPR05MB276; x-ms-traffictypediagnostic: BLUPR05MB276: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB276; x-forefront-prvs: 05220145DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(39860400002)(24454002)(189003)(199004)(2906002)(59450400001)(3280700002)(36756003)(77096006)(6486002)(4326008)(53936002)(99286004)(3660700001)(8936002)(6512007)(54896002)(6436002)(236005)(5003630100001)(6306002)(53546011)(2900100001)(6246003)(6506007)(105586002)(606006)(68736007)(25786009)(114624004)(9886003)(82746002)(81166006)(86362001)(575784001)(966005)(14454004)(81156014)(83716003)(76176011)(478600001)(8676002)(97736004)(5660300001)(54906003)(316002)(6916009)(229853002)(102836003)(106356001)(6116002)(7736002)(33656002)(5880100001)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB276; H:BLUPR05MB275.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F3BE374F22804587AD1B0755DE14DA5Ejunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a5d93d48-4292-4ed9-4cff-08d543ff50c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 21:03:39.1500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB276 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-15_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-1712150293 Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2017 21:03:48 -0000 --_000_F3BE374F22804587AD1B0755DE14DA5Ejunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJbmRlZWQsIGNvbmdyYXRzIQ0KDQpLLg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIERl YyAxNSwgMjAxNywgYXQgMTI6MTkgUE0sIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFp bHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCg0KSm9lbCwNCg0KICAgIFdlbGNvbWUgYWJv YXJkIQ0KDQpMb3UNCg0KT24gMTIvMTUvMjAxNyAxMjoyMSBQTSwgQmVub2l0IENsYWlzZSB3cm90 ZToNCkRlYXIgYWxsLA0KDQpBIGxvdCBpcyBoYXBwZW5pbmcgdGhlc2UgZGF5cyBpbiB0aGUgd29y bGQgb2YgZGF0YSBtb2RlbGluZy1kcml2ZW4NCm1hbmFnZW1lbnQgYXQgdGhlIElFVEY6DQogICAg Tk1EQSBhcmNoaXRlY3R1cmUsIE5FVENPTkYsIFJFU1RDT05GDQogICAgTk1EQS1jb21wbGlhbnQg WUFORyBtb2R1bGVzOiBzb21lIFJGQyBiaXMgbW9kdWxlcyBidXQgYWxzbyBuZXcgb25lcw0KICAg IEd1aWRlbGluZXM6IFJGQzYwODdiaXMgYW5kIHRoZSB0cmVlIGRpYWdyYW0NCiAgICBUaGUgaW50 ZXJhY3Rpb24gd2l0aCBORVRDT05GOiBUaGUgc2NoZW1hIG1vdW50LCBJRVRGLVlBTkctTElCUkFS WSwNCnRlbGVtZXRyeQ0KICAgIFRoZSBpbnRlcmFjdGlvbiB3aXRoIHJvdXRpbmcsIHdoZXJlIG1h bnkgWUFORyBtb2R1bGVzIGNvbWUgZnJvbS4NCiAgICBldGMuDQpUaGVyZSBhcmUgYSBsb3Qgb2Yg ZGVwZW5kZW5jaWVzIGJldHdlZW4gYWxsIHRoZXNlIHRhc2tzLCB3aGljaCBtdXN0IHRha2UNCnBs YWNlIGluIHBhcmFsbGVsLCBhbmQsIG9idmlvdXNseSwgYmUgY29tcGxldGVkIEFTQVAuDQoNCktl bnQgYW5kIExvdSBoYXZlIGEgbG90IG9uIHRoZWlyIHNob3VsZGVycyB0aGVzZSBkYXlzLg0KVG8g aGVscCB3aXRoIHRoZSBzaXR1YXRpb24gYW5kIHByb2FjdGl2ZWx5IHByb2dyZXNzIGRvY3VtZW50 cywgSSdtIGhhcHB5DQp0byBhbm5vdW5jZSB0aGF0IEpvZWwgSmFlZ2dsaSBhY2NlcHRlZCB0byBz ZXJ2ZSBhcyBhIHRoaXJkIE5FVE1PRA0KY28tY2hhaXIuIFRoYW5rIHlvdSBKb2VsLg0KDQpQbGVh c2Ugd2VsY29tZSBKb2VsLg0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19uZXRtb2QmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv RFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt PWFRdHJjWV9HSGdSa0ZmV0tzOThzU2xfeVl5N01Bcm9tUnRSbTYzbWl3RlEmcz1teHUweTljaDdK N0ZlTlNwRGdaa2dGYU5vXzIyVWNvdjlOWHVzSTM1NkRFJmU9DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fbmV0bW9kJmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2 b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8m bT1hUXRyY1lfR0hnUmtGZldLczk4c1NsX3lZeTdNQXJvbVJ0Um02M21pd0ZRJnM9bXh1MHk5Y2g3 SjdGZU5TcERnWmtnRmFOb18yMlVjb3Y5Tlh1c0kzNTZERSZlPQ0K --_000_F3BE374F22804587AD1B0755DE14DA5Ejunipernet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KSW5kZWVkLCBjb25ncmF0cyENCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PksuJm5ic3A7PGJyPg0KPGJyPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5TZW50 IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIERlYyAxNSwgMjAxNywgYXQgMTI6 MTkgUE0sIExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5s YmVyZ2VyQGxhYm4ubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+Sm9lbCw8L3NwYW4+PGJyPg0KPHNwYW4+PC9z cGFuPjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyBXZWxjb21lIGFib2FyZCE8L3NwYW4+ PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPkxvdTwvc3Bhbj48YnI+DQo8c3Bhbj48L3Nw YW4+PGJyPg0KPHNwYW4+T24gMTIvMTUvMjAxNyAxMjoyMSBQTSwgQmVub2l0IENsYWlzZSB3cm90 ZTo8L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+RGVhciBhbGwsPC9z cGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwv c3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5B IGxvdCBpcyBoYXBwZW5pbmcgdGhlc2UgZGF5cyBpbiB0aGUgd29ybGQgb2YgZGF0YSBtb2RlbGlu Zy1kcml2ZW4NCjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48c3Bhbj5tYW5hZ2VtZW50IGF0IHRoZSBJRVRGOjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsgTk1E QSBhcmNoaXRlY3R1cmUsIE5FVENPTkYsIFJFU1RDT05GPC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyBOTURB LWNvbXBsaWFudCBZQU5HIG1vZHVsZXM6IHNvbWUgUkZDIGJpcyBtb2R1bGVzIGJ1dCBhbHNvIG5l dyBvbmVzPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyBHdWlkZWxpbmVzOiBSRkM2MDg3YmlzIGFuZCB0aGUg dHJlZSBkaWFncmFtPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgaW50ZXJhY3Rpb24gd2l0aCBORVRD T05GOiBUaGUgc2NoZW1hIG1vdW50LCBJRVRGLVlBTkctTElCUkFSWSwNCjwvc3Bhbj48YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj50ZWxlbWV0cnk8L3Nw YW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBpbnRlcmFjdGlvbiB3aXRoIHJvdXRpbmcsIHdoZXJlIG1hbnkg WUFORyBtb2R1bGVzIGNvbWUgZnJvbS48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV0Yy48L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+VGhlcmUgYXJl IGEgbG90IG9mIGRlcGVuZGVuY2llcyBiZXR3ZWVuIGFsbCB0aGVzZSB0YXNrcywgd2hpY2ggbXVz dCB0YWtlDQo8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+cGxhY2UgaW4gcGFyYWxsZWwsIGFuZCwgb2J2aW91c2x5LCBiZSBjb21wbGV0ZWQg QVNBUC48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPktlbnQgYW5kIExvdSBoYXZlIGEgbG90IG9uIHRoZWlyIHNob3VsZGVycyB0aGVzZSBk YXlzLjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj5UbyBoZWxwIHdpdGggdGhlIHNpdHVhdGlvbiBhbmQgcHJvYWN0aXZlbHkgcHJvZ3Jlc3Mg ZG9jdW1lbnRzLCBJJ20gaGFwcHkNCjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj50byBhbm5vdW5jZSB0aGF0IEpvZWwgSmFlZ2dsaSBhY2Nl cHRlZCB0byBzZXJ2ZSBhcyBhIHRoaXJkIE5FVE1PRA0KPC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmNvLWNoYWlyLiBUaGFuayB5b3UgSm9l bC48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxz cGFuPlBsZWFzZSB3ZWxjb21lIEpvZWwuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5SZWdhcmRzLCBCZW5vaXQ8L3NwYW4+PGJyPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPm5ldG1vZCBtYWlsaW5nIGxpc3Q8L3Nw YW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEg aHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjwvc3Bhbj48 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lHYVEmYW1wO2M9SEFr WXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2 WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPWFRdHJjWV9HSGdSa0ZmV0tz OThzU2xfeVl5N01Bcm9tUnRSbTYzbWl3RlEmYW1wO3M9bXh1MHk5Y2g3SjdGZU5TcERnWmtnRmFO b18yMlVjb3Y5Tlh1c0kzNTZERSZhbXA7ZT0iPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0 bW9kJmFtcDtkPUR3SUdhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv RFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj Wm8mYW1wO209YVF0cmNZX0dIZ1JrRmZXS3M5OHNTbF95WXk3TUFyb21SdFJtNjNtaXdGUSZhbXA7 cz1teHUweTljaDdKN0ZlTlNwRGdaa2dGYU5vXzIyVWNvdjlOWHVzSTM1NkRFJmFtcDtlPTwvYT48 L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxz cGFuPm5ldG1vZCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRv Om5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lHYVEmYW1w O2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQ MHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPWFRdHJjWV9HSGdS a0ZmV0tzOThzU2xfeVl5N01Bcm9tUnRSbTYzbWl3RlEmYW1wO3M9bXh1MHk5Y2g3SjdGZU5TcERn WmtnRmFOb18yMlVjb3Y5Tlh1c0kzNTZERSZhbXA7ZT0iPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fbmV0bW9kJmFtcDtkPUR3SUdhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst bmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJ U2xhSmRjWm8mYW1wO209YVF0cmNZX0dIZ1JrRmZXS3M5OHNTbF95WXk3TUFyb21SdFJtNjNtaXdG USZhbXA7cz1teHUweTljaDdKN0ZlTlNwRGdaa2dGYU5vXzIyVWNvdjlOWHVzSTM1NkRFJmFtcDtl PTwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_F3BE374F22804587AD1B0755DE14DA5Ejunipernet_-- From nobody Fri Dec 15 15:04:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA61126B71 for ; Fri, 15 Dec 2017 15:04:53 -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 IqBKjhR_u2-V for ; Fri, 15 Dec 2017 15:04:51 -0800 (PST) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 44F2C1241FC for ; Fri, 15 Dec 2017 15:04:51 -0800 (PST) Received: by mail-ot0-x244.google.com with SMTP id q3so9095629oth.2 for ; Fri, 15 Dec 2017 15:04:51 -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; bh=BkwEe/aW7ZOiGZhl3Ez0P2M07/nP6ia0mXa/3LBRwfc=; b=bH1vg612QFoGi6Y5oI7C4PyoRGgOt4cmuA84r2YwiWg080xGP0lHEWffDenu8Mwkbn pqaiC2i8Pnl7NpG65WLNk3Tm4Ej6YnBtbhwXSCdqYGfFtdeE45Q6mt8TNCqR9DGK46RG RBJPWZMlF53dW0+XwSfkvIBnPPEESSdGQrstORHsxplSPeO3Ft2MuZOq2XFGJ8637xgA Gb3rVg9tNc7CcHDJmsqTWf+hoUPkW/DIEEz7x79G0daxSIMqbndgtNk0yMlkVrVt/xUe XxYJieCexKzen5IEtNW+uJDgrMf7gW+PLfZQjssFJz2iW1wY9wfH8Z882Mwc+p7Rb6dE EkKA== 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; bh=BkwEe/aW7ZOiGZhl3Ez0P2M07/nP6ia0mXa/3LBRwfc=; b=TqxiYdpzE9UWwXrMUGTZ2ExRmbUAC5eZ5IGjvXSaM3ROr5azr5wR134G62DrzOdOJX 2XAJ10SfKna5dtKJaF2I6cbcgv9eczoAD2b8hKa4fRm0WDtCarMbc3wQgqCP4SyWaIjA QzVDHEJJosqXuD4Q/nJrMLzKINYBPifNE9YBaLHLWLRZtNreyx3J8aQKlrKH791ah/83 fEjWta3BTer9vPZsWmU2iyPCYG3gYpQfvlQGP5jjSkyDYnn1AMrnmbS7097OIhuNcWOv h8m5HPTYcu2EG0FfcwMd27PKNmT+n/OA/6fZtIw66Ol36THzBrIgmCXJS5Us5veoTDoo u00Q== X-Gm-Message-State: AKGB3mLjB/J3XOXQ3djfgVDNrZtc/6YKJTF9KTH57+RAg1c8zp6Ne4Ey IiQI1i3+j6npDXhjKXBJ0mo= X-Google-Smtp-Source: ACJfBot4IBcu4zZdUXwV3DGkuHqNxvzTTVuRPU6LaaoLRjAul9pKNh//NanQxLzw7Cc2goR/nz5gZw== X-Received: by 10.157.52.34 with SMTP id v31mr9015394otb.281.1513379090630; Fri, 15 Dec 2017 15:04:50 -0800 (PST) Received: from [100.65.101.83] ([206.16.17.196]) by smtp.gmail.com with ESMTPSA id u16sm3544562otc.11.2017.12.15.15.04.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 15:04:49 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.29.0.171205 Date: Fri, 15 Dec 2017 15:04:46 -0800 From: Jeff Tantsura To: Kent Watsen , Lou Berger CC: "EXT - joelja@bogus.com" , NETMOD Working Group Message-ID: <51C696B7-8C9C-4CD5-9D38-60E7772A07B1@gmail.com> Thread-Topic: [netmod] Joel Jaeggli as a third NETMOD co-chair References: <47fc9556-97c9-8451-cdc3-c5da3b44cdf7@labn.net> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3596195089_140235336" Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Dec 2017 23:04:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3596195089_140235336 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Welcome Joel! Cheers, Jeff From: netmod on behalf of Kent Watsen Date: Friday, December 15, 2017 at 13:03 To: Lou Berger Cc: "EXT - joelja@bogus.com" , NETMOD Working Group Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair Indeed, congrats! K. Sent from my iPhone On Dec 15, 2017, at 12:19 PM, Lou Berger wrote: Joel, Welcome aboard! Lou On 12/15/2017 12:21 PM, Benoit Claise wrote: Dear all, A lot is happening these days in the world of data modeling-driven management at the IETF: NMDA architecture, NETCONF, RESTCONF NMDA-compliant YANG modules: some RFC bis modules but also new ones Guidelines: RFC6087bis and the tree diagram The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, telemetry The interaction with routing, where many YANG modules come from. etc. There are a lot of dependencies between all these tasks, which must take place in parallel, and, obviously, be completed ASAP. Kent and Lou have a lot on their shoulders these days. To help with the situation and proactively progress documents, I'm happy to announce that Joel Jaeggli accepted to serve as a third NETMOD co-chair. Thank you Joel. Please welcome Joel. Regards, Benoit _______________________________________________ netmod mailing list netmod@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ&s=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e= _______________________________________________ netmod mailing list netmod@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ&s=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e= _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --B_3596195089_140235336 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Welco= me Joel!

 

Cheers,

Jeff

 

From: netmod <netmod-bounces@ietf.org>= on behalf of Kent Watsen <kwatsen@juniper.net>
Date: Friday= , December 15, 2017 at 13:03
To: Lou Berger <lberger@labn.net&g= t;
Cc: "EXT - joelja@bogus.com" <joelja@bogus.com>= , NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmo= d] Joel Jaeggli as a third NETMOD co-chair

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

Indeed, congrats!

=

 

=

K. 

Sent from my iPhone


On Dec 15, 2017, at 12:19 P= M, Lou Berger <lberger@labn.net>= wrote:

Joel,

 = ;   Welcome aboard!

Lou

On 12/15/2017 12:21 PM, Beno= it Claise wrote:

Dear all,

 

A lot is happening these days in the world = of data modeling-driven

management at the IETF:

    NMDA architecture, NETCONF, RESTCONF

    NMDA-compliant YANG modu= les: some RFC bis modules but also new ones

    Guidelines: RFC6087bis and the tree d= iagram

   = ; The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY,

telemetry

    The interaction with rout= ing, where many YANG modules come from.

    etc.

There are a lot of dependencies between all these tasks, whi= ch must take

place in p= arallel, and, obviously, be completed ASAP.

 

Kent and Lou have a lot on their shoulders these days.

To help with the situation and proactively= progress documents, I'm happy

to announce that Joel Jaeggli accepted to serve as a third NETMOD

co-chair. Thank you Joel.=

 

Please welcome Joel.

 

Regards, Benoit

 

_________= ______________________________________

netmod mailing list

netmod@ietf.org

https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_netmod&d=3D= DwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ= 9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DaQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63m= iwFQ&s=3Dmxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e=3D=


___________= ____________________________________
netmod mailing list
netmod@ietf.org
https://urldefens= e.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_netmod&= ;d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUv= ZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DaQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm= 63miwFQ&s=3Dmxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e=3D

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

--B_3596195089_140235336-- From nobody Fri Dec 15 20:35:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C466124239 for ; Fri, 15 Dec 2017 20:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 04-PJErvruc6 for ; Fri, 15 Dec 2017 20:34:59 -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 D9E811241F3 for ; Fri, 15 Dec 2017 20:34:59 -0800 (PST) Received: from mb.local (c-73-96-132-59.hsd1.or.comcast.net [73.96.132.59]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vBG4YrFC061766 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 16 Dec 2017 04:34:55 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-96-132-59.hsd1.or.comcast.net [73.96.132.59] claimed to be mb.local To: Kent Watsen , Lou Berger Cc: Benoit Claise , NETMOD Working Group References: <47fc9556-97c9-8451-cdc3-c5da3b44cdf7@labn.net> From: joel jaeggli Message-ID: <420d9dde-beb7-5ef8-263b-b2df71152846@bogus.com> Date: Fri, 15 Dec 2017 20:34:43 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Thunderbird/58.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2017 04:35:01 -0000 Thanks, sounds like we have a lot of docs to look after. looking forward to helping out. joel On 12/15/17 13:03, Kent Watsen wrote: > > Indeed, congrats! > > K. > > Sent from my iPhone > > On Dec 15, 2017, at 12:19 PM, Lou Berger > wrote: > > Joel, > > Welcome aboard! > > Lou > > On 12/15/2017 12:21 PM, Benoit Claise wrote: > Dear all, > > A lot is happening these days in the world of data modeling-driven > management at the IETF: > NMDA architecture, NETCONF, RESTCONF > NMDA-compliant YANG modules: some RFC bis modules but also new ones > Guidelines: RFC6087bis and the tree diagram > The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, > telemetry > The interaction with routing, where many YANG modules come from. > etc. > There are a lot of dependencies between all these tasks, which must take > place in parallel, and, obviously, be completed ASAP. > > Kent and Lou have a lot on their shoulders these days. > To help with the situation and proactively progress documents, I'm happy > to announce that Joel Jaeggli accepted to serve as a third NETMOD > co-chair. Thank you Joel. > > Please welcome Joel. > > Regards, Benoit > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ&s=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e= > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aQtrcY_GHgRkFfWKs98sSl_yYy7MAromRtRm63miwFQ&s=mxu0y9ch7J7FeNSpDgZkgFaNo_22Ucov9NXusI356DE&e= > From nobody Fri Dec 15 21:49:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668D126DC2 for ; Fri, 15 Dec 2017 21:49:14 -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 MMx_l3MywnRo for ; Fri, 15 Dec 2017 21:49:12 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 84E78126B71 for ; Fri, 15 Dec 2017 21:49:12 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id e3so7536505pfi.10 for ; Fri, 15 Dec 2017 21:49:12 -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=+55BQ9XjqIPt/hM9KfxzVzp5cRptwzMB4VwCiet5RL4=; b=shpTSsEpRmmlLDlYmr+tEBeqyy8BeA7ox3ZPs9HCYdF0t2K2gAYPo01K/wugPP0qRW XUG0fMeqIraIJzfCrmkra5wCF+aTGXuWjqlr72HemiXU4kV9Q9HksQO/7uyab5mkdwYM MCpwTgCvRZ76TE0OlzNIkmH/fm4WojBGqLzeLH1x0H5mt9PSeTIQT8m2BN9oy7Ux5Nxn pJZiCYjFzKHr8OcsaEkAwGkhdYMI8T8EfsrLmmNkEkv8c21jtsvp0dHzbRh+JsJ2WvRT 5dDjgu3CZ3unGo+E4Tt6L9faNjmFYLT+4n+Q+ownyltZRJPhj6iz4qZj5NU7uFyk2+X/ YU7w== 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=+55BQ9XjqIPt/hM9KfxzVzp5cRptwzMB4VwCiet5RL4=; b=mAYsak0MwlWYjBP1fQzyYfmpaLevcT/HqC7FWYa30aQJUnZPHj8LYkZWfyglO+X9Ux 9YlK+StjRjtreIKL3bSMUImaGAlQKYfSQcxrsaKFX54Yzb6JiniNNG8AhIm4OKsTgod2 /e7xNlDxIkdZl6cwiHJKEABB6iCYGTldn/4s97jaELkTxXiUj2HAS/f+WT8SSxFhAvdI NfQg0148jhyXmMcb3WOqIrgQO7tAc4IjCrV1lnH4nvac2IEIfQnVNyS9gr8cpHuAxGnI njDDJWtDI0Ub3jMsVRNid296jQLUlLH5lugyP0N33kOVjN6EVogjP7jqsjvOOQ9URni/ Lh9g== X-Gm-Message-State: AKGB3mLUjjBem363jK7r7d+R8jdqOk8Qr1Ulya7MBMEB8IUSZOhRc3lU a4sBgDcV0dtQ+WroJNMgFNg= X-Google-Smtp-Source: ACJfBot5z7f5lhpzoj3ueWws5WXGIzdXbF/F+kOg3HpQo+/IyyLm+wDZNx6/bMG6Ug5v+y6RN73eRA== X-Received: by 10.101.78.205 with SMTP id w13mr14056105pgq.202.1513403351815; Fri, 15 Dec 2017 21:49:11 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id j62sm11180396pgc.35.2017.12.15.21.49.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Dec 2017 21:49:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Fri, 15 Dec 2017 21:49:06 -0800 Cc: NETMOD Working Group , Benoit Claise Content-Transfer-Encoding: quoted-printable Message-Id: <1152A14B-B19C-4411-87A0-879AFE60CAD7@gmail.com> References: To: Joel jaeggli X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2017 05:49:14 -0000 Joel, Welcome. Look forward to the interaction with NETCONF. Cheers. > On Dec 15, 2017, at 9:21 AM, Benoit Claise wrote: >=20 > Dear all, >=20 > A lot is happening these days in the world of data modeling-driven = management at the IETF: > NMDA architecture, NETCONF, RESTCONF > NMDA-compliant YANG modules: some RFC bis modules but also new = ones > Guidelines: RFC6087bis and the tree diagram > The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, = telemetry > The interaction with routing, where many YANG modules come from. > etc. > There are a lot of dependencies between all these tasks, which must = take place in parallel, and, obviously, be completed ASAP. >=20 > Kent and Lou have a lot on their shoulders these days. > To help with the situation and proactively progress documents, I'm = happy to announce that Joel Jaeggli accepted to serve as a third NETMOD = co-chair. Thank you Joel. >=20 > Please welcome Joel. >=20 > Regards, Benoit >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com From nobody Sat Dec 16 01:46:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964A126C22 for ; Sat, 16 Dec 2017 01:46:49 -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 5oFoeTyv0gQH for ; Sat, 16 Dec 2017 01:46:48 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3138812025C for ; Sat, 16 Dec 2017 01:46:48 -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 E81C91AE0475; Sat, 16 Dec 2017 10:46:45 +0100 (CET) Date: Sat, 16 Dec 2017 10:46:45 +0100 (CET) Message-Id: <20171216.104645.2140965470373068531.mbj@tail-f.com> To: vladimir@transpacket.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <937fadab-b3f0-1246-8543-00cb4d6a5acd@transpacket.com> References: <20171213.154734.273404682004037071.mbj@tail-f.com> <500e497e-9a80-8d00-22ca-6fe271fcd725@transpacket.com> <937fadab-b3f0-1246-8543-00cb4d6a5acd@transpacket.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] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2017 09:46:50 -0000 Hi, Vladimir Vassilev wrote: > = > On 12/13/2017 04:26 PM, Vladimir Vassilev wrote: > > Hi, > > > > On 12/13/2017 03:47 PM, Martin Bjorklund wrote: > > > >> Hi, > >> > >> Thanks for reporting this.=A0 I'll add the missing origin.=A0 But = why did > >> you think forwarding and mtu should be removed? > > 1. IMO since is not present in the container in the > > Appendix A () example and does not have default value i= n > > the model I still think it should be removed. > Alternatively the ipv4/mtu node can be a good example of a > origin=3D"or:system" configuration. Yes. > >> =A0=A0 In fact, I think I > >> missed , > > 2. IMO both fixes adding or removing should = be > > OK depending on the RFC6243 defined with-defaults capability > > 'basic-mode' parameter advertised by the server. I was running the > > example with basic-mode=3Dexplicit Right. I now have this: true false 1500
192.0.2.1 24 static
192.0.2.2 00:01:02:03:04:05 true false 1280 ... Do you think this is ok? /martin From nobody Sat Dec 16 05:20:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F1A126B7F for ; Sat, 16 Dec 2017 05:20:00 -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, 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 u84TC7khcSVD for ; Sat, 16 Dec 2017 05:19:56 -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 19530126BFD for ; Sat, 16 Dec 2017 05:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65896; q=dns/txt; s=iport; t=1513430396; x=1514639996; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u7c5CrlRnBiQ0c4ESuD0fbLz6hCo5zcDsDftrJb4Q1M=; b=Icjmduau9F+0lCSbMcVWKPdPaKN5MtZq22Ubl5Gbduc2Wz3gF71qZ9U4 Zs9rrIsB9bEjK34ds6eKsf367DCaOBh+4sAwsFtW6HGzgwidQB5R3sHCc xah84twLzBmAXwHP4h1tARiH+fdGV1PZfhfz+tjaMSZ8to2QkDxpuMpOb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAAAbHTVa/4QNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDDy9mdCcHg3yKIY8GiwGOIBSBfgMKGAEKgTkBgw9PAhqEZj8?= =?us-ascii?q?YAQEBAQEBAQEBax0LhSQCAQMBASEERwsQAgEIOAEGAwICAh8GCxQRAgQOBYlGT?= =?us-ascii?q?AMVEKgPgW06hzQNgyYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNpgg6DPgEpgwO?= =?us-ascii?q?CakQBgUQSF4MWMYIyBZIbh0KJIj0Ch32IL4R+ghaGE4tJjRo+hVuDFwIRGQGBO?= =?us-ascii?q?gEfOYFPbxU8KgGBfj+BW4I8eIlEgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,410,1508803200"; d="scan'208,217";a="326948041" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Dec 2017 13:19:54 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBGDJsg5019300 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Dec 2017 13:19:54 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; Sat, 16 Dec 2017 08:19: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; Sat, 16 Dec 2017 08:19:52 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: "netmod@ietf.org" CC: Kristian Larsson , Sonal Agarwal , Mahesh Jethanandani , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAAzEsAgACvpICAAshNAA== Date: Sat, 16 Dec 2017 13:19:52 +0000 Message-ID: <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@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> In-Reply-To: <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.211.5] Content-Type: multipart/alternative; boundary="_000_0F43CDE921D24ED7AE7C9A2B9F854101ciscocom_" 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: Sat, 16 Dec 2017 13:20:00 -0000 --_000_0F43CDE921D24ED7AE7C9A2B9F854101ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpBZnRlciBhIHNlcmllcyBvZiBkaXNjdXNzaW9ucyBvbi0gYW5kIG9mZi1saXN0LCBJ IGhhdmUgYSBjYW5kaWRhdGUgUFIgdGhhdCBpbmNsdWRlcyB0aGUgY2hhbmdlcyBpbiB0aGUgUFIg TWFoZXNoIHNlbnQgb3V0IHBsdXMgc29tZSBtb3JlIGVkaXRzLiBQbGVhc2Ugc2VlIGNvbnNvbGlk YXRlZCBQUiBoZXJlOg0KDQpodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9w dWxsLzIxDQoNCk1haW4gY2hhbmdlcyBpbiBhZGRpdGlvbiB0byBNYWhlc2jigJlzIFBSIGFyZToN Cg0KDQogICogICBNb3ZlZCBpbnRlcmZhY2UgYXR0YWNobWVudCB0byBiZSB2aWEgYW4gaW50ZXJm YWNlIGF1Z21lbnRhdGlvbi4NCiAgKiAgIFJlc3RydWN0dXJlZCBwb3J0IG1hdGNoZXMgc2xpZ2h0 bHkgdW5kZXIgYm90aCBJUHY0IGFuZCBJUHY2IGNvbnRhaW5lcnMuDQogICogICBSZW1vdmVkIHVu bmVjZXNzYXJ5IGlkZW50aXR5ICdpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZeKAmS4NCiAgKiAgIFJl bW92ZWQgYWN0aW9uIOKAmGljbXAtb2Zm4oCZLCBjYW4gYmUgYXVnbWVudGVkIGxhdGVyLg0KDQpG b3IgcmVmZXJlbmNlLCBoZXJlIGlzIHRoZSBjdXJyZW50IFlBTkcgdHJlZSBwbHVzIOKAnC0taWV0 ZuKAnSBsb2dzOg0KDQoxMzoxMiAkIHB5YW5nIC0taWV0ZiAtLWxpbnQgLWYgdHJlZSBpZXRmLWFj Y2Vzcy1jb250cm9sLWxpc3QueWFuZw0KaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc6NTE6 IGVycm9yOiBiYWQgdmFsdWUgIllZWVktTU0tREQiIChzaG91bGQgYmUgZGF0ZSkNCm1vZHVsZTog aWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0DQogICAgKy0tcncgYWNjZXNzLWxpc3RzDQogICAgICAg Ky0tcncgYWNsKiBbbmFtZV0NCiAgICAgICAgICArLS1ydyBuYW1lICAgIHN0cmluZw0KICAgICAg ICAgICstLXJ3IHR5cGU/ICAgYWNsLXR5cGUNCiAgICAgICAgICArLS1ydyBhY2VzDQogICAgICAg ICAgICAgKy0tcncgYWNlKiBbbmFtZV0NCiAgICAgICAgICAgICAgICArLS1ydyBuYW1lICAgICAg ICAgIHN0cmluZw0KICAgICAgICAgICAgICAgICstLXJ3IG1hdGNoZXMNCiAgICAgICAgICAgICAg ICB8ICArLS1ydyAobDIpPw0KICAgICAgICAgICAgICAgIHwgIHwgICstLTooZXRoKQ0KICAgICAg ICAgICAgICAgIHwgIHwgICAgICstLXJ3IGV0aCB7bWF0Y2gtb24tZXRofT8NCiAgICAgICAgICAg ICAgICB8ICB8ICAgICAgICArLS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcz8gICAgICAgIHlh bmc6bWFjLWFkZHJlc3MNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBkZXN0aW5h dGlvbi1tYWMtYWRkcmVzcy1tYXNrPyAgIHlhbmc6bWFjLWFkZHJlc3MNCiAgICAgICAgICAgICAg ICB8ICB8ICAgICAgICArLS1ydyBzb3VyY2UtbWFjLWFkZHJlc3M/ICAgICAgICAgICAgIHlhbmc6 bWFjLWFkZHJlc3MNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBzb3VyY2UtbWFj LWFkZHJlc3MtbWFzaz8gICAgICAgIHlhbmc6bWFjLWFkZHJlc3MNCiAgICAgICAgICAgICAgICB8 ICB8ICAgICAgICArLS1ydyBldGhlcnR5cGU/ICAgICAgICAgICAgICAgICAgICAgIGV0aDpldGhl cnR5cGUNCiAgICAgICAgICAgICAgICB8ICArLS1ydyAobDMpPw0KICAgICAgICAgICAgICAgIHwg IHwgICstLTooaXB2NCkNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBpcHY0IHttYXRj aC1vbi1pcHY0fT8NCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBkc2NwPyAgICAg ICAgICAgICAgICAgICAgICAgaW5ldDpkc2NwDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAg Ky0tcncgZWNuPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAg fCAgfCAgfCAgICAgKy0tcncgbGVuZ3RoPyAgICAgICAgICAgICAgICAgICAgIHVpbnQxNg0KICAg ICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHR0bD8gICAgICAgICAgICAgICAgICAgICAg ICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHByb3RvY29sPyAgICAg ICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IChz b3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcik/DQogICAgICAgICAgICAgICAgfCAgfCAgfCAg ICAgfCAgKy0tOihyYW5nZSkNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICB8ICArLS1y dyBzb3VyY2UtcG9ydC1sb3dlciAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAg ICAgICAgIHwgIHwgIHwgICAgIHwgIHwgICstLXJ3IHNvdXJjZS1wb3J0LXVwcGVyICAgICAgICAg ICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgfCAgKy0tOihv cGVyYXRvcikNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICAgICArLS1ydyBzb3VyY2Ut b3BlcmF0b3IgICAgICAgICAgICAgb3BlcmF0b3INCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAg ICB8ICAgICArLS1ydyBzb3VyY2UtcG9ydCAgICAgICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJl cg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IChkZXN0aW5hdGlvbi1wb3J0LXJh bmdlLW9yLW9wZXJhdG9yKT8NCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICArLS06KHJh bmdlKQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgIHwgICstLXJ3IGRlc3RpbmF0aW9u LXBvcnQtbG93ZXIgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAg fCAgICAgfCAgfCAgKy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciAgICAgIGluZXQ6cG9ydC1u dW1iZXINCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICArLS06KG9wZXJhdG9yKQ0KICAg ICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICAgICstLXJ3IGRlc3RpbmF0aW9uLW9wZXJhdG9y ICAgICAgICBvcGVyYXRvcg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICAgICstLXJ3 IGRlc3RpbmF0aW9uLXBvcnQgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAg ICAgICAgfCAgfCAgfCAgICAgKy0tcncgaWhsPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4 DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgZmxhZ3M/ICAgICAgICAgICAgICAg ICAgICAgIGJpdHMNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBvZmZzZXQ/ICAg ICAgICAgICAgICAgICAgICAgdWludDE2DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0t cncgaWRlbnRpZmljYXRpb24/ICAgICAgICAgICAgIHVpbnQxNg0KICAgICAgICAgICAgICAgIHwg IHwgIHwgICAgICstLXJ3IGRlc3RpbmF0aW9uLWlwdjQtbmV0d29yaz8gICBpbmV0OmlwdjQtcHJl Zml4DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgc291cmNlLWlwdjQtbmV0d29y az8gICAgICAgIGluZXQ6aXB2NC1wcmVmaXgNCiAgICAgICAgICAgICAgICB8ICB8ICArLS06KGlw djYpDQogICAgICAgICAgICAgICAgfCAgfCAgICAgKy0tcncgaXB2NiB7bWF0Y2gtb24taXB2Nn0/ DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgZHNjcD8gICAgICAgICAgICAgICAg ICAgICAgIGluZXQ6ZHNjcA0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IGVjbj8g ICAgICAgICAgICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAg ICstLXJ3IGxlbmd0aD8gICAgICAgICAgICAgICAgICAgICB1aW50MTYNCiAgICAgICAgICAgICAg ICB8ICB8ICAgICAgICArLS1ydyB0dGw/ICAgICAgICAgICAgICAgICAgICAgICAgdWludDgNCiAg ICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBwcm90b2NvbD8gICAgICAgICAgICAgICAg ICAgdWludDgNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyAoc291cmNlLXBvcnQt cmFuZ2Utb3Itb3BlcmF0b3IpPw0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICstLToo cmFuZ2UpDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgfCAgKy0tcncgc291cmNlLXBv cnQtbG93ZXIgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICAgICB8ICB8 ICAgICAgICB8ICB8ICArLS1ydyBzb3VyY2UtcG9ydC11cHBlciAgICAgICAgICAgaW5ldDpwb3J0 LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICstLToob3BlcmF0b3IpDQog ICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgICAgKy0tcncgc291cmNlLW9wZXJhdG9yICAg ICAgICAgICAgIG9wZXJhdG9yDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgICAgKy0t cncgc291cmNlLXBvcnQgICAgICAgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAg ICAgICAgICB8ICB8ICAgICAgICArLS1ydyAoZGVzdGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVy YXRvcik/DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgKy0tOihyYW5nZSkNCiAgICAg ICAgICAgICAgICB8ICB8ICAgICAgICB8ICB8ICArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LWxvd2Vy ICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwgIHwg ICstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAg ICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgKy0tOihvcGVyYXRvcikNCiAgICAgICAgICAgICAg ICB8ICB8ICAgICAgICB8ICAgICArLS1ydyBkZXN0aW5hdGlvbi1vcGVyYXRvciAgICAgICAgb3Bl cmF0b3INCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgICArLS1ydyBkZXN0aW5hdGlv bi1wb3J0ICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwg ICAgICAgICstLXJ3IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29yaz8gICBpbmV0OmlwdjYtcHJlZml4 DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgc291cmNlLWlwdjYtbmV0d29yaz8g ICAgICAgIGluZXQ6aXB2Ni1wcmVmaXgNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1y dyBmbG93LWxhYmVsPyAgICAgICAgICAgICAgICAgaW5ldDppcHY2LWZsb3ctbGFiZWwNCiAgICAg ICAgICAgICAgICB8ICArLS1ydyAobDQpPw0KICAgICAgICAgICAgICAgIHwgIHwgICstLToodGNw KQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IHRjcCB7bWF0Y2gtb24tdGNwfT8NCiAg ICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBzZXF1ZW5jZS1udW1iZXI/ICAgICAgICAg IHVpbnQzMg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGFja25vd2xlZGdlbWVu dC1udW1iZXI/ICAgdWludDMyDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgZGF0 YS1vZmZzZXQ/ICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAg ICstLXJ3IHJlc2VydmVkPyAgICAgICAgICAgICAgICAgdWludDgNCiAgICAgICAgICAgICAgICB8 ICB8ICB8ICAgICArLS1ydyBmbGFncz8gICAgICAgICAgICAgICAgICAgIGJpdHMNCiAgICAgICAg ICAgICAgICB8ICB8ICB8ICAgICArLS1ydyB3aW5kb3ctc2l6ZT8gICAgICAgICAgICAgIHVpbnQx Ng0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHVyZ2VudC1wb2ludGVyPyAgICAg ICAgICAgdWludDE2DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgb3B0aW9ucz8g ICAgICAgICAgICAgICAgICB1aW50MzINCiAgICAgICAgICAgICAgICB8ICB8ICArLS06KHVkcCkN CiAgICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyB1ZHAge21hdGNoLW9uLXVkcH0/DQogICAg ICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgbGVuZ3RoPyAgIHVpbnQxNg0KICAgICAgICAg ICAgICAgIHwgIHwgICstLTooaWNtcCkNCiAgICAgICAgICAgICAgICB8ICB8ICAgICArLS1ydyBp Y21wIHttYXRjaC1vbi1pY21wfT8NCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyB0 eXBlPyAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3 IGNvZGU/ICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0t cncgcmVzdC1vZi1oZWFkZXI/ICAgdWludDMyDQogICAgICAgICAgICAgICAgfCAgKy0tcncgZWdy ZXNzLWludGVyZmFjZT8gICAgaWY6aW50ZXJmYWNlLXJlZg0KICAgICAgICAgICAgICAgIHwgICst LXJ3IGluZ3Jlc3MtaW50ZXJmYWNlPyAgIGlmOmludGVyZmFjZS1yZWYNCiAgICAgICAgICAgICAg ICArLS1ydyBhY3Rpb25zDQogICAgICAgICAgICAgICAgfCAgKy0tcncgZm9yd2FyZGluZyAgICBp ZGVudGl0eXJlZg0KICAgICAgICAgICAgICAgIHwgICstLXJ3IGxvZ2dpbmc/ICAgICAgaWRlbnRp dHlyZWYNCiAgICAgICAgICAgICAgICArLS1ybyBzdGF0aXN0aWNzIHthY2wtYWdncmVnYXRlLXN0 YXRzfT8NCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpj b3VudGVyNjQNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFu Zzpjb3VudGVyNjQNCg0KICBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZToNCiAg ICArLS1ydyBhY2xzDQogICAgICAgKy0tcncgaW5ncmVzcw0KICAgICAgIHwgICstLXJ3IGFjbC1z ZXRzDQogICAgICAgfCAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgICAgfCAgICAgICAg Ky0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgICAg IHwgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5 cGUNCiAgICAgICB8ICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZh Y2Utc3RhdHN9Pw0KICAgICAgIHwgICAgICAgICAgICstLXJvIG5hbWUgICAgICAgICAgICAgICAt PiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAgICAgfCAgICAgICAgICAgKy0t cm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgfCAgICAgICAgICAg Ky0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgKy0tcncgZWdy ZXNzDQogICAgICAgICAgKy0tcncgYWNsLXNldHMNCiAgICAgICAgICAgICArLS1ydyBhY2wtc2V0 KiBbbmFtZV0NCiAgICAgICAgICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAtPiAvYWNj ZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgICAgICAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAg ICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgICAgICAgICAgICAgICstLXJvIGFjZS1z dGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgICAgICAgICAgICAgICAg Ky0tcm8gbmFtZSAgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25h bWUNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3Vu dGVyNjQNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpj b3VudGVyNjQNCg0KQ29tbWVudHMgd2VsY29tZSENCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQoNCg0K T24gMTQgRGVjIDIwMTcsIGF0IDE4OjUwLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikg PGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoN Cg0KT24gMTQgRGVjIDIwMTcsIGF0IDA4OjIxLCBTb25hbCBBZ2Fyd2FsIDxzYWdhcndhbDEyQGdt YWlsLmNvbTxtYWlsdG86c2FnYXJ3YWwxMkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgRWluYXIs DQoNCllvdSBoYWQgMyBxdWVzdGlvbnMgZm9yIG1lIG9uIGFsbCB0aGUgc2V2ZXJhbCBlLW1haWwg dGhyZWFkcy4NCjEuIEdsb2JhbCBhdHRhY2htZW50IHBvaW50DQoyLiBpY21wLW9mZg0KMy4gYWNs LWFnZ3JlZ2F0ZS1pbnRlcmZhY2Ugc3RhdHMuDQoNCkZvciAoMSksIG15IGZpcnN0IHByZWZlcmVu Y2UgaXMgdG8gaGF2ZSB0aGUgbW9kZWwgZGVmaW5lIGF0dGFjaG1lbnQgcG9pbnQgZm9yIGludGVy ZmFjZXMgb25seS4NCg0KZWluYXJubj4gSSBoYXZlIHNvbWUgZGlmZnMsIGxheWVyZWQgb24gdG9w IG9mIE1haGVzaOKAmXMgUFIgdG8gbmV0bW9kLXdnL2FjbC1tb2RlbCB0aGF0IGRvIHRoaXMuIE5l YXJseSBsaWtlIHRoZSBhdWdtZW50YXRpb24gSSBoYXZlIGJlbG93LiBGZWVsIGZyZWUgdG8gdGFr ZSBhIGxvb2sgYXQ6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9tamV0aGFuYW5kYW5pL2FjbC1tb2Rl bC9wdWxsLzMNCg0KSG93ZXZlciwgS3Jpc3RpYW4gd2FudHMgdGhlIGdsb2JhbCBhdHRhY2htZW50 IHBvaW50IGFzIHdlbGwgc28gdGhhdCBoZSBjYW4gYWRkIHRoZSBBQ0wgdG8gdGhlIGxpbnV4IHRh Ymxlcy4NCg0KZWluYXJubj4gSSB0aGluayBLcmlzdGlhbiBkb2VzbuKAmXQgZmVlbCBhIGdsb2Jh bCBhdHRhY2htZW50IHBvaW50IG5lZWRzIHRvIGJlIGluIHRoaXMgZmlyc3QgcmV2aXNpb24uIEJ1 dCBoZSBjYW4gY29uZmlybS4NCg0KSWYgYW4gQUNMIGlzIGF0dGFjaGVkIGdsb2JhbGx5LCBkb2Vz IHRoaXMgbWVhbiBpdCBpcyBwZXIgZGlyZWN0aW9uIG9yIGRvZXMgaXQgbWVhbiBpdCBpcyBhY3Jv c3MgZGlyZWN0aW9ucz8NCg0KZWluYXJubj4gSSBkb27igJl0IGtub3cgcmlnaHQgbm93IDotKQ0K DQpUaGlzIGdsb2JhbCBBQ0wgbWF5IG5vdCBiZSBhcHBsaWNhYmxlIHRvIGFueSBvZiBDaXNjbydz IHNlcnZpY2UgcHJvdmlkZXIgcm91dGVycyBhcyBJIGRvbid0IHNlZSBhbnkgcGxhdGZvcm0gYWN0 dWFsbHkgcmVwbGljYXRpbmcgdGhlIEFDTCB0byBhbGwgbGluZSBjYXJkcyBhbmQgYXR0YWNoaW5n IGl0IGluIGluZ3Jlc3MgYW5kIGVncmVzcyBkaXJlY3Rpb25zIGFjcm9zcyBhbGwgaW50ZXJmYWNl cy4NCg0KZWluYXJubj4gUGVyIG90aGVyIGVtYWlscywgSSBkb27igJl0IHRoaW5rIHdlIHVuZGVy c3RhbmQgdGhpcyBlbm91Z2ggeWV0IHRvIHNwZWNpZnkgaXQsIHNvIEkgc3VnZ2VzdCB3ZSBqdXN0 IGxlYXZlIGl0IG91dCBmb3Igbm93LiBOb3RoaW5nIGluIHRoZSBtb2RlbCBwcmV2ZW50cyBhIOKA nGdsb2JhbCBhdHRhY2htZW50IHBvaW504oCdIGJlaW5nIGFkZGVkIGxhdGVyIG9uY2Ugd2UgdW5k ZXJzdGFuZCB3aGF0IGl0IHJlYWxseSBtZWFucy4NCg0KRm9yICgyKSwgSSBhbSBvayB3aXRoIHJl bW92aW5nIGljbXAtb2ZmLg0KDQplaW5hcm5uPiBEb25lIGluIG15IFBSIGFib3ZlLg0KDQpGb3Ig KDMpLCB0aGlzIHdvdWxkIGhhdmUgdG8gYmUgYSBjb21iaW5hdGlvbiBvZiBBQ0wgc3RhdHMgYWNy b3NzIGFsbCBpbnRlcmZhY2VzIGZvciBhbGwgQUNMJ3MuIFNvbWV0aGluZyBsaWtlIHRoaXMgaXMg cG9zc2libGUgb24gYW4gWFIgYm94IHdoZXJlIEFDRVMgaGF2ZSBjb3VudGVyIG5hbWVzIGFzc29j aWF0ZWQgd2l0aCBpdC4gTGV0J3MgY2hhdCBhYm91dCB0aGlzIG9mZmxpbmUgdG9tb3Jyb3cuDQoN CmVpbmFybm4+IEnigJlsbCBwaW5nIHlvdSB0byBjbGFyaWZ5LCBhbmQgd2UgY2FuIGJyaW5nIGFu eSBjb25jbHVzaW9uIGJhY2sgdG8gdGhlIGxpc3QuDQoNCkNoZWVycywNCg0KRWluYXINCg0KDQoN ClNvbmFsLg0KDQoNCk9uIFdlZCwgRGVjIDEzLCAyMDE3IGF0IDEyOjEwIFBNLCBNYWhlc2ggSmV0 aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20+PiB3cm90ZToNCldlIHdhbnQgdG8gc3VwcG9ydCDigJxnbG9iYWzigJ0gYXR0YWNo bWVudCBwb2ludCBkb3duIHRoZSBsaW5lLCBhbmQgdGhhdCDigJxnbG9iYWzigJ0gYXR0YWNobWVu dCBwb2ludCB3aWxsIGJlIG9uZSBvZiB0aGUgY2hvaWNlcyAodGhlIG90aGVyIGJlaW5nIHRoZSBp bnRlcmZhY2UpLCB3aGF0IHdvdWxkIHRoaXMgYXVnbWVudCBsb29rIGxpa2UuIE5vdGUsIGFzIGZh ciBhcyBJIGtub3csIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUgYSBjaG9pY2Ugbm9kZS4NCg0K T24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJu bikgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdyb3RlOg0K DQpQZXJoYXBzIGxpa2UgdGhpcywgYXMgYW4gYXVnbWVudGF0aW9uIHRvIHRoZSBpbnRlcmZhY2U6 DQoNCiAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6DQogICAgKy0tcncgaW5n cmVzcy1hY2xzDQogICAgfCAgKy0tcncgYWNsLXNldHMNCiAgICB8ICAgICArLS1ydyBhY2wtc2V0 KiBbbmFtZV0NCiAgICB8ICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAtPiAvYWNjZXNz LWxpc3RzL2FjbC9uYW1lDQogICAgfCAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAgICAgLT4g L2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgIHwgICAgICAgICstLXJvIGFjZS1zdGF0aXN0aWNz KiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgfCAgICAgICAgICAgKy0tcm8gbmFtZSAg ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUNCiAgICB8ICAg ICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAgICB8ICAg ICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCiAgICArLS1y dyBlZ3Jlc3MtYWNscw0KICAgICAgICstLXJ3IGFjbC1zZXRzDQogICAgICAgICAgKy0tcncgYWNs LXNldCogW25hbWVdDQogICAgICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2Fj Y2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgICAgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAg IC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICAgICAgICAgICArLS1ybyBhY2Utc3RhdGlz dGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgICAgICAgICAgICAgICstLXJvIG5h bWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAg ICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAg ICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQoNCkNv dWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFpbmVyIGFib3ZlIGJvdGggdGhlc2UgJiBy ZW5hbWUg4oCcaW5ncmVzcy1hY2xzIiB0byDigJxpbmdyZXNz4oCdLCBldGMuIHRvIGdpdmUgYSBz aW5nbGUgcm9vdCBmb3IgdGhlIGF1Z21lbnRhdGlvbiBpZiBwcmVmZXJyZWQuDQoNCkNoZWVycywN Cg0KRWluYXINCg0KDQpPbiA2IERlYyAyMDE3LCBhdCAxOTo0MywgRWxpb3QgTGVhciA8bGVhckBj aXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KDQpPbiAxMi82LzE3 IDc6MjMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6DQpIb3cgZG9lcyBvbmUgbW92ZSB0 aGUgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsIGN1cnJlbnRseSBhbg0KJ2ludGVyZmFjZS1y ZWYnLCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlIGlmOmludGVyZmFjZXMvaW50ZXJmYWNlLA0K aW5zaWRlIG9mIHRoZSDigJhhY2zigJkgIGNvbnRhaW5lcj8gRG93biB0aGUgbGluZSB3ZSBtaWdo dCBuZWVkIHRvIGhhdmUgYW4NCmNvbnRhaW5lciBmb3IgImF0dGFjaG1lbnQgcG9pbnRzIiB0byBh Y2NvbW1vZGF0ZSB0aGUgcG9zc2liaWxpdHkgb2YNCmF0dGFjaGluZyBhbiBBQ0wgZWl0aGVyIHRv IGFuIGludGVyZmFjZSBvciDigJxnbG9iYWxseeKAnS4NCg0KDQpLZWVwaW5nIGluIG1pbmQgdGhh dCBvbmUgdXNlIGlzIHRoYXQgYW4gQUNMIGRvZXNuJ3QgYXR0YWNoIHRvIGFuDQppbnRlcmZhY2Ug YXQgYWxsLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoN Ck1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1h aWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg0K --_000_0F43CDE921D24ED7AE7C9A2B9F854101ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <17E76190A474104E965EEEC2E35F3366@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFsbCwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFmdGVyIGEgc2VyaWVzIG9mIGRpc2N1c3Npb25z IG9uLSBhbmQgb2ZmLWxpc3QsIEkgaGF2ZSBhIGNhbmRpZGF0ZSBQUiB0aGF0IGluY2x1ZGVzIHRo ZSBjaGFuZ2VzIGluIHRoZSBQUiBNYWhlc2ggc2VudCBvdXQgcGx1cyBzb21lIG1vcmUgZWRpdHMu IFBsZWFzZSBzZWUgY29uc29saWRhdGVkIFBSIGhlcmU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMCAwIDAgNDBw eDsgYm9yZGVyOiBub25lOyBwYWRkaW5nOiAwcHg7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMSIg Y2xhc3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMTwv YT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5NYWluIGNoYW5nZXMgaW4gYWRkaXRpb24gdG8gTWFoZXNo4oCZcyBQ UiBhcmU6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjx1bCBjbGFz cz0iTWFpbE91dGxpbmUiPg0KPGxpIGNsYXNzPSIiPk1vdmVkIGludGVyZmFjZSBhdHRhY2htZW50 IHRvIGJlIHZpYSBhbiBpbnRlcmZhY2UgYXVnbWVudGF0aW9uLjwvbGk+PGxpIGNsYXNzPSIiPlJl c3RydWN0dXJlZCBwb3J0IG1hdGNoZXMgc2xpZ2h0bHkgdW5kZXIgYm90aCBJUHY0IGFuZCBJUHY2 IGNvbnRhaW5lcnMuPC9saT48bGkgY2xhc3M9IiI+UmVtb3ZlZCB1bm5lY2Vzc2FyeSBpZGVudGl0 eSAnaW50ZXJmYWNlLWFjbC1hZ2dyZWdhdGXigJkuPC9saT48bGkgY2xhc3M9IiI+UmVtb3ZlZCBh Y3Rpb24g4oCYaWNtcC1vZmbigJksIGNhbiBiZSBhdWdtZW50ZWQgbGF0ZXIuPC9saT48L3VsPg0K PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Gb3IgcmVmZXJlbmNlLCBo ZXJlIGlzIHRoZSBjdXJyZW50IFlBTkcgdHJlZSBwbHVzIOKAnC0taWV0ZuKAnSBsb2dzOjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNv dXJpZXIiIGNsYXNzPSIiPjEzOjEyICQgcHlhbmcgLS1pZXRmIC0tbGludCAtZiB0cmVlIGlldGYt YWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD b3VyaWVyIiBjbGFzcz0iIj5pZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZzo1MTogZXJyb3I6 IGJhZCB2YWx1ZSAmcXVvdDtZWVlZLU1NLUREJnF1b3Q7IChzaG91bGQgYmUgZGF0ZSk8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPm1vZHVsZTogaWV0Zi1h Y2Nlc3MtY29udHJvbC1saXN0PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVy IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2Nlc3MtbGlzdHM8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyYjNDM7LS1ydyBhY2wqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7c3RyaW5nPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgYWNsLXR5cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJiM0MzstLXJ3IGFjZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNv dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyYjNDM7LS1ydyBhY2UqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7c3RyaW5nPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVy IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBtYXRjaGVzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IChsMik/PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0t OihldGgpPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBldGgge21hdGNoLW9uLWV0aH0/PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgZGVzdGluYXRpb24tbWFjLWFkZHJlc3M/ ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3lhbmc6bWFjLWFkZHJlc3M8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcy1tYXNrPyAm bmJzcDsgeWFuZzptYWMtYWRkcmVzczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzst LXJ3IHNvdXJjZS1tYWMtYWRkcmVzcz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgeWFuZzptYWMtYWRkcmVzczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcy1tYXNrPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt5YW5nOm1hYy1hZGRyZXNzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVy IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncg ZXRoZXJ0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXRoOmV0aGVydHlwZTwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1ydyAobDMp PzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7JiM0MzstLTooaXB2NCk8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNv dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGlwdjQge21h dGNoLW9uLWlwdjR9PzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xh c3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBkc2NwPyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGluZXQ6ZHNjcDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i Q291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBlY24/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmIzQzOy0tcncgbGVuZ3RoPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDE2PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNw OyAmbmJzcDsgJiM0MzstLXJ3IHR0bD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50ODwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBwcm90b2NvbD8gJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJh dG9yKT88L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS06KHJhbmdlKTwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgc291cmNlLXBvcnQt bG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OnBvcnQtbnVtYmVy PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyYjNDM7LS1ydyBzb3VyY2Ut cG9ydC11cHBlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6cG9ydC1u dW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS06KG9wZXJhdG9yKTwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgc291cmNlLW9w ZXJhdG9yICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG9wZXJhdG9y PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBzb3VyY2Ut cG9ydCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGluZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgKGRl c3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7JiM0MzstLToocmFuZ2UpPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD b3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwOyYjNDM7LS1ydyBkZXN0aW5hdGlvbi1wb3J0LWxvd2VyICZuYnNwOyAmbmJzcDsgJm5i c3A7aW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJz cDsmIzQzOy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciAmbmJzcDsgJm5ic3A7ICZuYnNwO2lu ZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS06KG9w ZXJhdG9yKTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncg ZGVzdGluYXRpb24tb3BlcmF0b3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3BlcmF0b3I8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGRlc3RpbmF0 aW9uLXBvcnQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBv cnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGlobD8gJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291 cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBm bGFncz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JpdHM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tcncgb2Zmc2V0PyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDE2PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsg JiM0MzstLXJ3IGlkZW50aWZpY2F0aW9uPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIi IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZGVzdGlu YXRpb24taXB2NC1uZXR3b3JrPyAmbmJzcDsgaW5ldDppcHY0LXByZWZpeDwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBzb3VyY2UtaXB2NC1uZXR3b3JrPyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtpbmV0OmlwdjQtcHJlZml4PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihpcHY2KTwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tcncgaXB2NiB7bWF0Y2gtb24taXB2Nn0/PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmIzQzOy0tcncgZHNjcD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OmRzY3A8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBlY24/ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIi IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBs ZW5ndGg/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS1ydyB0dGw/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBwcm90b2NvbD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyAoc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0 b3IpPzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihyYW5nZSk8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgc291 cmNlLXBvcnQtbG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OnBv cnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0 MzstLXJ3IHNvdXJjZS1wb3J0LXVwcGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgaW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsm IzQzOy0tOihvcGVyYXRvcik8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIi IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmIzQzOy0tcncgc291cmNlLW9wZXJhdG9yICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IG9wZXJhdG9yPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJD b3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJiM0MzstLXJ3IHNvdXJjZS1wb3J0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IChkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9y LW9wZXJhdG9yKT88L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNz PSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7JiM0MzstLToo cmFuZ2UpPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0Mzst LXJ3IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBvcnQt bnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0Mzst LXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBvcnQt bnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyYjNDM7LS06KG9wZXJh dG9yKTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBkZXN0aW5hdGlvbi1vcGVyYXRvciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvcGVyYXRv cjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBk ZXN0aW5hdGlvbi1wb3J0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGRl c3RpbmF0aW9uLWlwdjYtbmV0d29yaz8gJm5ic3A7IGluZXQ6aXB2Ni1wcmVmaXg8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBzb3VyY2UtaXB2Ni1uZXR3b3JrPyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OmlwdjYtcHJlZml4PC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0tcncgZmxvdy1sYWJlbD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OmlwdjYtZmxvdy1sYWJlbDwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1y dyAobDQpPzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwO3wgJm5ic3A7JiM0MzstLToodGNwKTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgdGNw IHttYXRjaC1vbi10Y3B9PzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBzZXF1ZW5j ZS1udW1iZXI/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50MzI8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNrbm93bGVkZ2VtZW50LW51bWJlcj8gJm5ic3A7 IHVpbnQzMjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBkYXRhLW9mZnNldD8gJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgcmVzZXJ2ZWQ/ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tcncgZmxhZ3M/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JpdHM8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tcncgd2luZG93LXNpemU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VpbnQxNjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyB1cmdlbnQtcG9pbnRlcj8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1 aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgb3B0aW9ucz8gJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50 MzI8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDt8ICZuYnNwOyYjNDM7LS06KHVkcCk8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNv dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IHVkcCB7bWF0 Y2gtb24tdWRwfT88L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNz PSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbGVuZ3RoPyAmbmJz cDsgdWludDE2PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihpY21wKTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncg aWNtcCB7bWF0Y2gtb24taWNtcH0/PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3Vy aWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0t cncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBjb2RlPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50ODwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JiM0MzstLXJ3IHJlc3Qtb2YtaGVhZGVyPyAmbmJzcDsgdWludDMyPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGVn cmVzcy1pbnRlcmZhY2U/ICZuYnNwOyAmbmJzcDtpZjppbnRlcmZhY2UtcmVmPC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGlu Z3Jlc3MtaW50ZXJmYWNlPyAmbmJzcDsgaWY6aW50ZXJmYWNlLXJlZjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWN0aW9uczwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1y dyBmb3J3YXJkaW5nICZuYnNwOyAmbmJzcDtpZGVudGl0eXJlZjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1ydyBsb2dnaW5nPyAm bmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aXR5cmVmPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBzdGF0aXN0aWNzIHthY2wtYWdncmVnYXRl LXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LS1ybyBtYXRjaGVkLXBhY2tldHM/ICZuYnNwOyB5YW5nOmNvdW50 ZXI2NDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3Vu dGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xh c3M9IiI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAm IzQzOy0tcncgYWNsczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xh c3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGluZ3Jlc3M8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxp c3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVd IHtpbnRlcmZhY2Utc3RhdHN9PzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2Fj ZS9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0 MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBlZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVy IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR5 cGU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nl c3MtbGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIi IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0 c30/PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZTwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+Q29tbWVudHMg d2VsY29tZSE8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj5D aGVlcnMsPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5FaW5hcjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDE0IERlYyAyMDE3LCBhdCAxODo1MCwg RWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pICZsdDs8YSBocmVmPSJtYWlsdG86ZWluYXJu bkBjaXNjby5jb20iIGNsYXNzPSIiPmVpbmFybm5AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTQgRGVjIDIwMTcsIGF0IDA4OjIxLCBT b25hbCBBZ2Fyd2FsICZsdDs8YSBocmVmPSJtYWlsdG86c2FnYXJ3YWwxMkBnbWFpbC5jb20iIGNs YXNzPSIiPnNhZ2Fyd2FsMTJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGly PSJsdHIiIGNsYXNzPSIiPkhpIEVpbmFyLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WW91IGhhZCAzIHF1ZXN0aW9ucyBmb3IgbWUgb24gYWxsIHRo ZSBzZXZlcmFsIGUtbWFpbCB0aHJlYWRzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLiBH bG9iYWwgYXR0YWNobWVudCBwb2ludDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4yLiBpY21wLW9mZjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4zLiBhY2wtYWdncmVnYXRlLWludGVyZmFjZSBzdGF0cy48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZv ciAoMSksIG15IGZpcnN0IHByZWZlcmVuY2UgaXMgdG8gaGF2ZSB0aGUgbW9kZWwgZGVmaW5lIGF0 dGFjaG1lbnQgcG9pbnQgZm9yIGludGVyZmFjZXMgb25seS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5laW5hcm5uJmd0OyBJIGhhdmUgc29tZSBkaWZmcywgbGF5ZXJlZCBvbiB0b3Ag b2YgTWFoZXNo4oCZcyBQUiB0byBuZXRtb2Qtd2cvYWNsLW1vZGVsIHRoYXQgZG8gdGhpcy4gTmVh cmx5IGxpa2UgdGhlIGF1Z21lbnRhdGlvbiBJIGhhdmUgYmVsb3cuIEZlZWwgZnJlZSB0byB0YWtl IGEgbG9vayBhdDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9u ZTsgcGFkZGluZzogMHB4OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL21qZXRoYW5hbmRh bmkvYWNsLW1vZGVsL3B1bGwvMyIgY2xhc3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL21qZXRoYW5h bmRhbmkvYWNsLW1vZGVsL3B1bGwvMzwvYT48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5Ib3dldmVyLCBLcmlzdGlhbiB3YW50cyB0aGUgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQg YXMgd2VsbCBzbyB0aGF0IGhlIGNhbiBhZGQgdGhlIEFDTCB0byB0aGUgbGludXggdGFibGVzLjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmVpbmFybm4mZ3Q7IEkgdGhpbmsgS3Jpc3Rp YW4gZG9lc27igJl0IGZlZWwgYSBnbG9iYWwgYXR0YWNobWVudCBwb2ludCBuZWVkcyB0byBiZSBp biB0aGlzIGZpcnN0IHJldmlzaW9uLiBCdXQgaGUgY2FuIGNvbmZpcm0uPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SWYgYW4gQUNMIGlzIGF0 dGFjaGVkIGdsb2JhbGx5LCBkb2VzIHRoaXMgbWVhbiBpdCBpcyBwZXIgZGlyZWN0aW9uIG9yIGRv ZXMgaXQgbWVhbiBpdCBpcyBhY3Jvc3MgZGlyZWN0aW9ucz88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5laW5hcm5uJmd0OyBJIGRvbuKAmXQga25vdyByaWdodCBub3cgOi0pPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBn bG9iYWwgQUNMIG1heSBub3QgYmUgYXBwbGljYWJsZSB0byBhbnkgb2YgQ2lzY28ncyBzZXJ2aWNl IHByb3ZpZGVyIHJvdXRlcnMgYXMgSSBkb24ndCBzZWUgYW55IHBsYXRmb3JtIGFjdHVhbGx5IHJl cGxpY2F0aW5nIHRoZSBBQ0wgdG8gYWxsIGxpbmUgY2FyZHMgYW5kIGF0dGFjaGluZyBpdCBpbiBp bmdyZXNzIGFuZCBlZ3Jlc3MgZGlyZWN0aW9ucyBhY3Jvc3MgYWxsIGludGVyZmFjZXMuPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZWluYXJubiZndDsgUGVyIG90aGVyIGVtYWlscywg SSBkb27igJl0IHRoaW5rIHdlIHVuZGVyc3RhbmQgdGhpcyBlbm91Z2ggeWV0IHRvIHNwZWNpZnkg aXQsIHNvIEkgc3VnZ2VzdCB3ZSBqdXN0IGxlYXZlIGl0IG91dCBmb3Igbm93LiBOb3RoaW5nIGlu IHRoZSBtb2RlbCBwcmV2ZW50cyBhIOKAnGdsb2JhbCBhdHRhY2htZW50IHBvaW504oCdIGJlaW5n IGFkZGVkIGxhdGVyIG9uY2Ugd2UgdW5kZXJzdGFuZCB3aGF0IGl0IHJlYWxseSBtZWFucy48L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Gb3Ig KDIpLCBJIGFtIG9rIHdpdGggcmVtb3ZpbmcgaWNtcC1vZmYuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+ZWluYXJubiZndDsgRG9uZSBpbiBteSBQUiBhYm92ZS48L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Gb3IgKDMpLCB0aGlz IHdvdWxkIGhhdmUgdG8gYmUgYSBjb21iaW5hdGlvbiBvZiBBQ0wgc3RhdHMgYWNyb3NzIGFsbCBp bnRlcmZhY2VzIGZvciBhbGwgQUNMJ3MuIFNvbWV0aGluZyBsaWtlIHRoaXMgaXMgcG9zc2libGUg b24gYW4gWFIgYm94IHdoZXJlIEFDRVMgaGF2ZSBjb3VudGVyIG5hbWVzIGFzc29jaWF0ZWQgd2l0 aCBpdC4gTGV0J3MgY2hhdCBhYm91dCB0aGlzIG9mZmxpbmUgdG9tb3Jyb3cuPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZWluYXJubiZndDsgSeKAmWxsIHBpbmcgeW91IHRvIGNsYXJp ZnksIGFuZCB3ZSBjYW4gYnJpbmcgYW55IGNvbmNsdXNpb24gYmFjayB0byB0aGUgbGlzdC48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Tb25h bC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gV2VkLCBEZWMgMTMsIDIwMTcgYXQgMTI6MTAgUE0sIE1haGVzaCBKZXRoYW5hbmRh bmkgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFu YW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiIGNsYXNzPSIiPldlIHdhbnQgdG8gc3VwcG9ydCDigJxnbG9iYWzigJ0gYXR0 YWNobWVudCBwb2ludCBkb3duIHRoZSBsaW5lLCBhbmQgdGhhdCDigJxnbG9iYWzigJ0gYXR0YWNo bWVudCBwb2ludCB3aWxsIGJlIG9uZSBvZiB0aGUgY2hvaWNlcyAodGhlIG90aGVyIGJlaW5nIHRo ZSBpbnRlcmZhY2UpLCB3aGF0IHdvdWxkIHRoaXMgYXVnbWVudCBsb29rIGxpa2UuIE5vdGUsIGFz IGZhciBhcyBJIGtub3csDQogeW91IGNhbm5vdCBhdWdtZW50IGluc2lkZSBhIGNob2ljZSBub2Rl Lg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMgMTMsIDIwMTcsIGF0IDY6NTcgQU0sIEVpbmFyIE5pbHNl bi1OeWdhYXJkIChlaW5hcm5uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVpbmFybm5AY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ZWluYXJubkBjaXNjby5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0ibV83MTAyNDA4OTA3NTMzMDE3NTAxQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQ7bGluZS1icmVhazphZnRlci13aGl0ZS1zcGFjZSIgY2xhc3M9IiI+UGVyaGFwcyBsaWtl IHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUgaW50ZXJmYWNlOg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAg NDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgYXVnbWVu dCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m bmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBpbmdyZXNzLWFjbHM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNz PSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsmIzQzOy0tcncgYWNsLXNldHM8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJp ZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wt c2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1l PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJ3IHR5cGU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIi IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz Oy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNv dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS88d2JyIGNs YXNzPSIiPm5hbWU8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgfCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLXBhY2tldHM/ ICZuYnNwOyB5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNo ZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNs YXNzPSIiPiZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGVncmVzcy1hY2xzPC9mb250PjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVy IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldHM8 L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5h bWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZndDsg L2FjY2Vzcy1saXN0cy9hY2wvbmFtZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHR5cGU/ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlz dHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ybyBhY2Utc3RhdGlzdGljcyogW25h bWVdIHtpbnRlcmZhY2Utc3RhdHN9PzwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8g bmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZn dDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvPHdiciBjbGFzcz0iIj5uYW1lPC9mb250Pjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJD b3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBtYXRjaGVkLXBhY2tldHM/ICZuYnNwOyB5YW5nOmNv dW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Q291bGQgYWxzbyBwdXQgYW4g4oCcYWNlc+KAnSBjb250YWluZXIgYWJvdmUgYm90aCB0aGVz ZSAmYW1wOyByZW5hbWUg4oCcaW5ncmVzcy1hY2xzJnF1b3Q7IHRvIOKAnGluZ3Jlc3PigJ0sIGV0 Yy4gdG8gZ2l2ZSBhIHNpbmdsZSByb290IGZvciB0aGUgYXVnbWVudGF0aW9uIGlmIHByZWZlcnJl ZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDYgRGVjIDIwMTcs IGF0IDE5OjQzLCBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5sZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGJyIGNsYXNzPSJtXzcxMDI0MDg5MDc1MzMwMTc1MDFBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCk9uIDEyLzYvMTcgNzoyMyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90 ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Ib3cgZG9l cyBvbmUgbW92ZSB0aGUgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsIGN1cnJlbnRseSBhbjxi ciBjbGFzcz0iIj4NCidpbnRlcmZhY2UtcmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZSBp ZjppbnRlcmZhY2VzL2ludGVyZmFjZSw8YnIgY2xhc3M9IiI+DQppbnNpZGUgb2YgdGhlIOKAmGFj bOKAmSAmbmJzcDtjb250YWluZXI/IERvd24gdGhlIGxpbmUgd2UgbWlnaHQgbmVlZCB0byBoYXZl IGFuPGJyIGNsYXNzPSIiPg0KY29udGFpbmVyIGZvciAmcXVvdDthdHRhY2htZW50IHBvaW50cyZx dW90OyB0byBhY2NvbW1vZGF0ZSB0aGUgcG9zc2liaWxpdHkgb2Y8YnIgY2xhc3M9IiI+DQphdHRh Y2hpbmcgYW4gQUNMIGVpdGhlciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0K S2VlcGluZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFj aCB0byBhbjxiciBjbGFzcz0iIj4NCmludGVyZmFjZSBhdCBhbGwuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyIGNsYXNzPSIiPmxpc3Rp bmZvL25ldG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBjbGFz cz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5NYWhlc2ggSmV0aGFuYW5kYW5pPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX188d2JyIGNsYXNzPSIiPl9fX19fX19fX19fX19f X19fPGJyIGNsYXNzPSIiPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiPm5ldG1vZEBpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyIGNsYXNzPSIiPmxpc3RpbmZvL25ldG1vZDwv YT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgY2xhc3M9IiI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0F43CDE921D24ED7AE7C9A2B9F854101ciscocom_-- From nobody Sat Dec 16 08:15:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F54E1276AF for ; Sat, 16 Dec 2017 08:15:38 -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 R11Onq4k1mX6 for ; Sat, 16 Dec 2017 08:15:36 -0800 (PST) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 2F608127078 for ; Sat, 16 Dec 2017 08:15:36 -0800 (PST) Received: by mail-wr0-x244.google.com with SMTP id y21so10506815wrc.1 for ; Sat, 16 Dec 2017 08:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=z7VHKaJXH0ypO77KaWhozrdX82XHKr3+cmDKDhKipNs=; b=asQ2jLki6VJGbJpzH3d9oFMK7cgLc4TBs0OPMGUsUob8jUCzC0XH8+p9mQEN7oVAmN 0293fJwaRAV4e50BKPZ7KeKZb/vyvV9fJQxI9Twa9nljeMJtChn3hzjINRHSgWOgtGZr m2JeydzssULRdX/MeroSAHMP7kHQerO6o0bhwv/jZoMX1OhPBaInttgrdIFLSWR91qtB I6bJfo3t6pStWbUx+PNyjzRsQwppfel3PYC/+053t6hz8OCpGORlVk8sGFe0GVJ7+as2 r/4EzxLbI8yrspX8zpIzZeS/HvV3dlw4DKl7LsHs+W566wxuxmQwIX0fB8x6A7Cn7qV6 BjHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=z7VHKaJXH0ypO77KaWhozrdX82XHKr3+cmDKDhKipNs=; b=WRlSdcaBI1lXjOGnlrq+oVSh+uw+DhY03hbMYZ+Up36Bx+tD2XuP7US7/qcVtEgemZ Q4Bf1KYhimokI73OI/DpmBYYmkkhakmLbTTngBCqcAGOGC5MTldn8WyYyCxinLw914Xf 8oEPAyz2azbXBY50UZjJY67B3KGua9GNAgOvWQUzkGlhQKMpOxciZray/sgcjPQvzopP 8oQJZGDPX7MuNMiPqxIfJr75YqWyZq1dYVzwlpPTw1uc73O2ULfzUYqNzSAQzPMolXLh UhtMikLjZdEY3MZ5SRJoaxg88x3iYwA5R/zlrDTsNpmQ/Q+gwioJBupoZ79DD9JLLDfg FsLg== X-Gm-Message-State: AKGB3mJ0V8hsyXXUww9foenKp3gQvvQA0hk8PeNrNDSMOtJHhL+MqsmK IbiiQblQhLJ7uuTQCkjC3gs= X-Google-Smtp-Source: ACJfBouwH0br1yteBbWIlKybXk40QkS+ERpqNGqm33HinPr1QoEwI1kV5e9twsDbjpHNeKElz2uWHQ== X-Received: by 10.223.200.138 with SMTP id k10mr12125169wrh.222.1513440934584; Sat, 16 Dec 2017 08:15:34 -0800 (PST) Received: from DESKTOPFLHJVQJ ([2001:16b8:2dd0:7100:1d7e:672b:4a5e:8f5b]) by smtp.gmail.com with ESMTPSA id e40sm22518853wre.6.2017.12.16.08.15.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Dec 2017 08:15:33 -0800 (PST) From: "Mehmet Ersue" To: "'Mahesh Jethanandani'" , "'Joel jaeggli'" Cc: "'NETMOD Working Group'" References: <1152A14B-B19C-4411-87A0-879AFE60CAD7@gmail.com> In-Reply-To: <1152A14B-B19C-4411-87A0-879AFE60CAD7@gmail.com> Date: Sat, 16 Dec 2017 17:15:33 +0100 Message-ID: <003801d37689$1a1f6aa0$4e5e3fe0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: de Thread-Index: AQIGgCDNaVhFeVYjvu0A7YA9MZi5oAL7qOSxosg0mdA= Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Dec 2017 16:15:39 -0000 +1 Mehmet > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh > Jethanandani > Sent: Saturday, December 16, 2017 6:49 AM > To: Joel jaeggli > Cc: NETMOD Working Group > Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair > > Joel, > > Welcome. Look forward to the interaction with NETCONF. > > Cheers. > > > On Dec 15, 2017, at 9:21 AM, Benoit Claise wrote: > > > > Dear all, > > > > A lot is happening these days in the world of data modeling-driven > management at the IETF: > > NMDA architecture, NETCONF, RESTCONF > > NMDA-compliant YANG modules: some RFC bis modules but also new > ones > > Guidelines: RFC6087bis and the tree diagram > > The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, > telemetry > > The interaction with routing, where many YANG modules come from. > > etc. > > There are a lot of dependencies between all these tasks, which must take > place in parallel, and, obviously, be completed ASAP. > > > > Kent and Lou have a lot on their shoulders these days. > > To help with the situation and proactively progress documents, I'm happy > to announce that Joel Jaeggli accepted to serve as a third NETMOD co-chair. > Thank you Joel. > > > > Please welcome Joel. > > > > Regards, Benoit > > > > _______________________________________________ > > 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 Sun Dec 17 01:41:09 2017 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 AAED3124B09; Sun, 17 Dec 2017 01:41:03 -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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151350366366.6834.11745943206659790943@ietfa.amsl.com> Date: Sun, 17 Dec 2017 01:41:03 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-01.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, 17 Dec 2017 09:41: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 Interface Management Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc7223bis-01.txt Pages : 47 Date : 2017-12-17 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-01 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 Dec 17 01:41:53 2017 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 061E2124B09; Sun, 17 Dec 2017 01:41:52 -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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151350371198.6933.15197989796381747109@ietfa.amsl.com> Date: Sun, 17 Dec 2017 01:41:52 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7277bis-01.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, 17 Dec 2017 09:41: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 IP Management Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc7277bis-01.txt Pages : 32 Date : 2017-12-17 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7277bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-01 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 Dec 17 01:46:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621F81287A5 for ; Sun, 17 Dec 2017 01:46:17 -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 W9WMxpSCM6_E for ; Sun, 17 Dec 2017 01:46:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7FD128799 for ; Sun, 17 Dec 2017 01:46: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 531471AE02BD for ; Sun, 17 Dec 2017 10:46:14 +0100 (CET) Date: Sun, 17 Dec 2017 10:46:13 +0100 (CET) Message-Id: <20171217.104613.1471554589063021632.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151350366366.6834.11745943206659790943@ietfa.amsl.com> References: <151350366366.6834.11745943206659790943@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] I-D Action: draft-ietf-netmod-rfc7223bis-01.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, 17 Dec 2017 09:46:17 -0000 Hi, This version addresses the WGLC comments received. I have also added a reference to the tree diagram draft. /martin 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 Interface Management > Author : Martin Bjorklund > Filename : draft-ietf-netmod-rfc7223bis-01.txt > Pages : 47 > Date : 2017-12-17 > > 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-01 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-01 > > > 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 > From nobody Sun Dec 17 01:46:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495E4128799 for ; Sun, 17 Dec 2017 01:46:38 -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 av1lrQLyIetv for ; Sun, 17 Dec 2017 01:46: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 D4AB5124B09 for ; Sun, 17 Dec 2017 01:46:36 -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 2959A1AE02BD for ; Sun, 17 Dec 2017 10:46:36 +0100 (CET) Date: Sun, 17 Dec 2017 10:46:36 +0100 (CET) Message-Id: <20171217.104636.2275583743710846755.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151350371198.6933.15197989796381747109@ietfa.amsl.com> References: <151350371198.6933.15197989796381747109@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] I-D Action: draft-ietf-netmod-rfc7277bis-01.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, 17 Dec 2017 09:46:38 -0000 Hi, This version addresses the WGLC comments received. I have also added a reference to the tree diagram draft. /martin 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 IP Management > Author : Martin Bjorklund > Filename : draft-ietf-netmod-rfc7277bis-01.txt > Pages : 32 > Date : 2017-12-17 > > 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-01 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7277bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-01 > > > 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 > From nobody Sun Dec 17 03:30:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D13127201 for ; Sun, 17 Dec 2017 03:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 w1WmBTunoruj for ; Sun, 17 Dec 2017 03:29:56 -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 2A1161205F1 for ; Sun, 17 Dec 2017 03:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85595; q=dns/txt; s=iport; t=1513510195; x=1514719795; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=hXfL8NaLqwg1PUTizflTifT3QsURpdrs6AJP5w0faso=; b=kPOlCheJv0hebSeQ9O6qiZv85N+/PWGhrJ3Ai3aj/l2AQaqbQHZsbAnp KNhlGIa3EExZ1Yi8H5E4F0pbfx/w4rlXeO/U1VPeKn3VvdZHaomzbeg3K kW/ko1E/5rIZNtfNZh/bS60NICNVSRFIJ2QM/9XlBkmSEjQ5SxAUCP3LO I=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.45,415,1508803200"; d="asc'?scan'208,217";a="918512" 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; 17 Dec 2017 11:29:53 +0000 Received: from [10.61.192.142] ([10.61.192.142]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBHBTqO7003032; Sun, 17 Dec 2017 11:29:52 GMT To: "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" Cc: Kristian Larsson 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> From: Eliot Lear Message-ID: Date: Sun, 17 Dec 2017 12:29:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OLdtCDr3jonlxmmpvmd00iJBkLCt3MeUp" 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: Sun, 17 Dec 2017 11:29:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OLdtCDr3jonlxmmpvmd00iJBkLCt3MeUp Content-Type: multipart/mixed; boundary="0pDQurFe5Cb4lpFQsVndMJ2Fr7aEmfJOb"; protected-headers="v1" From: Eliot Lear To: "Einar Nilsen-Nygaard (einarnn)" , "netmod@ietf.org" Cc: Kristian Larsson 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> In-Reply-To: <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> --0pDQurFe5Cb4lpFQsVndMJ2Fr7aEmfJOb Content-Type: multipart/alternative; boundary="------------1186BCA1D7BD4BF754BCA652" Content-Language: en-US This is a multi-part message in MIME format. --------------1186BCA1D7BD4BF754BCA652 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RWluYXIsCgpJIHRoaW5rIHRoaXMgY2hhbmdlIGlzIGZpbmUsIHdpdGggb25lIGV4Y2VwdGlv bi7CoCBJIHdvdWxkIHJhdGhlciB0aGUKYXVnbWVudCB0byB0aGUgaW50ZXJmYWNlIG5vdCBi ZSByZXF1aXJlZCBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3QKYWN0dWFsbHkgaGF2 ZSBpbnRlcmZhY2VzLsKgIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIG1heSBiZSB0d28gd2F5 cyB0byBnbwphYm91dCB0aGlzOgoKIDEuIFNlcGFyYXRlIG91dCB0aGUgYXVnbWVudCBpbnRv IGEgc2VwYXJhdGUgbW9kdWxlIChzYW1lIGRvYyBpcyBmaW5lKTsgb3IKIDIuIFNvbWVob3cg ImZlYXR1cmUtaXplIiB0aGUgYXVnbWVudC4KCkkgZG9uJ3Qga25vdyBob3cgdG8gZG8gKDIp IGJ1dCBpZiB5b3UgZG8sIHRoYXQncyBva2F5IGJ5IG1lLgoKRWxpb3QKCgpPbiAxNi4xMi4x NyAxNDoxOSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOgo+IEFsbCwK Pgo+IEFmdGVyIGEgc2VyaWVzIG9mIGRpc2N1c3Npb25zIG9uLSBhbmQgb2ZmLWxpc3QsIEkg aGF2ZSBhIGNhbmRpZGF0ZSBQUgo+IHRoYXQgaW5jbHVkZXMgdGhlIGNoYW5nZXMgaW4gdGhl IFBSIE1haGVzaCBzZW50IG91dCBwbHVzIHNvbWUgbW9yZQo+IGVkaXRzLiBQbGVhc2Ugc2Vl IGNvbnNvbGlkYXRlZCBQUiBoZXJlOgo+Cj4gICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRt b2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjEKPgo+Cj4gTWFpbiBjaGFuZ2VzIGluIGFkZGl0aW9u IHRvIE1haGVzaOKAmXMgUFIgYXJlOgo+Cj4gICAqIE1vdmVkIGludGVyZmFjZSBhdHRhY2ht ZW50IHRvIGJlIHZpYSBhbiBpbnRlcmZhY2UgYXVnbWVudGF0aW9uLgo+ICAgKiBSZXN0cnVj dHVyZWQgcG9ydCBtYXRjaGVzIHNsaWdodGx5IHVuZGVyIGJvdGggSVB2NCBhbmQgSVB2Ngo+ ICAgICBjb250YWluZXJzLgo+ICAgKiBSZW1vdmVkIHVubmVjZXNzYXJ5IGlkZW50aXR5ICdp bnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZeKAmS4KPiAgICogUmVtb3ZlZCBhY3Rpb24g4oCYaWNt cC1vZmbigJksIGNhbiBiZSBhdWdtZW50ZWQgbGF0ZXIuCj4KPgo+IEZvciByZWZlcmVuY2Us IGhlcmUgaXMgdGhlIGN1cnJlbnQgWUFORyB0cmVlIHBsdXMg4oCcLS1pZXRm4oCdIGxvZ3M6 Cj4KPiAxMzoxMiAkIHB5YW5nIC0taWV0ZiAtLWxpbnQgLWYgdHJlZSBpZXRmLWFjY2Vzcy1j b250cm9sLWxpc3QueWFuZwo+IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nOjUxOiBl cnJvcjogYmFkIHZhbHVlICJZWVlZLU1NLUREIgo+IChzaG91bGQgYmUgZGF0ZSkKPiBtb2R1 bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdAo+IMKgIMKgICstLXJ3IGFjY2Vzcy1saXN0 cwo+IMKgIMKgIMKgIMKgKy0tcncgYWNsKiBbbmFtZV0KPiDCoCDCoCDCoCDCoCDCoCArLS1y dyBuYW1lIMKgIMKgc3RyaW5nCj4gwqAgwqAgwqAgwqAgwqAgKy0tcncgdHlwZT8gwqAgYWNs LXR5cGUKPiDCoCDCoCDCoCDCoCDCoCArLS1ydyBhY2VzCj4gwqAgwqAgwqAgwqAgwqAgwqAg wqArLS1ydyBhY2UqIFtuYW1lXQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IG5h bWUgwqAgwqAgwqAgwqAgwqBzdHJpbmcKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1y dyBtYXRjaGVzCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCstLXJ3IChsMik/Cj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqArLS06KGV0aCkKPiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCArLS1ydyBldGgge21hdGNoLW9uLWV0aH0/Cj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBkZXN0aW5h dGlvbi1tYWMtYWRkcmVzcz8gwqAgwqAgwqAKPiDCoHlhbmc6bWFjLWFkZHJlc3MKPiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGRlc3RpbmF0aW9u LW1hYy1hZGRyZXNzLW1hc2s/IMKgCj4geWFuZzptYWMtYWRkcmVzcwo+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgc291cmNlLW1hYy1hZGRyZXNz PyDCoCDCoCDCoCDCoCDCoCDCoAo+IHlhbmc6bWFjLWFkZHJlc3MKPiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcy1t YXNrPyDCoCDCoCDCoAo+IMKgeWFuZzptYWMtYWRkcmVzcwo+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgZXRoZXJ0eXBlPyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoAo+IMKgZXRoOmV0aGVydHlwZQo+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqArLS1ydyAobDMpPwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgKy0tOihpcHY0KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCst LXJ3IGlwdjQge21hdGNoLW9uLWlwdjR9Pwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqB8IMKgfCDCoCDCoCArLS1ydyBkc2NwPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBpbmV0OmRzY3AKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAg wqAgKy0tcncgZWNuPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVpbnQ4 Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IGxlbmd0 aD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWludDE2Cj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IHR0bD8gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqB8IMKgfCDCoCDCoCArLS1ydyBwcm90b2NvbD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgdWludDgKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0t cncgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8KPiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoCstLToocmFuZ2UpCj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqB8IMKgKy0tcncgc291cmNlLXBvcnQt bG93ZXIgwqAgwqAgwqAgwqAgwqAKPiBpbmV0OnBvcnQtbnVtYmVyCj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqB8IMKgKy0tcncgc291cmNlLXBvcnQt dXBwZXIgwqAgwqAgwqAgwqAgwqAKPiBpbmV0OnBvcnQtbnVtYmVyCj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqArLS06KG9wZXJhdG9yKQo+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgIMKgICstLXJ3IHNvdXJj ZS1vcGVyYXRvciDCoCDCoCDCoCDCoCDCoCDCoAo+IG9wZXJhdG9yCj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqAgwqAgKy0tcncgc291cmNlLXBvcnQg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAKPiBpbmV0OnBvcnQtbnVtYmVyCj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IChkZXN0aW5hdGlvbi1wb3J0 LXJhbmdlLW9yLW9wZXJhdG9yKT8KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oHwgwqAgwqAgfCDCoCstLToocmFuZ2UpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oHwgwqB8IMKgIMKgIHwgwqB8IMKgKy0tcncgZGVzdGluYXRpb24tcG9ydC1sb3dlciDCoCDC oAo+IMKgaW5ldDpwb3J0LW51bWJlcgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgfCDCoCDCoCB8IMKgfCDCoCstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIgwqAgwqAK PiDCoGluZXQ6cG9ydC1udW1iZXIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oHwgwqAgwqAgfCDCoCstLToob3BlcmF0b3IpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgIHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24tb3BlcmF0b3IgwqAg wqAgwqAKPiDCoG9wZXJhdG9yCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8 IMKgIMKgIHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24tcG9ydCDCoCDCoCDCoCDCoCDCoAo+ IMKgaW5ldDpwb3J0LW51bWJlcgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKg fCDCoCDCoCArLS1ydyBpaGw/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg dWludDgKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncg ZmxhZ3M/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYml0cwo+IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBvZmZzZXQ/IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQxNgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqB8IMKgfCDCoCDCoCArLS1ydyBpZGVudGlmaWNhdGlvbj8gwqAgwqAgwqAgwqAgwqAg wqAgdWludDE2Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICst LXJ3IGRlc3RpbmF0aW9uLWlwdjQtbmV0d29yaz8gwqAKPiBpbmV0OmlwdjQtcHJlZml4Cj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IHNvdXJjZS1p cHY0LW5ldHdvcms/IMKgIMKgIMKgCj4gwqBpbmV0OmlwdjQtcHJlZml4Cj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCDCoHwgwqArLS06KGlwdjYpCj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqAgwqAgKy0tcncgaXB2NiB7bWF0Y2gtb24taXB2Nn0/Cj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBkc2NwPyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbmV0OmRzY3AKPiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGVjbj8gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgIMKgIMKgIMKgKy0tcncgbGVuZ3RoPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB1aW50MTYKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCst LXJ3IHR0bD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgcHJvdG9jb2w/ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4Cj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyAoc291cmNlLXBvcnQtcmFuZ2Utb3Itb3Bl cmF0b3IpPwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDC oCstLToocmFuZ2UpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAg wqB8IMKgfCDCoCstLXJ3IHNvdXJjZS1wb3J0LWxvd2VyIMKgIMKgIMKgIMKgIMKgCj4gaW5l dDpwb3J0LW51bWJlcgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKg IMKgfCDCoHwgwqArLS1ydyBzb3VyY2UtcG9ydC11cHBlciDCoCDCoCDCoCDCoCDCoAo+IGlu ZXQ6cG9ydC1udW1iZXIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDC oCDCoHwgwqArLS06KG9wZXJhdG9yKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgIMKgIMKgIMKgfCDCoCDCoCArLS1ydyBzb3VyY2Utb3BlcmF0b3IgwqAgwqAgwqAgwqAg wqAgwqAKPiBvcGVyYXRvcgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKg IMKgIMKgfCDCoCDCoCArLS1ydyBzb3VyY2UtcG9ydCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oAo+IGluZXQ6cG9ydC1udW1iZXIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDC oCDCoCDCoCDCoCstLXJ3IChkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8K PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqArLS06KHJh bmdlKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoHwg wqArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LWxvd2VyIMKgIMKgCj4gwqBpbmV0OnBvcnQtbnVt YmVyCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgfCDC oCstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIgwqAgwqAKPiDCoGluZXQ6cG9ydC1udW1i ZXIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqArLS06 KG9wZXJhdG9yKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKg fCDCoCDCoCArLS1ydyBkZXN0aW5hdGlvbi1vcGVyYXRvciDCoCDCoCDCoAo+IMKgb3BlcmF0 b3IKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqAgwqAg Ky0tcncgZGVzdGluYXRpb24tcG9ydCDCoCDCoCDCoCDCoCDCoAo+IMKgaW5ldDpwb3J0LW51 bWJlcgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncg ZGVzdGluYXRpb24taXB2Ni1uZXR3b3JrPyDCoAo+IGluZXQ6aXB2Ni1wcmVmaXgKPiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IHNvdXJjZS1pcHY2 LW5ldHdvcms/IMKgIMKgIMKgCj4gwqBpbmV0OmlwdjYtcHJlZml4Cj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBmbG93LWxhYmVsPyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoAo+IGluZXQ6aXB2Ni1mbG93LWxhYmVsCj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoCstLXJ3IChsNCk/Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqArLS06KHRjcCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwg wqArLS1ydyB0Y3Age21hdGNoLW9uLXRjcH0/Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgICstLXJ3IHNlcXVlbmNlLW51bWJlcj8gwqAgwqAgwqAgwqAgwqB1 aW50MzIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncg YWNrbm93bGVkZ2VtZW50LW51bWJlcj8gwqAgdWludDMyCj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IGRhdGEtb2Zmc2V0PyDCoCDCoCDCoCDCoCDC oCDCoCDCoHVpbnQ4Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKg ICstLXJ3IHJlc2VydmVkPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1aW50OAo+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBmbGFncz8gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBiaXRzCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgICstLXJ3IHdpbmRvdy1zaXplPyDCoCDCoCDCoCDCoCDCoCDCoCDC oHVpbnQxNgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1y dyB1cmdlbnQtcG9pbnRlcj8gwqAgwqAgwqAgwqAgwqAgdWludDE2Cj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IG9wdGlvbnM/IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgdWludDMyCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwg wqArLS06KHVkcCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqArLS1y dyB1ZHAge21hdGNoLW9uLXVkcH0/Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwg wqB8IMKgIMKgICstLXJ3IGxlbmd0aD8gwqAgdWludDE2Cj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqArLS06KGljbXApCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oHwgwqAgwqAgKy0tcncgaWNtcCB7bWF0Y2gtb24taWNtcH0/Cj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyB0eXBlPyDCoCDCoCDCoCDCoCDCoCDC oCB1aW50OAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0t cncgY29kZT8gwqAgwqAgwqAgwqAgwqAgwqAgdWludDgKPiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IHJlc3Qtb2YtaGVhZGVyPyDCoCB1aW50MzIK PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgKy0tcncgZWdyZXNzLWludGVyZmFjZT8g wqAgwqBpZjppbnRlcmZhY2UtcmVmCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCst LXJ3IGluZ3Jlc3MtaW50ZXJmYWNlPyDCoCBpZjppbnRlcmZhY2UtcmVmCj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgKy0tcncgYWN0aW9ucwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqArLS1ydyBmb3J3YXJkaW5nIMKgIMKgaWRlbnRpdHlyZWYKPiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgKy0tcncgbG9nZ2luZz8gwqAgwqAgwqBpZGVudGl0eXJlZgo+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJvIHN0YXRpc3RpY3Mge2FjbC1hZ2dyZWdhdGUt c3RhdHN9Pwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8gbWF0Y2hlZC1w YWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2NAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgKy0tcm8gbWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPgo+IMKgIGF1 Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOgo+IMKgIMKgICstLXJ3IGFjbHMK PiDCoCDCoCDCoCDCoCstLXJ3IGluZ3Jlc3MKPiDCoCDCoCDCoCDCoHwgwqArLS1ydyBhY2wt c2V0cwo+IMKgIMKgIMKgIMKgfCDCoCDCoCArLS1ydyBhY2wtc2V0KiBbbmFtZV0KPiDCoCDC oCDCoCDCoHwgwqAgwqAgwqAgwqArLS1ydyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgLT4g L2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJ3 IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUKPiDC oCDCoCDCoCDCoHwgwqAgwqAgwqAgwqArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtp bnRlcmZhY2Utc3RhdHN9Pwo+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBu YW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0+Cj4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9h Y2UvbmFtZQo+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBh Y2tldHM/IMKgIHlhbmc6Y291bnRlcjY0Cj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKg ICstLXJvIG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4gwqAgwqAgwqAg wqArLS1ydyBlZ3Jlc3MKPiDCoCDCoCDCoCDCoCDCoCArLS1ydyBhY2wtc2V0cwo+IMKgIMKg IMKgIMKgIMKgIMKgIMKgKy0tcncgYWNsLXNldCogW25hbWVdCj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoC0+IC9hY2Nlc3MtbGlz dHMvYWNsL25hbWUKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyB0eXBlPyDCoCDC oCDCoCDCoCDCoCDCoCAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0 YXRzfT8KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG5hbWUgwqAgwqAg wqAgwqAgwqAgwqAgwqAgLT4KPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lCj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKg IHlhbmc6Y291bnRlcjY0Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBt YXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNvdW50ZXI2NAo+Cj4gQ29tbWVudHMgd2VsY29t ZSEKPgo+IENoZWVycywKPgo+IEVpbmFyCj4KPgo+Cj4+IE9uIDE0IERlYyAyMDE3LCBhdCAx ODo1MCwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pCj4+IDxlaW5hcm5uQGNpc2Nv LmNvbSA8bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4gd3JvdGU6Cj4+Cj4+Cj4+Cj4+PiBP biAxNCBEZWMgMjAxNywgYXQgMDg6MjEsIFNvbmFsIEFnYXJ3YWwgPHNhZ2Fyd2FsMTJAZ21h aWwuY29tCj4+PiA8bWFpbHRvOnNhZ2Fyd2FsMTJAZ21haWwuY29tPj4gd3JvdGU6Cj4+Pgo+ Pj4gSGkgRWluYXIsCj4+Pgo+Pj4gWW91IGhhZCAzIHF1ZXN0aW9ucyBmb3IgbWUgb24gYWxs IHRoZSBzZXZlcmFsIGUtbWFpbCB0aHJlYWRzLsKgCj4+PiAxLiBHbG9iYWwgYXR0YWNobWVu dCBwb2ludAo+Pj4gMi4gaWNtcC1vZmYKPj4+IDMuIGFjbC1hZ2dyZWdhdGUtaW50ZXJmYWNl IHN0YXRzLgo+Pj4KPj4+IEZvciAoMSksIG15IGZpcnN0IHByZWZlcmVuY2UgaXMgdG8gaGF2 ZSB0aGUgbW9kZWwgZGVmaW5lIGF0dGFjaG1lbnQKPj4+IHBvaW50IGZvciBpbnRlcmZhY2Vz IG9ubHkuCj4+Cj4+IGVpbmFybm4+IEkgaGF2ZSBzb21lIGRpZmZzLCBsYXllcmVkIG9uIHRv cCBvZiBNYWhlc2jigJlzIFBSIHRvCj4+IG5ldG1vZC13Zy9hY2wtbW9kZWwgdGhhdCBkbyB0 aGlzLiBOZWFybHkgbGlrZSB0aGUgYXVnbWVudGF0aW9uIEkgaGF2ZQo+PiBiZWxvdy4gRmVl bCBmcmVlIHRvIHRha2UgYSBsb29rIGF0Ogo+Pgo+PiAgICAgaHR0cHM6Ly9naXRodWIuY29t L21qZXRoYW5hbmRhbmkvYWNsLW1vZGVsL3B1bGwvMwo+Pgo+Pgo+Pj4gSG93ZXZlciwgS3Jp c3RpYW4gd2FudHMgdGhlIGdsb2JhbCBhdHRhY2htZW50IHBvaW50IGFzIHdlbGwgc28gdGhh dAo+Pj4gaGUgY2FuIGFkZCB0aGUgQUNMIHRvIHRoZSBsaW51eCB0YWJsZXMuCj4+Cj4+IGVp bmFybm4+IEkgdGhpbmsgS3Jpc3RpYW4gZG9lc27igJl0IGZlZWwgYSBnbG9iYWwgYXR0YWNo bWVudCBwb2ludAo+PiBuZWVkcyB0byBiZSBpbiB0aGlzIGZpcnN0IHJldmlzaW9uLiBCdXQg aGUgY2FuIGNvbmZpcm0uCj4+Cj4+PiBJZiBhbiBBQ0wgaXMgYXR0YWNoZWQgZ2xvYmFsbHks IGRvZXMgdGhpcyBtZWFuIGl0IGlzIHBlciBkaXJlY3Rpb24KPj4+IG9yIGRvZXMgaXQgbWVh biBpdCBpcyBhY3Jvc3MgZGlyZWN0aW9ucz8KPj4KPj4gZWluYXJubj4gSSBkb27igJl0IGtu b3cgcmlnaHQgbm93IDotKQo+Pgo+Pj4gVGhpcyBnbG9iYWwgQUNMIG1heSBub3QgYmUgYXBw bGljYWJsZSB0byBhbnkgb2YgQ2lzY28ncyBzZXJ2aWNlCj4+PiBwcm92aWRlciByb3V0ZXJz IGFzIEkgZG9uJ3Qgc2VlIGFueSBwbGF0Zm9ybSBhY3R1YWxseSByZXBsaWNhdGluZwo+Pj4g dGhlIEFDTCB0byBhbGwgbGluZSBjYXJkcyBhbmQgYXR0YWNoaW5nIGl0IGluIGluZ3Jlc3Mg YW5kIGVncmVzcwo+Pj4gZGlyZWN0aW9ucyBhY3Jvc3MgYWxsIGludGVyZmFjZXMuCj4+Cj4+ IGVpbmFybm4+IFBlciBvdGhlciBlbWFpbHMsIEkgZG9u4oCZdCB0aGluayB3ZSB1bmRlcnN0 YW5kIHRoaXMgZW5vdWdoCj4+IHlldCB0byBzcGVjaWZ5IGl0LCBzbyBJIHN1Z2dlc3Qgd2Ug anVzdCBsZWF2ZSBpdCBvdXQgZm9yIG5vdy4gTm90aGluZwo+PiBpbiB0aGUgbW9kZWwgcHJl dmVudHMgYSDigJxnbG9iYWwgYXR0YWNobWVudCBwb2ludOKAnSBiZWluZyBhZGRlZCBsYXRl cgo+PiBvbmNlIHdlIHVuZGVyc3RhbmQgd2hhdCBpdCByZWFsbHkgbWVhbnMuCj4+Cj4+PiBG b3IgKDIpLCBJIGFtIG9rIHdpdGggcmVtb3ZpbmcgaWNtcC1vZmYuCj4+Cj4+IGVpbmFybm4+ IERvbmUgaW4gbXkgUFIgYWJvdmUuCj4+Cj4+PiBGb3IgKDMpLCB0aGlzIHdvdWxkIGhhdmUg dG8gYmUgYSBjb21iaW5hdGlvbiBvZiBBQ0wgc3RhdHMgYWNyb3NzIGFsbAo+Pj4gaW50ZXJm YWNlcyBmb3IgYWxsIEFDTCdzLiBTb21ldGhpbmcgbGlrZSB0aGlzIGlzIHBvc3NpYmxlIG9u IGFuIFhSCj4+PiBib3ggd2hlcmUgQUNFUyBoYXZlIGNvdW50ZXIgbmFtZXMgYXNzb2NpYXRl ZCB3aXRoIGl0LiBMZXQncyBjaGF0Cj4+PiBhYm91dCB0aGlzIG9mZmxpbmUgdG9tb3Jyb3cu Cj4+Cj4+IGVpbmFybm4+IEnigJlsbCBwaW5nIHlvdSB0byBjbGFyaWZ5LCBhbmQgd2UgY2Fu IGJyaW5nIGFueSBjb25jbHVzaW9uCj4+IGJhY2sgdG8gdGhlIGxpc3QuCj4+Cj4+IENoZWVy cywKPj4KPj4gRWluYXIKPj4KPj4KPj4KPj4+IFNvbmFsLgo+Pj4KPj4+Cj4+PiBPbiBXZWQs IERlYyAxMywgMjAxNyBhdCAxMjoxMCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaQo+Pj4gPG1q ZXRoYW5hbmRhbmlAZ21haWwuY29tIDxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+ PiB3cm90ZToKPj4+Cj4+PiAgICAgV2Ugd2FudCB0byBzdXBwb3J0IOKAnGdsb2JhbOKAnSBh dHRhY2htZW50IHBvaW50IGRvd24gdGhlIGxpbmUsIGFuZAo+Pj4gICAgIHRoYXQg4oCcZ2xv YmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgd2lsbCBiZSBvbmUgb2YgdGhlIGNob2ljZXMgKHRo ZQo+Pj4gICAgIG90aGVyIGJlaW5nIHRoZSBpbnRlcmZhY2UpLCB3aGF0IHdvdWxkIHRoaXMg YXVnbWVudCBsb29rIGxpa2UuCj4+PiAgICAgTm90ZSwgYXMgZmFyIGFzIEkga25vdywgeW91 IGNhbm5vdCBhdWdtZW50IGluc2lkZSBhIGNob2ljZSBub2RlLgo+Pj4KPj4+PiAgICAgT24g RGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJu bikKPj4+PiAgICAgPGVpbmFybm5AY2lzY28uY29tIDxtYWlsdG86ZWluYXJubkBjaXNjby5j b20+PiB3cm90ZToKPj4+Pgo+Pj4+ICAgICBQZXJoYXBzIGxpa2UgdGhpcywgYXMgYW4gYXVn bWVudGF0aW9uIHRvIHRoZSBpbnRlcmZhY2U6Cj4+Pj4KPj4+PiAgICAgICAgIMKgIGF1Z21l bnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOgo+Pj4+ICAgICAgICAgwqAgwqAgKy0t cncgaW5ncmVzcy1hY2xzCj4+Pj4gICAgICAgICDCoCDCoCB8IMKgKy0tcncgYWNsLXNldHMK Pj4+PiAgICAgICAgIMKgIMKgIHwgwqAgwqAgKy0tcncgYWNsLXNldCogW25hbWVdCj4+Pj4g ICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDC oCDCoC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUKPj4+PiAgICAgICAgIMKgIMKgIHwgwqAg wqAgwqAgwqArLS1ydyB0eXBlPyDCoCDCoCDCoCDCoCDCoCDCoCAtPiAvYWNjZXNzLWxpc3Rz L2FjbC90eXBlCj4+Pj4gICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgKy0tcm8gYWNlLXN0 YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+PiAgICAgICAgIMKgIMKg IHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+ Pj4+ICAgICAgICAgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+Pj4+ICAgICAg ICAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlh bmc6Y291bnRlcjY0Cj4+Pj4gICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJv IG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+Pj4gICAgICAgICDCoCDC oCArLS1ydyBlZ3Jlc3MtYWNscwo+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqArLS1ydyBhY2wt c2V0cwo+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldCogW25hbWVd Cj4+Pj4gICAgICAgICDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJ3IG5hbWUgwqAgwqAgwqAg wqAgwqAgwqAgwqAtPiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lCj4+Pj4gICAgICAgICDCoCDC oCDCoCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9hY2Nl c3MtbGlzdHMvYWNsL3R5cGUKPj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0t cm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+PiAgICAg ICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAgwqAgwqAgwqAgwqAg wqAgwqAgLT4KPj4+PiAgICAgICAgIC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUK Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtcGFj a2V0cz8gwqAgeWFuZzpjb3VudGVyNjQKPj4+PiAgICAgICAgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+Pj4K Pj4+Pgo+Pj4+ICAgICBDb3VsZCBhbHNvIHB1dCBhbiDigJxhY2Vz4oCdIGNvbnRhaW5lciBh Ym92ZSBib3RoIHRoZXNlICYgcmVuYW1lCj4+Pj4gICAgIOKAnGluZ3Jlc3MtYWNscyIgdG8g 4oCcaW5ncmVzc+KAnSwgZXRjLiB0byBnaXZlIGEgc2luZ2xlIHJvb3QgZm9yIHRoZQo+Pj4+ ICAgICBhdWdtZW50YXRpb24gaWYgcHJlZmVycmVkLgo+Pj4+Cj4+Pj4gICAgIENoZWVycywK Pj4+Pgo+Pj4+ICAgICBFaW5hcgo+Pj4+Cj4+Pj4KPj4+Pj4gICAgIE9uIDYgRGVjIDIwMTcs IGF0IDE5OjQzLCBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbQo+Pj4+PiAgICAgPG1haWx0 bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOgo+Pj4+Pgo+Pj4+Pgo+Pj4+Pgo+Pj4+PiAgICAg T24gMTIvNi8xNyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOgo+Pj4+Pj4g ICAgIEhvdyBkb2VzIG9uZSBtb3ZlIHRoZSBpbnRlcmZhY2UgYXR0YWNobWVudCBwb2ludCwg Y3VycmVudGx5IGFuCj4+Pj4+PiAgICAgJ2ludGVyZmFjZS1yZWYnLCB0byBhbiBhdWdtZW50 YXRpb24gb2YgdGhlCj4+Pj4+PiAgICAgaWY6aW50ZXJmYWNlcy9pbnRlcmZhY2UsCj4+Pj4+ PiAgICAgaW5zaWRlIG9mIHRoZSDigJhhY2zigJkgwqBjb250YWluZXI/IERvd24gdGhlIGxp bmUgd2UgbWlnaHQgbmVlZAo+Pj4+Pj4gICAgIHRvIGhhdmUgYW4KPj4+Pj4+ICAgICBjb250 YWluZXIgZm9yICJhdHRhY2htZW50IHBvaW50cyIgdG8gYWNjb21tb2RhdGUgdGhlCj4+Pj4+ PiAgICAgcG9zc2liaWxpdHkgb2YKPj4+Pj4+ICAgICBhdHRhY2hpbmcgYW4gQUNMIGVpdGhl ciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uCj4+Pj4+Pgo+Pj4+Pgo+Pj4+ PiAgICAgS2VlcGluZyBpbiBtaW5kIHRoYXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vz bid0IGF0dGFjaCB0byBhbgo+Pj4+PiAgICAgaW50ZXJmYWNlIGF0IGFsbC4KPj4+Pj4KPj4+ Pj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4+Pj4+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+ICAgICBuZXRtb2RAaWV0Zi5v cmcgPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Cj4+Pj4+ICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4+PiAgICAgPGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPgo+Pj4+Cj4+Pgo+Pj4gICAgIE1haGVz aCBKZXRoYW5hbmRhbmkKPj4+ICAgICBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbSA8bWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tPgo+Pj4KPj4+Cj4+PiAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+ICAgICBuZXRtb2QgbWFp bGluZyBsaXN0Cj4+PiAgICAgbmV0bW9kQGlldGYub3JnIDxtYWlsdG86bmV0bW9kQGlldGYu b3JnPgo+Pj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kCj4+PiAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kPgo+Pj4KPj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPj4gbmV0bW9kQGlldGYub3Jn IDxtYWlsdG86bmV0bW9kQGlldGYub3JnPgo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBp ZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k Cgo= --------------1186BCA1D7BD4BF754BCA652 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Einar,

I think this change is fine, with one exception.=C2=A0 I would rat= her 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-Nygaar= d (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 --l= int -f tree ietf-access-control-list.yang
ietf-access-control-list= =2Eyang:51: error: bad value "YYYY-MM-DD" (should be date)
=
module: ietf-access-control-list
=C2=A0 =C2=A0 +--rw acce= ss-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 {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-mask? =C2=A0 yang:mac-a= ddress
=C2=A0 =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)
=C2=A0 =C2=A0 =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=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)
=C2=A0 =C2=A0 =C2=A0 =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-pref= ix
=C2=A0 =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=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 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=A0ui= nt32
=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 ui= nt16
=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 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 {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-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=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}?
=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 +--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-> /acce= ss-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-lis= ts/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-> /acce= ss-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-lis= ts/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-Nygaar= d (einarnn) <einarnn@cisco.com> wrote:=



On 14 Dec 2017, at 08:21, Sonal Agarwal <sagarwal12@gm= ail.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 t= o 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://git= hub.com/mjethanandani/acl-model/pull/3

However, Kristian wants the globa= l 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 po= int=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 cl= arify, and we can bring any conclusion back to the list.

Cheers,

Einar



Sonal.


On Wed, Dec 13, 2017 a= t 12:10 PM, Mahesh Jethanandani <mjethanandani@gmai= l.com> wrote:
We want to support =E2=80=9Cglobal=E2=80=9D at= tachment 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) <eina= rnn@cisco.com> wrote:

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

=C2=A0= augment /if:interfaces/if:int= erface:
=C2=A0= =C2=A0 +--rw ingress-acls
=C2=A0= =C2=A0 | =C2=A0+--rw acl-sets<= /font>
=C2=A0= =C2=A0 | =C2=A0 =C2=A0 +--rw a= cl-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/nam= e
=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/typ= e
=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:counter64<= /font>
=C2=A0= =C2=A0 +--rw egress-acls
=C2=A0= =C2=A0 =C2=A0 =C2=A0+--rw acl-sets<= /font>
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw a= cl-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/nam= e
=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/typ= e
=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:counter64<= /font>

Could also pu= t an =E2=80=9Caces=E2=80=9D c= ontainer 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.<= /div>

Cheers,

Einar
=


On 6 De= c 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/int= erface,
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=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/list= info/netmod


Mahesh Jethanandani=
mjetha= nandani@gmail.com


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



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



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

--------------1186BCA1D7BD4BF754BCA652-- --0pDQurFe5Cb4lpFQsVndMJ2Fr7aEmfJOb-- --OLdtCDr3jonlxmmpvmd00iJBkLCt3MeUp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlo2VS4ACgkQh7ZrRtnS ejMdzAf/YknZkfCIrmjUsBPBqCI3fUwebvd+ArKD7mndVDF0+UQYE3NIPjDW0y5e 2rdkjzKvufnpvIAfkAJmnGNf3qI/pscRU/ZSKFkBDAPhwpte54XwW/DMyorZYwcR iewLt3JR2svB5yKhcFE6WunlGricNAXv5ezEvMUp+B708c1JanU+AQhqvJS8LAfP CWNATq+26nhzW0GtV586Wb8jBqaFLbATzqkfHcsTGEaGO2PuOl2Hxg6Q6Zehwf1B IYNj8xvxW1GnlhGlg6Af46HYNaSGdzKdGzNhkBxFciDF0H2hdE1OYwXS3COcii0W qxvzEvY59wZqvv0tQ8C67nOfZE6Cnw== =NrQR -----END PGP SIGNATURE----- --OLdtCDr3jonlxmmpvmd00iJBkLCt3MeUp-- From nobody Sun Dec 17 04:00:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A56127201 for ; Sun, 17 Dec 2017 04:00:43 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id degISlyy4p4h for ; Sun, 17 Dec 2017 04:00: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 E751C12711E for ; Sun, 17 Dec 2017 04:00: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 E444F69; Sun, 17 Dec 2017 13:00:38 +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 2WnvR1KjdzMg; Sun, 17 Dec 2017 13:00: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; Sun, 17 Dec 2017 13:00:38 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D10D420130; Sun, 17 Dec 2017 13:00:38 +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 gq_pzgx64MtG; Sun, 17 Dec 2017 13:00:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 927BC20073; Sun, 17 Dec 2017 13:00:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5DED1419D159; Sun, 17 Dec 2017 13:00:38 +0100 (CET) Date: Sun, 17 Dec 2017 13:00:38 +0100 From: Juergen Schoenwaelder To: Eliot Lear Cc: "netmod@ietf.org" Message-ID: <20171217120038.iwne4nkty4z6kz2t@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Eliot Lear , "netmod@ietf.org" References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) 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: Sun, 17 Dec 2017 12:00:43 -0000 On Sun, Dec 17, 2017 at 12:29:50PM +0100, Eliot Lear wrote: > I would rather the augment to the interface not be required for > implementations that don't actually have interfaces. Do you have an example of such a device / implementation? /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 Sun Dec 17 04:17:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9C512785F for ; Sun, 17 Dec 2017 04:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 YsaWA1hEoYjD for ; Sun, 17 Dec 2017 04:17:15 -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 DF99B1205F1 for ; Sun, 17 Dec 2017 04:17:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2543; q=dns/txt; s=iport; t=1513513035; x=1514722635; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xMDz5FY7s8YRSoaMYHX2guwtixoJsbTHNwnQHHx0kVo=; b=kudZp4S2PiJ/9If7eMAonRpI3b4kLH1wJ8h3WMz4yrHDiJyyJmR7WgTN vXp6HTdOijs0TieP1ATuNj0yVC4hizHyHZO0mUv79Bte05FRWrbqj7kwM VWAf05qzhraAQrXAtK+Tx7b/1ZQ4Il1jbJtSL2mMvxOwcuIhR/qyAJDj4 0=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAQAfYDZa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUYhC2LFY9kMZk2BwOFOwKFQxQBAQEBAQEBAQFrHQuFJAEFI2Y?= =?us-ascii?q?LGCoCAlcGDQgBAYomqQ+CJ4pmAQEBAQEBBAEBAQEBFA+DboV2gwOIMoJjBYpcm?= =?us-ascii?q?GCET4ItjjCBfYoYh16WeIE7NiKBTzIaCBsVgmaEVkCKeAEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,415,1508803200"; d="asc'?scan'208";a="968919" 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; 17 Dec 2017 12:17:09 +0000 Received: from [10.61.192.142] ([10.61.192.142]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBHCH8Kj020621 for ; Sun, 17 Dec 2017 12:17:09 GMT To: "netmod@ietf.org" References: <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> <20171217120038.iwne4nkty4z6kz2t@elstar.local> From: Eliot Lear Message-ID: <35eabb48-4a1b-eed3-3adc-bc53ae111441@cisco.com> Date: Sun, 17 Dec 2017 13:17:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171217120038.iwne4nkty4z6kz2t@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Rvft2hcS5sluMVkKhHMQJqRf2vqQlFfAv" 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: Sun, 17 Dec 2017 12:17:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Rvft2hcS5sluMVkKhHMQJqRf2vqQlFfAv Content-Type: multipart/mixed; boundary="E9rPDt6fadRu8flroiE5pkEmbLengJ0mo"; protected-headers="v1" From: Eliot Lear To: "netmod@ietf.org" Message-ID: <35eabb48-4a1b-eed3-3adc-bc53ae111441@cisco.com> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 References: <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> <20171217120038.iwne4nkty4z6kz2t@elstar.local> In-Reply-To: <20171217120038.iwne4nkty4z6kz2t@elstar.local> --E9rPDt6fadRu8flroiE5pkEmbLengJ0mo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 17.12.17 13:00, Juergen Schoenwaelder wrote: > On Sun, Dec 17, 2017 at 12:29:50PM +0100, Eliot Lear wrote: > >> I would rather the augment to the interface not be required for >> implementations that don't actually have interfaces. > Do you have an example of such a device / implementation? > Yes.=C2=A0 Manufacturer Usage Descriptions.=C2=A0 In this case the access= -lists of the ACL model are used to build out an intent description relating to a device.=C2=A0 There is no specific interface assigned to that intent. Eliot --E9rPDt6fadRu8flroiE5pkEmbLengJ0mo-- --Rvft2hcS5sluMVkKhHMQJqRf2vqQlFfAv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlo2YEIACgkQh7ZrRtnS ejOAaAgAwEs9twug+QNgxchFrSY/fEvDeMKLbu8OSFl+2bxlTYF/R02FFw+mzkfD 1NfSg6UfvkL1nmD1dH/Mn7a+z1Ns82RbSx3ut8GjvQes05KTVlfqXBG6c4yX3Uwu bKKBZh/864+8HsiGa1ddAn0ZeOhGoQIA07rme4BmOrWcJOPil4SsV3RZAmUW1uUe zkS29xlT9Xux110/IHrIyne7hdGygcZkKrxa8WI8D/13+Q81FiKV+/FA/g3NuikM WQJw6w55oSfVJLcwJLbzolfRuOvz6Y/g/RmNLkHb6dts9BU3x/K1hUnsTBj+bLnr asJVsyI0yZSYhS2A/B2HRUszJ7RJCw== =Q24I -----END PGP SIGNATURE----- --Rvft2hcS5sluMVkKhHMQJqRf2vqQlFfAv-- From nobody Sun Dec 17 06:35:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85989126B7F for ; Sun, 17 Dec 2017 06:35:16 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbfxGfyNms9G for ; Sun, 17 Dec 2017 06:35:12 -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 6F9DF124B18 for ; Sun, 17 Dec 2017 06:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79728; q=dns/txt; s=iport; t=1513521312; x=1514730912; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DTaUTvaacdM8wsRdVQq3vInCevFh1o/sDwRFt8ZcoYE=; b=EVR+bZKPT02f1URVYL3xBOuMUzFESYfK1rRA6N0tsNhc9Wq0rOCVrgmz 4NHw8mOL+RqIxjGnblxgYUUSsrjZ2LPULEJlhcnSVXlndl0S2lRoc1iQx FTIF6EPKrZ3q19GF+ofFsU9PnqcuXPIQPxHezVK8Ynfp/HqJhor9/jqDE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQDmfzZa/4kNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDDy9mdBQTB4N/iiGPCYFaiSeOIBSBfgMKGAEKgTkBgw9PAhq?= =?us-ascii?q?EZj8YAQEBAQEBAQEBayiFJAIBAwEBGAkERwsQAgEIOAEGAwICAh8GCxQRAgQOB?= =?us-ascii?q?YlGTAMVEKh3gW06JocNDYMmAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDboIOgz4?= =?us-ascii?q?BKQyCd4JqRAGBRBIXGB+CXzGCMgWSG4dCiSI9Aod9iC+EfoIWhhOLSo0bPoVbg?= =?us-ascii?q?xcCERkBgToBHzmBT28VPCoBgX4/gVuCPHiJLIEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,416,1508803200"; d="scan'208,217";a="331570381" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2017 14:34:53 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBHEYrhV024852 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 17 Dec 2017 14:34: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; Sun, 17 Dec 2017 09:34: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; Sun, 17 Dec 2017 09:34:52 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Eliot Lear CC: "netmod@ietf.org" , Kristian Larsson Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 Thread-Index: AQHTbr9cXtHryOdSBU6fXjbxU9aeHqM3Cy0AgAqwcwCAAFeRgIAAzEsAgACvpICAAshNAIABc5kAgAAzf4A= Date: Sun, 17 Dec 2017 14:34:52 +0000 Message-ID: <5299E333-F1F3-4781-B467-0BFB271A4915@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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.163.11] Content-Type: multipart/alternative; boundary="_000_5299E333F1F34781B4670BFB271A4915ciscocom_" 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: Sun, 17 Dec 2017 14:35:16 -0000 --_000_5299E333F1F34781B4670BFB271A4915ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RWxpb3QsDQoNCk5vdGhpbmcgY2FuIGZvcmNlIGFuIGltcGxlbWVudGF0aW9uIHRvIGhhdmUgdG8g aW1wbGVtZW50IGVpdGhlciB0aGUgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsIG9yIHRoZSBhdWdtZW50 YXRpb24gaW4gdGhlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCBtb2RlbC4gSSBhcHByZWNpYXRl IHlvdXIgZGVzaXJlIGZvciBtb2R1bGFyaXR5IGFuZCBjb2hlc2l2ZW5lc3MsIGJ1dCBJIHdvdWxk IHJlc2lzdCAjMSwgYmVjYXVzZSBJIGZlZWwgdGhhdCB0aGUgbWFqb3JpdHkgb2YgdXNlcnMgd2ls bCBiZSB0YXJnZXRpbmcgaW50ZXJmYWNlLWJhc2VkIGF0dGFjaG1lbnQgb3ZlciB0aW1lLiBJ4oCZ dmUgYWRkZSBiYWNrIGluIHVzZSBvZiB0aGUg4oCcaW50ZXJmYWNlLWF0dGFjaG1lbnTigJ0gZmVh dHVyZSAod2hpY2ggSSB0b29rIG91dCBhcyBwYXJ0IG9mIHJlZmFjdG9yaW5nIGludGVyZmFjZSBh dHRhY2htZW50KS4gUGFydCBvZjoNCg0KaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wt bW9kZWwvcHVsbC8yMQ0KDQpUaGUgYXVnbWVudHMgcGFydCBvZiB0aGUgdHJlZSBub3cgbG9va3Mg bGlrZToNCg0KICBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZToNCiAgICArLS1y dyBhY2xzIHtpbnRlcmZhY2UtYXR0YWNobWVudH0/DQogICAgICAgKy0tcncgaW5ncmVzcw0KICAg ICAgIHwgICstLXJ3IGFjbC1zZXRzDQogICAgICAgfCAgICAgKy0tcncgYWNsLXNldCogW25hbWVd DQogICAgICAgfCAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0 cy9hY2wvbmFtZQ0KICAgICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+IC9h Y2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICAgICB8ICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGlj cyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgICAgIHwgICAgICAgICAgICstLXJvIG5h bWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAg ICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQog ICAgICAgfCAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0 DQogICAgICAgKy0tcncgZWdyZXNzDQogICAgICAgICAgKy0tcncgYWNsLXNldHMNCiAgICAgICAg ICAgICArLS1ydyBhY2wtc2V0KiBbbmFtZV0NCiAgICAgICAgICAgICAgICArLS1ydyBuYW1lICAg ICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgICAgICAgICAgICAgKy0t cncgdHlwZT8gICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgICAgICAg ICAgICAgICstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQog ICAgICAgICAgICAgICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlz dHMvYWNsL2FjZXMvYWNlL25hbWUNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBh Y2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVk LW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQoNCk9uIDE3 IERlYyAyMDE3LCBhdCAxMToyOSwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxl YXJAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KRWluYXIsDQoNCkkgdGhpbmsgdGhpcyBjaGFuZ2Ug aXMgZmluZSwgd2l0aCBvbmUgZXhjZXB0aW9uLiAgSSB3b3VsZCByYXRoZXIgdGhlIGF1Z21lbnQg dG8gdGhlIGludGVyZmFjZSBub3QgYmUgcmVxdWlyZWQgZm9yIGltcGxlbWVudGF0aW9ucyB0aGF0 IGRvbid0IGFjdHVhbGx5IGhhdmUgaW50ZXJmYWNlcy4gIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJl IG1heSBiZSB0d28gd2F5cyB0byBnbyBhYm91dCB0aGlzOg0KDQogIDEuICBTZXBhcmF0ZSBvdXQg dGhlIGF1Z21lbnQgaW50byBhIHNlcGFyYXRlIG1vZHVsZSAoc2FtZSBkb2MgaXMgZmluZSk7IG9y DQogIDIuICBTb21laG93ICJmZWF0dXJlLWl6ZSIgdGhlIGF1Z21lbnQuDQoNCkkgZG9uJ3Qga25v dyBob3cgdG8gZG8gKDIpIGJ1dCBpZiB5b3UgZG8sIHRoYXQncyBva2F5IGJ5IG1lLg0KDQpFbGlv dA0KDQpPbiAxNi4xMi4xNyAxNDoxOSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdy b3RlOg0KQWxsLA0KDQpBZnRlciBhIHNlcmllcyBvZiBkaXNjdXNzaW9ucyBvbi0gYW5kIG9mZi1s aXN0LCBJIGhhdmUgYSBjYW5kaWRhdGUgUFIgdGhhdCBpbmNsdWRlcyB0aGUgY2hhbmdlcyBpbiB0 aGUgUFIgTWFoZXNoIHNlbnQgb3V0IHBsdXMgc29tZSBtb3JlIGVkaXRzLiBQbGVhc2Ugc2VlIGNv bnNvbGlkYXRlZCBQUiBoZXJlOg0KDQpodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1t b2RlbC9wdWxsLzIxDQoNCk1haW4gY2hhbmdlcyBpbiBhZGRpdGlvbiB0byBNYWhlc2jigJlzIFBS IGFyZToNCg0KDQogICogICBNb3ZlZCBpbnRlcmZhY2UgYXR0YWNobWVudCB0byBiZSB2aWEgYW4g aW50ZXJmYWNlIGF1Z21lbnRhdGlvbi4NCiAgKiAgIFJlc3RydWN0dXJlZCBwb3J0IG1hdGNoZXMg c2xpZ2h0bHkgdW5kZXIgYm90aCBJUHY0IGFuZCBJUHY2IGNvbnRhaW5lcnMuDQogICogICBSZW1v dmVkIHVubmVjZXNzYXJ5IGlkZW50aXR5ICdpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0ZeKAmS4NCiAg KiAgIFJlbW92ZWQgYWN0aW9uIOKAmGljbXAtb2Zm4oCZLCBjYW4gYmUgYXVnbWVudGVkIGxhdGVy Lg0KDQpGb3IgcmVmZXJlbmNlLCBoZXJlIGlzIHRoZSBjdXJyZW50IFlBTkcgdHJlZSBwbHVzIOKA nC0taWV0ZuKAnSBsb2dzOg0KDQoxMzoxMiAkIHB5YW5nIC0taWV0ZiAtLWxpbnQgLWYgdHJlZSBp ZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QueWFuZw0KaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlh bmc6NTE6IGVycm9yOiBiYWQgdmFsdWUgIllZWVktTU0tREQiIChzaG91bGQgYmUgZGF0ZSkNCm1v ZHVsZTogaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0DQogICAgKy0tcncgYWNjZXNzLWxpc3RzDQog ICAgICAgKy0tcncgYWNsKiBbbmFtZV0NCiAgICAgICAgICArLS1ydyBuYW1lICAgIHN0cmluZw0K ICAgICAgICAgICstLXJ3IHR5cGU/ICAgYWNsLXR5cGUNCiAgICAgICAgICArLS1ydyBhY2VzDQog ICAgICAgICAgICAgKy0tcncgYWNlKiBbbmFtZV0NCiAgICAgICAgICAgICAgICArLS1ydyBuYW1l ICAgICAgICAgIHN0cmluZw0KICAgICAgICAgICAgICAgICstLXJ3IG1hdGNoZXMNCiAgICAgICAg ICAgICAgICB8ICArLS1ydyAobDIpPw0KICAgICAgICAgICAgICAgIHwgIHwgICstLTooZXRoKQ0K ICAgICAgICAgICAgICAgIHwgIHwgICAgICstLXJ3IGV0aCB7bWF0Y2gtb24tZXRofT8NCiAgICAg ICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcz8gICAg ICAgIHlhbmc6bWFjLWFkZHJlc3MNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBk ZXN0aW5hdGlvbi1tYWMtYWRkcmVzcy1tYXNrPyAgIHlhbmc6bWFjLWFkZHJlc3MNCiAgICAgICAg ICAgICAgICB8ICB8ICAgICAgICArLS1ydyBzb3VyY2UtbWFjLWFkZHJlc3M/ICAgICAgICAgICAg IHlhbmc6bWFjLWFkZHJlc3MNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBzb3Vy Y2UtbWFjLWFkZHJlc3MtbWFzaz8gICAgICAgIHlhbmc6bWFjLWFkZHJlc3MNCiAgICAgICAgICAg ICAgICB8ICB8ICAgICAgICArLS1ydyBldGhlcnR5cGU/ICAgICAgICAgICAgICAgICAgICAgIGV0 aDpldGhlcnR5cGUNCiAgICAgICAgICAgICAgICB8ICArLS1ydyAobDMpPw0KICAgICAgICAgICAg ICAgIHwgIHwgICstLTooaXB2NCkNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBpcHY0 IHttYXRjaC1vbi1pcHY0fT8NCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBkc2Nw PyAgICAgICAgICAgICAgICAgICAgICAgaW5ldDpkc2NwDQogICAgICAgICAgICAgICAgfCAgfCAg fCAgICAgKy0tcncgZWNuPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAg ICAgICAgfCAgfCAgfCAgICAgKy0tcncgbGVuZ3RoPyAgICAgICAgICAgICAgICAgICAgIHVpbnQx Ng0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHR0bD8gICAgICAgICAgICAgICAg ICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHByb3RvY29s PyAgICAgICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICst LXJ3IChzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcik/DQogICAgICAgICAgICAgICAgfCAg fCAgfCAgICAgfCAgKy0tOihyYW5nZSkNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICB8 ICArLS1ydyBzb3VyY2UtcG9ydC1sb3dlciAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAg ICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgIHwgICstLXJ3IHNvdXJjZS1wb3J0LXVwcGVyICAg ICAgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgfCAg Ky0tOihvcGVyYXRvcikNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICAgICArLS1ydyBz b3VyY2Utb3BlcmF0b3IgICAgICAgICAgICAgb3BlcmF0b3INCiAgICAgICAgICAgICAgICB8ICB8 ICB8ICAgICB8ICAgICArLS1ydyBzb3VyY2UtcG9ydCAgICAgICAgICAgICAgICAgaW5ldDpwb3J0 LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IChkZXN0aW5hdGlvbi1w b3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8NCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICAr LS06KHJhbmdlKQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgIHwgICstLXJ3IGRlc3Rp bmF0aW9uLXBvcnQtbG93ZXIgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAgICAgICAgICAgICAg fCAgfCAgfCAgICAgfCAgfCAgKy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciAgICAgIGluZXQ6 cG9ydC1udW1iZXINCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICArLS06KG9wZXJhdG9y KQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICAgICstLXJ3IGRlc3RpbmF0aW9uLW9w ZXJhdG9yICAgICAgICBvcGVyYXRvcg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICAg ICstLXJ3IGRlc3RpbmF0aW9uLXBvcnQgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyDQogICAg ICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgaWhsPyAgICAgICAgICAgICAgICAgICAgICAg IHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgZmxhZ3M/ICAgICAgICAg ICAgICAgICAgICAgIGJpdHMNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBvZmZz ZXQ/ICAgICAgICAgICAgICAgICAgICAgdWludDE2DQogICAgICAgICAgICAgICAgfCAgfCAgfCAg ICAgKy0tcncgaWRlbnRpZmljYXRpb24/ICAgICAgICAgICAgIHVpbnQxNg0KICAgICAgICAgICAg ICAgIHwgIHwgIHwgICAgICstLXJ3IGRlc3RpbmF0aW9uLWlwdjQtbmV0d29yaz8gICBpbmV0Omlw djQtcHJlZml4DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgc291cmNlLWlwdjQt bmV0d29yaz8gICAgICAgIGluZXQ6aXB2NC1wcmVmaXgNCiAgICAgICAgICAgICAgICB8ICB8ICAr LS06KGlwdjYpDQogICAgICAgICAgICAgICAgfCAgfCAgICAgKy0tcncgaXB2NiB7bWF0Y2gtb24t aXB2Nn0/DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgZHNjcD8gICAgICAgICAg ICAgICAgICAgICAgIGluZXQ6ZHNjcA0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3 IGVjbj8gICAgICAgICAgICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwg ICAgICAgICstLXJ3IGxlbmd0aD8gICAgICAgICAgICAgICAgICAgICB1aW50MTYNCiAgICAgICAg ICAgICAgICB8ICB8ICAgICAgICArLS1ydyB0dGw/ICAgICAgICAgICAgICAgICAgICAgICAgdWlu dDgNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyBwcm90b2NvbD8gICAgICAgICAg ICAgICAgICAgdWludDgNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyAoc291cmNl LXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPw0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwg ICstLToocmFuZ2UpDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgfCAgKy0tcncgc291 cmNlLXBvcnQtbG93ZXIgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAgICAgICAgICAg ICB8ICB8ICAgICAgICB8ICB8ICArLS1ydyBzb3VyY2UtcG9ydC11cHBlciAgICAgICAgICAgaW5l dDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICstLToob3BlcmF0 b3IpDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgICAgKy0tcncgc291cmNlLW9wZXJh dG9yICAgICAgICAgICAgIG9wZXJhdG9yDQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAg ICAgKy0tcncgc291cmNlLXBvcnQgICAgICAgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAg ICAgICAgICAgICAgICB8ICB8ICAgICAgICArLS1ydyAoZGVzdGluYXRpb24tcG9ydC1yYW5nZS1v ci1vcGVyYXRvcik/DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgKy0tOihyYW5nZSkN CiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICB8ICArLS1ydyBkZXN0aW5hdGlvbi1wb3J0 LWxvd2VyICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAg IHwgIHwgICstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIgICAgICBpbmV0OnBvcnQtbnVtYmVy DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgKy0tOihvcGVyYXRvcikNCiAgICAgICAg ICAgICAgICB8ICB8ICAgICAgICB8ICAgICArLS1ydyBkZXN0aW5hdGlvbi1vcGVyYXRvciAgICAg ICAgb3BlcmF0b3INCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgICArLS1ydyBkZXN0 aW5hdGlvbi1wb3J0ICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcg0KICAgICAgICAgICAgICAg IHwgIHwgICAgICAgICstLXJ3IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29yaz8gICBpbmV0OmlwdjYt cHJlZml4DQogICAgICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgc291cmNlLWlwdjYtbmV0 d29yaz8gICAgICAgIGluZXQ6aXB2Ni1wcmVmaXgNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAg ICArLS1ydyBmbG93LWxhYmVsPyAgICAgICAgICAgICAgICAgaW5ldDppcHY2LWZsb3ctbGFiZWwN CiAgICAgICAgICAgICAgICB8ICArLS1ydyAobDQpPw0KICAgICAgICAgICAgICAgIHwgIHwgICst LToodGNwKQ0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IHRjcCB7bWF0Y2gtb24tdGNw fT8NCiAgICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyBzZXF1ZW5jZS1udW1iZXI/ICAg ICAgICAgIHVpbnQzMg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGFja25vd2xl ZGdlbWVudC1udW1iZXI/ICAgdWludDMyDQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0t cncgZGF0YS1vZmZzZXQ/ICAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwg IHwgICAgICstLXJ3IHJlc2VydmVkPyAgICAgICAgICAgICAgICAgdWludDgNCiAgICAgICAgICAg ICAgICB8ICB8ICB8ICAgICArLS1ydyBmbGFncz8gICAgICAgICAgICAgICAgICAgIGJpdHMNCiAg ICAgICAgICAgICAgICB8ICB8ICB8ICAgICArLS1ydyB3aW5kb3ctc2l6ZT8gICAgICAgICAgICAg IHVpbnQxNg0KICAgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLXJ3IHVyZ2VudC1wb2ludGVy PyAgICAgICAgICAgdWludDE2DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgb3B0 aW9ucz8gICAgICAgICAgICAgICAgICB1aW50MzINCiAgICAgICAgICAgICAgICB8ICB8ICArLS06 KHVkcCkNCiAgICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyB1ZHAge21hdGNoLW9uLXVkcH0/ DQogICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tcncgbGVuZ3RoPyAgIHVpbnQxNg0KICAg ICAgICAgICAgICAgIHwgIHwgICstLTooaWNtcCkNCiAgICAgICAgICAgICAgICB8ICB8ICAgICAr LS1ydyBpY21wIHttYXRjaC1vbi1pY21wfT8NCiAgICAgICAgICAgICAgICB8ICB8ICAgICAgICAr LS1ydyB0eXBlPyAgICAgICAgICAgICB1aW50OA0KICAgICAgICAgICAgICAgIHwgIHwgICAgICAg ICstLXJ3IGNvZGU/ICAgICAgICAgICAgIHVpbnQ4DQogICAgICAgICAgICAgICAgfCAgfCAgICAg ICAgKy0tcncgcmVzdC1vZi1oZWFkZXI/ICAgdWludDMyDQogICAgICAgICAgICAgICAgfCAgKy0t cncgZWdyZXNzLWludGVyZmFjZT8gICAgaWY6aW50ZXJmYWNlLXJlZg0KICAgICAgICAgICAgICAg IHwgICstLXJ3IGluZ3Jlc3MtaW50ZXJmYWNlPyAgIGlmOmludGVyZmFjZS1yZWYNCiAgICAgICAg ICAgICAgICArLS1ydyBhY3Rpb25zDQogICAgICAgICAgICAgICAgfCAgKy0tcncgZm9yd2FyZGlu ZyAgICBpZGVudGl0eXJlZg0KICAgICAgICAgICAgICAgIHwgICstLXJ3IGxvZ2dpbmc/ICAgICAg aWRlbnRpdHlyZWYNCiAgICAgICAgICAgICAgICArLS1ybyBzdGF0aXN0aWNzIHthY2wtYWdncmVn YXRlLXN0YXRzfT8NCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAg eWFuZzpjb3VudGVyNjQNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8g ICAgeWFuZzpjb3VudGVyNjQNCg0KICBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFj ZToNCiAgICArLS1ydyBhY2xzDQogICAgICAgKy0tcncgaW5ncmVzcw0KICAgICAgIHwgICstLXJ3 IGFjbC1zZXRzDQogICAgICAgfCAgICAgKy0tcncgYWNsLXNldCogW25hbWVdDQogICAgICAgfCAg ICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0K ICAgICAgIHwgICAgICAgICstLXJ3IHR5cGU/ICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMv YWNsL3R5cGUNCiAgICAgICB8ICAgICAgICArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtp bnRlcmZhY2Utc3RhdHN9Pw0KICAgICAgIHwgICAgICAgICAgICstLXJvIG5hbWUgICAgICAgICAg ICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lDQogICAgICAgfCAgICAgICAg ICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgfCAgICAg ICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0DQogICAgICAgKy0t cncgZWdyZXNzDQogICAgICAgICAgKy0tcncgYWNsLXNldHMNCiAgICAgICAgICAgICArLS1ydyBh Y2wtc2V0KiBbbmFtZV0NCiAgICAgICAgICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAt PiAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgICAgICAgICAgICAgKy0tcncgdHlwZT8gICAg ICAgICAgICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgICAgICAgICAgICAgICstLXJv IGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgICAgICAgICAg ICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMv YWNlL25hbWUNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFu Zzpjb3VudGVyNjQNCiAgICAgICAgICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAg eWFuZzpjb3VudGVyNjQNCg0KQ29tbWVudHMgd2VsY29tZSENCg0KQ2hlZXJzLA0KDQpFaW5hcg0K DQoNCg0KT24gMTQgRGVjIDIwMTcsIGF0IDE4OjUwLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWlu YXJubikgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdyb3Rl Og0KDQoNCg0KT24gMTQgRGVjIDIwMTcsIGF0IDA4OjIxLCBTb25hbCBBZ2Fyd2FsIDxzYWdhcndh bDEyQGdtYWlsLmNvbTxtYWlsdG86c2FnYXJ3YWwxMkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkg RWluYXIsDQoNCllvdSBoYWQgMyBxdWVzdGlvbnMgZm9yIG1lIG9uIGFsbCB0aGUgc2V2ZXJhbCBl LW1haWwgdGhyZWFkcy4NCjEuIEdsb2JhbCBhdHRhY2htZW50IHBvaW50DQoyLiBpY21wLW9mZg0K My4gYWNsLWFnZ3JlZ2F0ZS1pbnRlcmZhY2Ugc3RhdHMuDQoNCkZvciAoMSksIG15IGZpcnN0IHBy ZWZlcmVuY2UgaXMgdG8gaGF2ZSB0aGUgbW9kZWwgZGVmaW5lIGF0dGFjaG1lbnQgcG9pbnQgZm9y IGludGVyZmFjZXMgb25seS4NCg0KZWluYXJubj4gSSBoYXZlIHNvbWUgZGlmZnMsIGxheWVyZWQg b24gdG9wIG9mIE1haGVzaOKAmXMgUFIgdG8gbmV0bW9kLXdnL2FjbC1tb2RlbCB0aGF0IGRvIHRo aXMuIE5lYXJseSBsaWtlIHRoZSBhdWdtZW50YXRpb24gSSBoYXZlIGJlbG93LiBGZWVsIGZyZWUg dG8gdGFrZSBhIGxvb2sgYXQ6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9tamV0aGFuYW5kYW5pL2Fj bC1tb2RlbC9wdWxsLzMNCg0KSG93ZXZlciwgS3Jpc3RpYW4gd2FudHMgdGhlIGdsb2JhbCBhdHRh Y2htZW50IHBvaW50IGFzIHdlbGwgc28gdGhhdCBoZSBjYW4gYWRkIHRoZSBBQ0wgdG8gdGhlIGxp bnV4IHRhYmxlcy4NCg0KZWluYXJubj4gSSB0aGluayBLcmlzdGlhbiBkb2VzbuKAmXQgZmVlbCBh IGdsb2JhbCBhdHRhY2htZW50IHBvaW50IG5lZWRzIHRvIGJlIGluIHRoaXMgZmlyc3QgcmV2aXNp b24uIEJ1dCBoZSBjYW4gY29uZmlybS4NCg0KSWYgYW4gQUNMIGlzIGF0dGFjaGVkIGdsb2JhbGx5 LCBkb2VzIHRoaXMgbWVhbiBpdCBpcyBwZXIgZGlyZWN0aW9uIG9yIGRvZXMgaXQgbWVhbiBpdCBp cyBhY3Jvc3MgZGlyZWN0aW9ucz8NCg0KZWluYXJubj4gSSBkb27igJl0IGtub3cgcmlnaHQgbm93 IDotKQ0KDQpUaGlzIGdsb2JhbCBBQ0wgbWF5IG5vdCBiZSBhcHBsaWNhYmxlIHRvIGFueSBvZiBD aXNjbydzIHNlcnZpY2UgcHJvdmlkZXIgcm91dGVycyBhcyBJIGRvbid0IHNlZSBhbnkgcGxhdGZv cm0gYWN0dWFsbHkgcmVwbGljYXRpbmcgdGhlIEFDTCB0byBhbGwgbGluZSBjYXJkcyBhbmQgYXR0 YWNoaW5nIGl0IGluIGluZ3Jlc3MgYW5kIGVncmVzcyBkaXJlY3Rpb25zIGFjcm9zcyBhbGwgaW50 ZXJmYWNlcy4NCg0KZWluYXJubj4gUGVyIG90aGVyIGVtYWlscywgSSBkb27igJl0IHRoaW5rIHdl IHVuZGVyc3RhbmQgdGhpcyBlbm91Z2ggeWV0IHRvIHNwZWNpZnkgaXQsIHNvIEkgc3VnZ2VzdCB3 ZSBqdXN0IGxlYXZlIGl0IG91dCBmb3Igbm93LiBOb3RoaW5nIGluIHRoZSBtb2RlbCBwcmV2ZW50 cyBhIOKAnGdsb2JhbCBhdHRhY2htZW50IHBvaW504oCdIGJlaW5nIGFkZGVkIGxhdGVyIG9uY2Ug d2UgdW5kZXJzdGFuZCB3aGF0IGl0IHJlYWxseSBtZWFucy4NCg0KRm9yICgyKSwgSSBhbSBvayB3 aXRoIHJlbW92aW5nIGljbXAtb2ZmLg0KDQplaW5hcm5uPiBEb25lIGluIG15IFBSIGFib3ZlLg0K DQpGb3IgKDMpLCB0aGlzIHdvdWxkIGhhdmUgdG8gYmUgYSBjb21iaW5hdGlvbiBvZiBBQ0wgc3Rh dHMgYWNyb3NzIGFsbCBpbnRlcmZhY2VzIGZvciBhbGwgQUNMJ3MuIFNvbWV0aGluZyBsaWtlIHRo aXMgaXMgcG9zc2libGUgb24gYW4gWFIgYm94IHdoZXJlIEFDRVMgaGF2ZSBjb3VudGVyIG5hbWVz IGFzc29jaWF0ZWQgd2l0aCBpdC4gTGV0J3MgY2hhdCBhYm91dCB0aGlzIG9mZmxpbmUgdG9tb3Jy b3cuDQoNCmVpbmFybm4+IEnigJlsbCBwaW5nIHlvdSB0byBjbGFyaWZ5LCBhbmQgd2UgY2FuIGJy aW5nIGFueSBjb25jbHVzaW9uIGJhY2sgdG8gdGhlIGxpc3QuDQoNCkNoZWVycywNCg0KRWluYXIN Cg0KDQoNClNvbmFsLg0KDQoNCk9uIFdlZCwgRGVjIDEzLCAyMDE3IGF0IDEyOjEwIFBNLCBNYWhl c2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFu ZGFuaUBnbWFpbC5jb20+PiB3cm90ZToNCldlIHdhbnQgdG8gc3VwcG9ydCDigJxnbG9iYWzigJ0g YXR0YWNobWVudCBwb2ludCBkb3duIHRoZSBsaW5lLCBhbmQgdGhhdCDigJxnbG9iYWzigJ0gYXR0 YWNobWVudCBwb2ludCB3aWxsIGJlIG9uZSBvZiB0aGUgY2hvaWNlcyAodGhlIG90aGVyIGJlaW5n IHRoZSBpbnRlcmZhY2UpLCB3aGF0IHdvdWxkIHRoaXMgYXVnbWVudCBsb29rIGxpa2UuIE5vdGUs IGFzIGZhciBhcyBJIGtub3csIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUgYSBjaG9pY2Ugbm9k ZS4NCg0KT24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAo ZWluYXJubikgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdy b3RlOg0KDQpQZXJoYXBzIGxpa2UgdGhpcywgYXMgYW4gYXVnbWVudGF0aW9uIHRvIHRoZSBpbnRl cmZhY2U6DQoNCiAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2U6DQogICAgKy0t cncgaW5ncmVzcy1hY2xzDQogICAgfCAgKy0tcncgYWNsLXNldHMNCiAgICB8ICAgICArLS1ydyBh Y2wtc2V0KiBbbmFtZV0NCiAgICB8ICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAtPiAv YWNjZXNzLWxpc3RzL2FjbC9uYW1lDQogICAgfCAgICAgICAgKy0tcncgdHlwZT8gICAgICAgICAg ICAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQ0KICAgIHwgICAgICAgICstLXJvIGFjZS1zdGF0 aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/DQogICAgfCAgICAgICAgICAgKy0tcm8g bmFtZSAgICAgICAgICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL25hbWUNCiAg ICB8ICAgICAgICAgICArLS1ybyBtYXRjaGVkLXBhY2tldHM/ICAgeWFuZzpjb3VudGVyNjQNCiAg ICB8ICAgICAgICAgICArLS1ybyBtYXRjaGVkLW9jdGV0cz8gICAgeWFuZzpjb3VudGVyNjQNCiAg ICArLS1ydyBlZ3Jlc3MtYWNscw0KICAgICAgICstLXJ3IGFjbC1zZXRzDQogICAgICAgICAgKy0t cncgYWNsLXNldCogW25hbWVdDQogICAgICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAg LT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQ0KICAgICAgICAgICAgICstLXJ3IHR5cGU/ICAgICAg ICAgICAgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUNCiAgICAgICAgICAgICArLS1ybyBhY2Ut c3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pw0KICAgICAgICAgICAgICAgICst LXJvIG5hbWUgICAgICAgICAgICAgICAtPiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1l DQogICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyAgIHlhbmc6Y291bnRlcjY0 DQogICAgICAgICAgICAgICAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/ICAgIHlhbmc6Y291bnRlcjY0 DQoNCkNvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFpbmVyIGFib3ZlIGJvdGggdGhl c2UgJiByZW5hbWUg4oCcaW5ncmVzcy1hY2xzIiB0byDigJxpbmdyZXNz4oCdLCBldGMuIHRvIGdp dmUgYSBzaW5nbGUgcm9vdCBmb3IgdGhlIGF1Z21lbnRhdGlvbiBpZiBwcmVmZXJyZWQuDQoNCkNo ZWVycywNCg0KRWluYXINCg0KDQpPbiA2IERlYyAyMDE3LCBhdCAxOTo0MywgRWxpb3QgTGVhciA8 bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KDQpPbiAx Mi82LzE3IDc6MjMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6DQpIb3cgZG9lcyBvbmUg bW92ZSB0aGUgaW50ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsIGN1cnJlbnRseSBhbg0KJ2ludGVy ZmFjZS1yZWYnLCB0byBhbiBhdWdtZW50YXRpb24gb2YgdGhlIGlmOmludGVyZmFjZXMvaW50ZXJm YWNlLA0KaW5zaWRlIG9mIHRoZSDigJhhY2zigJkgIGNvbnRhaW5lcj8gRG93biB0aGUgbGluZSB3 ZSBtaWdodCBuZWVkIHRvIGhhdmUgYW4NCmNvbnRhaW5lciBmb3IgImF0dGFjaG1lbnQgcG9pbnRz IiB0byBhY2NvbW1vZGF0ZSB0aGUgcG9zc2liaWxpdHkgb2YNCmF0dGFjaGluZyBhbiBBQ0wgZWl0 aGVyIHRvIGFuIGludGVyZmFjZSBvciDigJxnbG9iYWxseeKAnS4NCg0KDQpLZWVwaW5nIGluIG1p bmQgdGhhdCBvbmUgdXNlIGlzIHRoYXQgYW4gQUNMIGRvZXNuJ3QgYXR0YWNoIHRvIGFuDQppbnRl cmZhY2UgYXQgYWxsLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYu b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWls dG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg0KDQoNCg== --_000_5299E333F1F34781B4670BFB271A4915ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <839982E199ADDB41956A3BC9EFFEEF08@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkVsaW90LA0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90aGluZyBjYW4gZm9yY2UgYW4gaW1wbGVt ZW50YXRpb24gdG8gaGF2ZSB0byBpbXBsZW1lbnQgZWl0aGVyIHRoZSZuYnNwO2lldGYtaW50ZXJm YWNlcyBtb2RlbCBvciB0aGUgYXVnbWVudGF0aW9uIGluIHRoZSBpZXRmLWFjY2Vzcy1jb250cm9s LWxpc3QgbW9kZWwuIEkgYXBwcmVjaWF0ZSB5b3VyIGRlc2lyZSBmb3IgbW9kdWxhcml0eSBhbmQg Y29oZXNpdmVuZXNzLCBidXQgSSB3b3VsZCByZXNpc3QgIzEsIGJlY2F1c2UgSSBmZWVsDQogdGhh dCB0aGUgbWFqb3JpdHkgb2YgdXNlcnMgd2lsbCBiZSB0YXJnZXRpbmcgaW50ZXJmYWNlLWJhc2Vk IGF0dGFjaG1lbnQgb3ZlciB0aW1lLiBJ4oCZdmUgYWRkZSBiYWNrIGluIHVzZSBvZiB0aGUg4oCc aW50ZXJmYWNlLWF0dGFjaG1lbnTigJ0gZmVhdHVyZSAod2hpY2ggSSB0b29rIG91dCBhcyBwYXJ0 IG9mIHJlZmFjdG9yaW5nIGludGVyZmFjZSBhdHRhY2htZW50KS4gUGFydCBvZjo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6IDBweDsiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1t b2RlbC9wdWxsLzIxIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1t b2RlbC9wdWxsLzIxPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGF1Z21lbnRzIHBhcnQgb2YgdGhl IHRyZWUgbm93IGxvb2tzIGxpa2U6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmll ciIgY2xhc3M9IiI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOjwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNscyA8YiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iI2Zm MjYwMCIgY2xhc3M9IiI+e2ludGVyZmFjZS1hdHRhY2htZW50fTwvZm9udD48L2I+PzwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IGluZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0t cncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDst Jmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBl PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9PzwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICYjNDM7LS1ybyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBlZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldCogW25hbWVd PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR5cGU/ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMv YWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIi IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0 c30/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2Uv bmFtZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xh c3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6 Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVy IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAm bmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkNoZWVy cyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+T24gMTcgRGVjIDIwMTcsIGF0IDExOjI5LCBFbGlvdCBMZWFyICZsdDs8YSBocmVm PSJtYWlsdG86bGVhckBjaXNjby5jb20iIGNsYXNzPSIiPmxlYXJAY2lzY28uY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiIgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iIj5FaW5hciw8L3A+DQo8cCBjbGFzcz0iIj5JIHRoaW5rIHRoaXMgY2hh bmdlIGlzIGZpbmUsIHdpdGggb25lIGV4Y2VwdGlvbi4mbmJzcDsgSSB3b3VsZCByYXRoZXIgdGhl IGF1Z21lbnQgdG8gdGhlIGludGVyZmFjZSBub3QgYmUgcmVxdWlyZWQgZm9yIGltcGxlbWVudGF0 aW9ucyB0aGF0IGRvbid0IGFjdHVhbGx5IGhhdmUgaW50ZXJmYWNlcy4mbmJzcDsgSSB1bmRlcnN0 YW5kIHRoYXQgdGhlcmUgbWF5IGJlIHR3byB3YXlzIHRvIGdvIGFib3V0IHRoaXM6PC9wPg0KPG9s IGNsYXNzPSIiPg0KPGxpIGNsYXNzPSIiPlNlcGFyYXRlIG91dCB0aGUgYXVnbWVudCBpbnRvIGEg c2VwYXJhdGUgbW9kdWxlIChzYW1lIGRvYyBpcyBmaW5lKTsgb3INCjwvbGk+PGxpIGNsYXNzPSIi PlNvbWVob3cgJnF1b3Q7ZmVhdHVyZS1pemUmcXVvdDsgdGhlIGF1Z21lbnQuIDwvbGk+PC9vbD4N CjxwIGNsYXNzPSIiPkkgZG9uJ3Qga25vdyBob3cgdG8gZG8gKDIpIGJ1dCBpZiB5b3UgZG8sIHRo YXQncyBva2F5IGJ5IG1lLjwvcD4NCjxwIGNsYXNzPSIiPkVsaW90PGJyIGNsYXNzPSIiPg0KPC9w Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxNi4xMi4x NyAxNDoxOSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOjBGNDNDREU5LTIx RDItNEVENy1BRTdDLTlBMkI5Rjg1NDEwMUBjaXNjby5jb20iIGNsYXNzPSIiPg0KQWxsLA0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWZ0ZXIgYSBz ZXJpZXMgb2YgZGlzY3Vzc2lvbnMgb24tIGFuZCBvZmYtbGlzdCwgSSBoYXZlIGEgY2FuZGlkYXRl IFBSIHRoYXQgaW5jbHVkZXMgdGhlIGNoYW5nZXMgaW4gdGhlIFBSIE1haGVzaCBzZW50IG91dCBw bHVzIHNvbWUgbW9yZSBlZGl0cy4gUGxlYXNlIHNlZSBjb25zb2xpZGF0ZWQgUFIgaGVyZTo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luOiAwIDAgMCA0MHB4OyBib3JkZXI6IG5vbmU7IHBhZGRpbmc6DQogICAgICAgIDBw eDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v bmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIxIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRy dWUiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjE8L2E+PC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TWFpbiBjaGFuZ2VzIGluIGFkZGl0aW9uIHRv IE1haGVzaOKAmXMgUFIgYXJlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9Ik1haWxPdXRsaW5lIj4NCjxsaSBjbGFz cz0iIj5Nb3ZlZCBpbnRlcmZhY2UgYXR0YWNobWVudCB0byBiZSB2aWEgYW4gaW50ZXJmYWNlIGF1 Z21lbnRhdGlvbi4gPC9saT48bGkgY2xhc3M9IiI+UmVzdHJ1Y3R1cmVkIHBvcnQgbWF0Y2hlcyBz bGlnaHRseSB1bmRlciBib3RoIElQdjQgYW5kIElQdjYgY29udGFpbmVycy4NCjwvbGk+PGxpIGNs YXNzPSIiPlJlbW92ZWQgdW5uZWNlc3NhcnkgaWRlbnRpdHkgJ2ludGVyZmFjZS1hY2wtYWdncmVn YXRl4oCZLiA8L2xpPjxsaSBjbGFzcz0iIj5SZW1vdmVkIGFjdGlvbiDigJhpY21wLW9mZuKAmSwg Y2FuIGJlIGF1Z21lbnRlZCBsYXRlci4gPC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Gb3IgcmVmZXJlbmNlLCBoZXJl IGlzIHRoZSBjdXJyZW50IFlBTkcgdHJlZSBwbHVzIOKAnC0taWV0ZuKAnSBsb2dzOjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPjEzOjEyICQgcHlhbmcgLS1p ZXRmIC0tbGludCAtZiB0cmVlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nPC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj5pZXRmLWFj Y2Vzcy1jb250cm9sLWxpc3QueWFuZzo1MTogZXJyb3I6IGJhZCB2YWx1ZSAmcXVvdDtZWVlZLU1N LUREJnF1b3Q7IChzaG91bGQgYmUgZGF0ZSk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPm1vZHVsZTogaWV0Zi1hY2Nlc3MtY29udHJvbC1s aXN0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2Nlc3MtbGlzdHM8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBhY2wqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7c3RyaW5nPC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgYWNsLXR5 cGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJp ZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGFjZXM8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBh Y2UqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7c3RyaW5nPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICYjNDM7LS1ydyBtYXRjaGVzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IChsMik/PC9mb250 PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5i c3A7fCAmbmJzcDsmIzQzOy0tOihldGgpPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBldGgge21hdGNoLW9uLWV0aH0/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmIzQzOy0tcncgZGVzdGluYXRpb24tbWFjLWFkZHJlc3M/ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3lhbmc6bWFjLWFkZHJlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcy1tYXNrPyAmbmJzcDsgeWFuZzpt YWMtYWRkcmVzczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFj ZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3 IHNvdXJjZS1tYWMtYWRkcmVzcz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgeWFuZzptYWMtYWRkcmVzczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7JiM0MzstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcy1tYXNrPyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt5YW5nOm1hYy1hZGRyZXNzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmIzQzOy0tcncgZXRoZXJ0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXRoOmV0aGVydHlw ZTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwOyYjNDM7LS1ydyAobDMpPzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7JiM0MzstLTooaXB2NCk8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGlwdjQge21hdGNoLW9uLWlwdjR9Pzwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBkc2NwPyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGluZXQ6ZHNjcDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyBlY24/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbGVuZ3RoPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDE2PC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR0bD8gJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7 LS1ydyBwcm90b2NvbD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNw OyAmIzQzOy0tcncgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT88L2ZvbnQ+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS06KHJhbmdlKTwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgc291cmNlLXBvcnQt bG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbmV0OnBvcnQtbnVtYmVy PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVy Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyYjNDM7LS1y dyBzb3VyY2UtcG9ydC11cHBlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlu ZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYj NDM7LS06KG9wZXJhdG9yKTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tcncgc291cmNlLW9wZXJhdG9yICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IG9wZXJhdG9yPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgfCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBzb3VyY2UtcG9ydCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6cG9ydC1udW1iZXI8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgKGRlc3RpbmF0aW9uLXBv cnQtcmFuZ2Utb3Itb3BlcmF0b3IpPzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7JiM0MzstLToocmFuZ2UpPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwOyYjNDM7LS1ydyBkZXN0aW5hdGlvbi1wb3J0LWxvd2VyICZuYnNwOyAmbmJz cDsgJm5ic3A7aW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciAmbmJzcDsg Jm5ic3A7ICZuYnNwO2luZXQ6cG9ydC1udW1iZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyB8ICZuYnNwOyYjNDM7LS06KG9wZXJhdG9yKTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsg Jm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZGVzdGluYXRpb24tb3BlcmF0b3IgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3BlcmF0b3I8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGRlc3RpbmF0aW9uLXBvcnQgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBvcnQtbnVtYmVyPC9mb250 PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5i c3A7fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGlobD8gJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt1aW50ODwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBmbGFncz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JpdHM8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tcncgb2Zmc2V0PyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDE2PC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJ3IGlkZW50aWZpY2F0aW9uPyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgZGVzdGluYXRpb24taXB2NC1uZXR3b3JrPyAmbmJzcDsg aW5ldDppcHY0LXByZWZpeDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1y dyBzb3VyY2UtaXB2NC1uZXR3b3JrPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0Omlw djQtcHJlZml4PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihpcHY2KTwvZm9udD48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tcncgaXB2NiB7bWF0Y2gtb24taXB2Nn0/PC9mb250PjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgZHNjcD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBp bmV0OmRzY3A8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9 IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBl Y24/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBsZW5ndGg/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MTY8L2Zv bnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0dGw/ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250 IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyBwcm90b2NvbD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyAoc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3Ip PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihy YW5nZSk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7fCAmbmJz cDsmIzQzOy0tcncgc291cmNlLXBvcnQtbG93ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IHNvdXJjZS1wb3J0LXVwcGVyICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsmIzQzOy0tOihvcGVyYXRvcik8L2ZvbnQ+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJz cDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncg c291cmNlLW9wZXJhdG9yICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IG9wZXJhdG9yPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNl PSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJ3IHNvdXJjZS1wb3J0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IChkZXN0aW5hdGlvbi1wb3J0LXJhbmdl LW9yLW9wZXJhdG9yKT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i c3A7JiM0MzstLToocmFuZ2UpPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIgJm5ic3A7ICZu YnNwOyAmbmJzcDtpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7JiM0MzstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OnBvcnQtbnVtYmVyPC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyYjNDM7LS06KG9wZXJhdG9yKTwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBkZXN0aW5h dGlvbi1vcGVyYXRvciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvcGVyYXRvcjwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBk ZXN0aW5hdGlvbi1wb3J0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aW5ldDpwb3J0LW51bWJlcjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29yaz8gJm5ic3A7IGluZXQ6aXB2Ni1wcmVmaXg8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBzb3VyY2UtaXB2 Ni1uZXR3b3JrPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmV0OmlwdjYtcHJlZml4PC9m b250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgZmxvdy1sYWJlbD8g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBp bmV0OmlwdjYtZmxvdy1sYWJlbDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xh c3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7LS1ydyAobDQpPzwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5i c3A7JiM0MzstLToodGNwKTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9 IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsmIzQzOy0tcncgdGNwIHtt YXRjaC1vbi10Y3B9PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIg ZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBz ZXF1ZW5jZS1udW1iZXI/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50MzI8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWNrbm93bGVkZ2VtZW50 LW51bWJlcj8gJm5ic3A7IHVpbnQzMjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYj NDM7LS1ydyBkYXRhLW9mZnNldD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0t cncgcmVzZXJ2ZWQ/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0t cncgZmxhZ3M/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JpdHM8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm b250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNw OyAmIzQzOy0tcncgd2luZG93LXNpemU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3VpbnQxNjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICYj NDM7LS1ydyB1cmdlbnQtcG9pbnRlcj8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB1aW50MTY8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9 IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgb3B0aW9u cz8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt1aW50MzI8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyYjNDM7LS06KHVkcCk8L2ZvbnQ+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZu YnNwO3wgJm5ic3A7JiM0MzstLXJ3IHVkcCB7bWF0Y2gtb24tdWRwfT88L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNw O3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgbGVuZ3RoPyAmbmJzcDsgdWludDE2PC9mb250Pjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 fCAmbmJzcDsmIzQzOy0tOihpY21wKTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg Y2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncg aWNtcCB7bWF0Y2gtb24taWNtcH0/PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmIzQzOy0tcncgdHlwZT8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgdWludDg8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9 IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBj b2RlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50ODwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHJlc3Qtb2YtaGVhZGVy PyAmbmJzcDsgdWludDMyPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGVncmVzcy1pbnRlcmZhY2U/ICZuYnNw OyAmbmJzcDtpZjppbnRlcmZhY2UtcmVmPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGluZ3Jlc3MtaW50ZXJm YWNlPyAmbmJzcDsgaWY6aW50ZXJmYWNlLXJlZjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgYWN0aW9uczwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYj NDM7LS1ydyBmb3J3YXJkaW5nICZuYnNwOyAmbmJzcDtpZGVudGl0eXJlZjwvZm9udD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyYjNDM7 LS1ydyBsb2dnaW5nPyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lkZW50aXR5cmVmPC9mb250PjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBz dGF0aXN0aWNzIHthY2wtYWdncmVnYXRlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ybyBt YXRjaGVkLXBhY2tldHM/ICZuYnNwOyB5YW5nOmNvdW50ZXI2NDwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzst LXJvIG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPjxiciBjbGFz cz0iIj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0i Q291cmllciI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOjwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5i c3A7ICZuYnNwOyAmIzQzOy0tcncgYWNsczwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IGluZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIi IGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7JiM0Mzst LXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBm YWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsg JiM0MzstLXJ3IGFjbC1zZXQqIFtuYW1lXTwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbmFtZSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC9u YW1lPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3Vy aWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ybyBhY2Utc3RhdGlzdGlj cyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9PzwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ybyBuYW1lICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNz LWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtcGFja2V0 cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIG1hdGNoZWQtb2N0ZXRz PyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyYjNDM7LS1ydyBlZ3Jlc3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNz PSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0 MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0i IiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBuYW1lICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlz dHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZh Y2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJiM0MzstLXJ3IHR5cGU/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGU8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJvIGFjZS1z dGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/PC9mb250PjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0t cm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg LSZndDsgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZTwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzst LXJvIG1hdGNoZWQtcGFja2V0cz8gJm5ic3A7IHlhbmc6Y291bnRlcjY0PC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm IzQzOy0tcm8gbWF0Y2hlZC1vY3RldHM/ICZuYnNwOyAmbmJzcDt5YW5nOmNvdW50ZXI2NDwvZm9u dD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Q29tbWVudHMgd2VsY29tZSE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5F aW5hcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pk9uIDE0IERlYyAyMDE3LCBhdCAxODo1MCwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4p ICZsdDs8YSBocmVmPSJtYWlsdG86ZWluYXJubkBjaXNjby5jb20iIGNsYXNzPSIiIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSI+ZWluYXJubkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxi ciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZToNCiAgICAg ICAgICAgICAgICBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDE0IERlYyAyMDE3LCBh dCAwODoyMSwgU29uYWwgQWdhcndhbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhZ2Fyd2FsMTJAZ21h aWwuY29tIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPnNhZ2Fyd2FsMTJAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhpIEVpbmFy LA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WW91 IGhhZCAzIHF1ZXN0aW9ucyBmb3IgbWUgb24gYWxsIHRoZSBzZXZlcmFsIGUtbWFpbCB0aHJlYWRz LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLiBHbG9iYWwgYXR0YWNobWVudCBwb2ludDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4yLiBpY21wLW9mZjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4zLiBh Y2wtYWdncmVnYXRlLWludGVyZmFjZSBzdGF0cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkZvciAoMSksIG15IGZpcnN0IHByZWZlcmVu Y2UgaXMgdG8gaGF2ZSB0aGUgbW9kZWwgZGVmaW5lIGF0dGFjaG1lbnQgcG9pbnQgZm9yIGludGVy ZmFjZXMgb25seS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5laW5hcm5uJmd0OyBJ IGhhdmUgc29tZSBkaWZmcywgbGF5ZXJlZCBvbiB0b3Agb2YgTWFoZXNo4oCZcyBQUiB0byBuZXRt b2Qtd2cvYWNsLW1vZGVsIHRoYXQgZG8gdGhpcy4gTmVhcmx5IGxpa2UgdGhlIGF1Z21lbnRhdGlv biBJIGhhdmUgYmVsb3cuIEZlZWwgZnJlZSB0byB0YWtlIGEgbG9vayBhdDo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW46IDAgMCAwIDQwcHg7IGJvcmRlcjogbm9uZTsNCiAgICAgICAgICAgICAgICAgIHBh ZGRpbmc6IDBweDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9tamV0aGFuYW5kYW5pL2Fj bC1tb2RlbC9wdWxsLzMiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly9n aXRodWIuY29tL21qZXRoYW5hbmRhbmkvYWNsLW1vZGVsL3B1bGwvMzwvYT48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Ib3dldmVyLCBLcmlzdGlhbiB3YW50cyB0aGUgZ2xvYmFs IGF0dGFjaG1lbnQgcG9pbnQgYXMgd2VsbCBzbyB0aGF0IGhlIGNhbiBhZGQgdGhlIEFDTCB0byB0 aGUgbGludXggdGFibGVzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmVpbmFybm4m Z3Q7IEkgdGhpbmsgS3Jpc3RpYW4gZG9lc27igJl0IGZlZWwgYSBnbG9iYWwgYXR0YWNobWVudCBw b2ludCBuZWVkcyB0byBiZSBpbiB0aGlzIGZpcnN0IHJldmlzaW9uLiBCdXQgaGUgY2FuIGNvbmZp cm0uPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+SWYgYW4gQUNMIGlzIGF0dGFjaGVkIGdsb2JhbGx5LCBkb2VzIHRoaXMgbWVhbiBpdCBpcyBw ZXIgZGlyZWN0aW9uIG9yIGRvZXMgaXQgbWVhbiBpdCBpcyBhY3Jvc3MgZGlyZWN0aW9ucz88L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5laW5hcm5uJmd0OyBJIGRvbuKAmXQga25vdyBy aWdodCBub3cgOi0pPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+VGhpcyBnbG9iYWwgQUNMIG1heSBub3QgYmUgYXBwbGljYWJsZSB0byBhbnkg b2YgQ2lzY28ncyBzZXJ2aWNlIHByb3ZpZGVyIHJvdXRlcnMgYXMgSSBkb24ndCBzZWUgYW55IHBs YXRmb3JtIGFjdHVhbGx5IHJlcGxpY2F0aW5nIHRoZSBBQ0wgdG8gYWxsIGxpbmUgY2FyZHMgYW5k IGF0dGFjaGluZyBpdCBpbiBpbmdyZXNzIGFuZCBlZ3Jlc3MgZGlyZWN0aW9ucyBhY3Jvc3MgYWxs IGludGVyZmFjZXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZWluYXJubiZndDsg UGVyIG90aGVyIGVtYWlscywgSSBkb27igJl0IHRoaW5rIHdlIHVuZGVyc3RhbmQgdGhpcyBlbm91 Z2ggeWV0IHRvIHNwZWNpZnkgaXQsIHNvIEkgc3VnZ2VzdCB3ZSBqdXN0IGxlYXZlIGl0IG91dCBm b3Igbm93LiBOb3RoaW5nIGluIHRoZSBtb2RlbCBwcmV2ZW50cyBhIOKAnGdsb2JhbCBhdHRhY2ht ZW50IHBvaW504oCdIGJlaW5nIGFkZGVkIGxhdGVyIG9uY2Ugd2UgdW5kZXJzdGFuZCB3aGF0IGl0 IHJlYWxseSBtZWFucy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5Gb3IgKDIpLCBJIGFtIG9rIHdpdGggcmVtb3ZpbmcgaWNtcC1vZmYuPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZWluYXJubiZndDsgRG9uZSBpbiBteSBQUiBh Ym92ZS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5Gb3IgKDMpLCB0aGlzIHdvdWxkIGhhdmUgdG8gYmUgYSBjb21iaW5hdGlvbiBvZiBBQ0wg c3RhdHMgYWNyb3NzIGFsbCBpbnRlcmZhY2VzIGZvciBhbGwgQUNMJ3MuIFNvbWV0aGluZyBsaWtl IHRoaXMgaXMgcG9zc2libGUgb24gYW4gWFIgYm94IHdoZXJlIEFDRVMgaGF2ZSBjb3VudGVyIG5h bWVzIGFzc29jaWF0ZWQgd2l0aCBpdC4gTGV0J3MgY2hhdCBhYm91dCB0aGlzIG9mZmxpbmUgdG9t b3Jyb3cuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ZWluYXJubiZndDsgSeKAmWxs IHBpbmcgeW91IHRvIGNsYXJpZnksIGFuZCB3ZSBjYW4gYnJpbmcgYW55IGNvbmNsdXNpb24gYmFj ayB0byB0aGUgbGlzdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5Tb25hbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBEZWMgMTMsIDIwMTcgYXQgMTI6MTAgUE0s IE1haGVzaCBKZXRoYW5hbmRhbmkgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0 Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDpicmVhay13b3JkIiBjbGFzcz0iIj5XZSB3YW50IHRvIHN1cHBvcnQg4oCc Z2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgZG93biB0aGUgbGluZSwgYW5kIHRoYXQg4oCcZ2xv YmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgd2lsbCBiZSBvbmUgb2YgdGhlIGNob2ljZXMgKHRoZSBv dGhlciBiZWluZyB0aGUgaW50ZXJmYWNlKSwgd2hhdCB3b3VsZCB0aGlzIGF1Z21lbnQgbG9vayBs aWtlLiBOb3RlLCBhcyBmYXIgYXMgSSBrbm93LA0KIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUg YSBjaG9pY2Ugbm9kZS4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iaDUiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3IEFN LCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikgJmx0OzxhIGhyZWY9Im1haWx0bzplaW5h cm5uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+ZWluYXJubkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i bV83MTAyNDA4OTA3NTMzMDE3NTAxQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7bGluZS1icmVhazphZnRl ci13aGl0ZS1zcGFjZSIgY2xhc3M9IiI+UGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRh dGlvbiB0byB0aGUgaW50ZXJmYWNlOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmll ciI+Jm5ic3A7IGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlOjwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIg ZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmIzQzOy0tcncgaW5ncmVzcy1hY2xzPC9mb250 PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFz cz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7JiM0MzstLXJ3IGFjbC1z ZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNw OyAmIzQzOy0tcncgYWNsLXNldCogW25hbWVdPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IG5hbWUgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZndDsgL2FjY2Vz cy1saXN0cy9hY2wvbmFtZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyB8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtJmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBl PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9u dCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7JiM0MzstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1z dGF0c30/PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbmFtZSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSZndDsgL2FjY2Vzcy1saXN0cy9hY2wv YWNlcy9hY2UvPHdiciBjbGFzcz0iIj5uYW1lPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8g bWF0Y2hlZC1wYWNrZXRzPyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LS1ybyBtYXRjaGVkLW9jdGV0cz8gJm5ic3A7ICZuYnNwO3lhbmc6Y291bnRlcjY0PC9m b250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBj bGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBlZ3Jlc3MtYWNs czwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGZv bnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0 MzstLXJ3IGFjbC1zZXRzPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS1ydyBhY2wtc2V0KiBbbmFtZV08L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZh Y2U9IkNvdXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS1ydyBuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOy0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWU8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7LS1ydyB0eXBlPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAt Jmd0OyAvYWNjZXNzLWxpc3RzL2FjbC90eXBlPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjbGFzcz0iIiBmYWNlPSJDb3VyaWVyIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcm8gYWNl LXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRzfT88L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNv dXJpZXIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJiM0MzstLXJvIG5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0mZ3Q7IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlLzx3YnIgY2xhc3M9 IiI+bmFtZTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGZvbnQgY2xhc3M9IiIgZmFjZT0iQ291cmllciI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tcm8gbWF0Y2hlZC1wYWNrZXRz PyAmbmJzcDsgeWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNsYXNzPSIiIGZhY2U9IkNvdXJpZXIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLXJv IG1hdGNoZWQtb2N0ZXRzPyAmbmJzcDsgJm5ic3A7eWFuZzpjb3VudGVyNjQ8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkNvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFpbmVy IGFib3ZlIGJvdGggdGhlc2UgJmFtcDsgcmVuYW1lIOKAnGluZ3Jlc3MtYWNscyZxdW90OyB0byDi gJxpbmdyZXNz4oCdLCBldGMuIHRvIGdpdmUgYSBzaW5nbGUgcm9vdCBmb3IgdGhlIGF1Z21lbnRh dGlvbiBpZiBwcmVmZXJyZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWluYXI8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5PbiA2IERlYyAyMDE3LCBhdCAxOTo0MywgRWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmxlYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiIgbW96LWRvLW5vdC1zZW5k PSJ0cnVlIj5sZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJt XzcxMDI0MDg5MDc1MzMwMTc1MDFBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDEy LzYvMTcgNzoyMyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Ib3cgZG9lcyBvbmUgbW92ZSB0aGUgaW50 ZXJmYWNlIGF0dGFjaG1lbnQgcG9pbnQsIGN1cnJlbnRseSBhbjxiciBjbGFzcz0iIj4NCidpbnRl cmZhY2UtcmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZSBpZjppbnRlcmZhY2VzL2ludGVy ZmFjZSw8YnIgY2xhc3M9IiI+DQppbnNpZGUgb2YgdGhlIOKAmGFjbOKAmSAmbmJzcDtjb250YWlu ZXI/IERvd24gdGhlIGxpbmUgd2UgbWlnaHQgbmVlZCB0byBoYXZlIGFuPGJyIGNsYXNzPSIiPg0K Y29udGFpbmVyIGZvciAmcXVvdDthdHRhY2htZW50IHBvaW50cyZxdW90OyB0byBhY2NvbW1vZGF0 ZSB0aGUgcG9zc2liaWxpdHkgb2Y8YnIgY2xhc3M9IiI+DQphdHRhY2hpbmcgYW4gQUNMIGVpdGhl ciB0byBhbiBpbnRlcmZhY2Ugb3Ig4oCcZ2xvYmFsbHnigJ0uPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KS2VlcGluZyBpbiBtaW5kIHRo YXQgb25lIHVzZSBpcyB0aGF0IGFuIEFDTCBkb2Vzbid0IGF0dGFjaCB0byBhbjxiciBjbGFzcz0i Ij4NCmludGVyZmFjZSBhdCBhbGwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPHdiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fXzxi ciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJt YWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiIgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY2xhc3M9IiIgY29s b3I9IiM4ODg4ODgiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TWFoZXNoIEpldGhh bmFuZGFuaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFu aUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRy dWUiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX188d2JyIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fPGJy IGNsYXNzPSIiPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bmV0 bW9kQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vPHdiciBjbGFzcz0iIj5saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bmV0bW9kQGll dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kIiBjbGFzcz0iIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjxmaWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1lbnRIZWFkZXIiPjwv ZmllbGRzZXQ+IDxiciBjbGFzcz0iIj4NCjxwcmUgd3JhcD0iIiBjbGFzcz0iIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlz dA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm5ldG1v ZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1m cmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPg0KPC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_5299E333F1F34781B4670BFB271A4915ciscocom_-- From nobody Sun Dec 17 08:58:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6D126579; Sun, 17 Dec 2017 08:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 UQuXuw1L0fs3; Sun, 17 Dec 2017 08:58:02 -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 E3BC51200F1; Sun, 17 Dec 2017 08:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3052; q=dns/txt; s=iport; t=1513529881; x=1514739481; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OzqGshuQGjrCiskSOW0KitWKF0DkoSuPiGhlG0VBGgY=; b=SEl+IrOsjpuQy4wI6pBtbxgeq6UoKrE5iQC19sPhHcJTX347PlVj3wZ5 HEWV+vT22DCH3fFZB/0bkONnvJFMpSQMka0FMimzKsDTKAtkCEJdQz6fd IXd0CPFqN+3J2GIkXyuWfXTnYjzcZwGX5M2kAb7HnAiGE33xP9MzaIN2n I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AABXoTZa/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N/iiGPCYIAlyGCFQoYDYRHTwIahGY/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSQBAQQBASEROgsQAgEIDgoCAiYCAgIlCxUQAgQBDQWKKhCoV4InimYBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgl+CDoM/gyyDLgEYgW2CfoJjBaM8Aod?= =?us-ascii?q?9jS2CFoYTi0qKTYJOiTACERkBgToBHzmBT28VPIIphFZ4AYkqgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,417,1508803200"; d="scan'208";a="327240886" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Dec 2017 16:58:00 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBHGw0gV020188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 17 Dec 2017 16:58:00 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; Sun, 17 Dec 2017 11:57:59 -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, 17 Dec 2017 11:57:59 -0500 From: "Acee Lindem (acee)" To: Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-01 Thread-Index: AQHTdecPhSAo6kKOv0CHaR8SVGCwjKNHxIIA Date: Sun, 17 Dec 2017 16:57:59 +0000 Message-ID: References: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net> <44e5318a-4157-b825-b688-5185ab2458cb@labn.net> In-Reply-To: <44e5318a-4157-b825-b688-5185ab2458cb@labn.net> 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: <409701999A65DA4F8FDA64E6E94D7144@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-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, 17 Dec 2017 16:58:04 -0000 SGkgTG91LCBldCBhbCwgDQoNClRoZSBvbmx5IGlzc3VlIHdlIGFyZSBzdHJ1Z2dsaW5nIHdpdGgg aXMgd2hldGhlciB3ZSBuZWVkIHRvIHNwZWNpZnkgdGhlDQp2ZXJzaW9uIGluIHRoZSBpZXRmLWlu dGVyZmFjZXMgaW1wb3J0LiBXZSBoYXZlIG5vdGVkIHRoYXQNCmRyYWZ0LWlldGYtbmV0bW9kLXJm YzcyNzdiaXMtMDEudHh0IGRvZXMgbm90IGltcG9ydCBieSByZXZpc2lvbi4NCg0KV2UgYWxzbyBo YXZlIHNvIG5pdHM6DQoNCiAgIDEuIEFkZCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgZm9yDQpb SS1ELmlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10uDQogICAyLiBCYXNlZCBvbiBhIGNv bW1lbnQgZnJvbSBWbGFkaW1pciwgd2UgYWRkZWQgdGhlIHByZWZpeCBmb3INCmlldGYtcm91dGlu Zy55YW5nLCDigJxydDrigJ0sIHRvIHNldmVyYWwgcmVmZXJlbmNlcyB3aXRoaW4gaWV0Zi1yb3V0 aW5nLnlhbmcuDQpXYXMgdGhpcyBuZWNlc3Nhcnk/IE9mIGNvdXJzZSwgdGhlIG1vZGVsIGNvbXBp bGVzIHdpdGggb3Igd2l0aG91dCB0aGUNCnByZWZpeC4gDQoNClRoYW5rcywNCkFjZWUNCg0KT24g MTIvMTUvMTcsIDM6NTUgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExvdSBCZXJnZXIiDQo8bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxiZXJnZXJAbGFibi5uZXQ+IHdyb3Rl Og0KDQo+QWxsLA0KPglUaGlzIGxhc3QgY2FsbCBpcyBjbG9zZWQuDQo+DQo+V2Ugbm90ZSB0aGF0 IHRoZXJlIHdhcyBhbiB1cGRhdGUgZHVyaW5nIHRoZSBMQyBhbmQgdGhhdCBubyBjb21tZW50cyB3 ZXJlDQo+cmVjZWl2ZWQgZHVyaW5nIHRoZSBMQyBwZXJpb2QuICBBcyB0aGlzIGlzIHNpbXBseSBh IG1lY2hhbmljYWwgdXBkYXRlDQo+dGhhdCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIFdHIHdl IHBsYW4gdG8gcHJvY2VlZCB3aXRoIHRoZQ0KPnB1YmxpY2F0aW9uIHByb2Nlc3MuDQo+DQo+QXV0 aG9ycywNCj4JUGxlYXNlIGxldC91cyB0aGUgV0cga25vdyB3aGVuIHlvdSBoYXZlIHB1Ymxpc2hl ZCBhIHZlcnNpb24gcmVhZHkgZm9yDQo+cHVibGljYXRpb24uICBBbHNvIHBsZWFzZSBsZXQgdGhl IFdHIGtub3cgd2hhdCBoYXMgY2hhbmdlZCBpbiB0aGUNCj5kb2N1bWVudCBzaW5jZSB0aGUgc3Rh cnQgb2YgTEMgKHJldiAtMDEpDQo+DQo+VGhhbmsgeW91LA0KPk5ldE1vZCBDaGFpcnMNCj4NCj4N Cj4NCj5PbiAxMS8yOS8yMDE3IDEyOjI2IFBNLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPj4gQWxsLA0K Pj4gDQo+PiBUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u DQo+PiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlzLTAxLg0KPj4gDQo+PiBQbGVhc2UgcmVj YWxsIHRoYXQgdGhpcyB1cGRhdGUncyBpbnRlbnRpb24gaXMgdG8NCj4+IG1vZGlmeSB0aGUgWUFO RyBtb2R1bGUgdG8gYmUgaW4gbGluZSB3aXRoIHRoZSBOTURBDQo+PiBndWlkZWxpbmVzIFsxXS4g IFJldmlld2luZyB0aGUgZGlmZiBiZXR3ZWVuIHRoZSB0d28NCj4+IGRyYWZ0cyBbMl0gc2hvdWxk IHJldmVhbCBqdXN0IHRoaXMuDQo+PiANCj4+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBl bmRzIG9uIERlY2VtYmVyIDEzLg0KPj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUg bmV0bW9kIG1haWxpbmcgbGlzdC4NCj4+IA0KPj4gUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJ J3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQNCj4+IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZv ciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KPj4gVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9y dGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuDQo+PiANCj4+IFsxXSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDENCj4+IFsyXSANCj4+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdkaWZmJnVybDE9cmZjODAyMi50 eHQmdXJsMj1kcg0KPj5hZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0wMS50eHQNCj4+IA0KPj4g VGhhbmsgeW91LA0KPj4gTmV0bW9kIENoYWlycw0KPj4gDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0 bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg0K From nobody Sun Dec 17 12:33:23 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E24124D37; Sun, 17 Dec 2017 12:33:22 -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_H4=-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 45xnLKirOlWl; Sun, 17 Dec 2017 12:33:19 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00110.outbound.protection.outlook.com [40.107.0.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E613124B0A; Sun, 17 Dec 2017 12:33:18 -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=YiFbEBqZ5y0BEoQtQ/E9O4PQpHFdYydVLD0+VZlhJsk=; b=cUNXmO0TpktUsT2Ha/tZ/pSFYPTrlm4/szyelj1MB28OgvMwdrQDCvXD6jTCu0dfVsKpozBFZ+KH/B26RB3w/zC53h52ZbyMOsnpZ4VgP5f01HRkZytKNZfzQ/QA3lvfyjGMnJ69U4ZRJUm4r2DlEQN4zCvam43WEMIL+aA2srQ= 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.345.10; Sun, 17 Dec 2017 20:33:14 +0000 Message-ID: <00f801d37775$b508ad00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Clyde Wildes \(cwildes\)" , "Benoit Claise \(bclaise\)" , "Kent Watsen" , Cc: References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net> <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net> <5CE9EE07-D75D-4E5C-BC70-1F969732A526@juniper.net> <8e873d52-a6bd-87ee-9ff5-62c85eb5b6dc@cisco.com> <8015AC50-45CE-4813-B77B-8D1D3D3BC349@cisco.com> <004401d374d1$e1fb3540$4001a8c0@gateway.2wire.net> <872D5B29-8411-44AE-BAD2-BAA7D1F50F7B@cisco.com> Date: Sun, 17 Dec 2017 20:29:05 -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: DB6PR0501CA0012.eurprd05.prod.outlook.com (2603:10a6:4:8f::22) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 54ae2d84-47d8-4040-2ec9-08d5458d6625 X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603307)(7153051); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:RBpuJY8dEKNwU3wxiT29KYnU/blNNPjZKBS3caJ2f7DqOGFIUrR7FkzTCNpUCUWFnsj2ihxcyJprfj5CnS2cbfRxS6XAKE3Egq8ld9hPSl8q2hgnU4otxHJJRBnRB3DKYXqXpb6q/gIqG/tG2dWuP9h5uBqbkg8vBJSE8dk7ucIzw/UiTBQyl6z61nnK6KYSOYnTjrKobyD2PHBW+YGapL+klOOz/Wmcfg8RHIn5548YKul+Sb1LVmWywTcjcBayeKlesyJ2tQqtR20pMaFue/sGStrrAK0hQkacnjwY4cI=; 25:1gGA4U12F/eXPCL1wh0j26TsqpE8ZBIN7crDgDGEb5We+K3bN1LGLpmiCiaqmMGRSl7ApAmJ8XT6RGdo29Kb4EZGbqfZiStBcsUolwrsv1cATEKv7w3NTVq9lVd6ahTl7ga43M8beYxQEFK4ADzNC8aurlpSqYxFJ8MXcEqNqeqZi8DQf6PcOo3pKD6U5ijQ4jGERcdYJ7p8p1UsH574IS1jkt2ZBXRqFKsbAYUF71eAqx0k2tCJ1bptBR7bFGwyvu+K57cY3tY+tksb80prh/xI7Ziq3HxW/ZnrWFDZMCv9As/p6QReDapQV133bgp6+uyvVt5TXvx6h/j6616gEA==; 31:GXmKi/izu3z5Pnb7ivhLEEWodIOCtK32cpMZoMJ4ACU+VPk2krObBJmc5ooSjDs042RdSmjikxsmwX0krcUbZpVOvWvpqxTteESgaDj0FDQOyl44erCVxmOJFvZcc/jRKJLs9s+WUi1iP6PTLEOtqviZdOuTDhHiQOKYV8LGyEvIWaU1GhZ0vhMSqJAWmvtrcUlbc2U0nagRnBefS/hezzFve36M0aQOiFxNXR8+Iew= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231023)(10201501046)(93006095)(93001095)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:3CrBUoI2Qbr249OpWM3/l3mYty16u7TjuwUi+N/YtuS4H8cW0MQ3oAC5h5wJ/FclCXdIa5HQeCRs7iAVuQfIP+JuxzpTz2dX4VHaGsbaYo9eLf2b3kQAXc9Ch8SkBcnS68tfdDVmPgaPD10XPs6HegvRSLT+bZMoYomFcKsZzsh2INhPeV3XeZO9v1RZ9YRlkRYoVTJUPZagZlBgg6+9GCp27ZjXAUk5TRrTUY+imTQb9aMd9epeMAPl/f0F9gNguxIsnncVkbSwoPhR+6Va19E901QATNR+wcNFHg52BU2FsowM0XADmpLrft1XcfJU/asNO034PRLqp7R/ww4AcbxT/brO7nwGznz1dcZ3JnXH5kf0c4OnSyUcae2Mb2lA X-Forefront-PRVS: 05245CA661 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(396003)(376002)(366004)(13464003)(53474002)(57704003)(189003)(24454002)(51444003)(199004)(14496001)(6116002)(50466002)(59450400001)(110136005)(478600001)(966005)(86362001)(575784001)(116806002)(44736005)(229853002)(93886005)(6306002)(8676002)(81166006)(81156014)(106356001)(105586002)(6486002)(8666007)(3846002)(1556002)(230783001)(9686003)(7736002)(305945005)(316002)(5660300001)(53936002)(6246003)(4326008)(84392002)(4720700003)(6666003)(1456003)(52116002)(2486003)(62236002)(2870700001)(47776003)(44716002)(76176011)(81816011)(386003)(66066001)(53546011)(25786009)(81686011)(6496006)(23676004)(68736007)(1941001)(61296003)(8936002)(16526018)(33896004)(2906002)(97736004)(50226002)(116284003)(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) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDI7MjM6SytwdnlrUDlqZ1dFN1BhZ0Z3YWJjYkg4?= =?utf-8?B?RlhmMEE3YkgrSjZWZXNOMzVZQ2h2RjB5RC94ZEJQbEZxd1Nrc0t3K1c4S05X?= =?utf-8?B?c3pjTEZpODhETjU1VWlYYnVGQ2N1YVpieldpWDRZV3ozYXR4ZjNOSlVHN0RE?= =?utf-8?B?dVI2WDY2SjFab0V2Unh5WFBHbzhzcmlNUUJGREUrdmo4aWRUZDQrbTJ1eGZE?= =?utf-8?B?V3k2elNzdnEzQzhCTFdraHMvQkFVei9ZMUtLU0N3TEdXMmMxZ25LNWQ2WWZk?= =?utf-8?B?a1hBamR4dUF5OEVSUGo1aVk5K3FaMmNkcmowYTlXRjRra2UrakdaMlVoYi8w?= =?utf-8?B?L044Wjc5UmNoOVpiRGlmTWdOajdGaTZsQTZibjV4VXRYc3I5OUxlSWdVaFJO?= =?utf-8?B?Z1dIMTZ1MGFKQzFPMVJtWXgzdlNFdy9wOVFRUWpDM05mOUUrNjhMTjFJNldY?= =?utf-8?B?cEtYNXR3ME5CRUFMMkhrbmpNYUo0UXJUYmhyM1RSVGM3aWpWMlFLbnpsWkRu?= =?utf-8?B?TkpYbTVKRThZVWdTTkd0Y1E3bEdDM3I2dGt5NGd4Rkkrci9pSE02RFVJSFZj?= =?utf-8?B?UzRVV0ZNY1hkVHpJWDNoYnNsejVsWndlT3MxVGh5RkM1dCtJalE2MEpEUEUw?= =?utf-8?B?YTVBVnRFODdIcFRoWUxGcDArTmlNdUZHU0pUWjJYeFY2RmdHQ0w0NWxMMkVV?= =?utf-8?B?QTJGUXQzTjllLzY1bUxUM2JiclNmZ2tvSkZvUEtlbUp2NFdIemhWYlYzRlhU?= =?utf-8?B?OVlKUXdaWmx3TVJFVVBTTVd1aXZuZlNiOERjZ3dFUWpUNnlDeWQzWUs0UFI5?= =?utf-8?B?RmY4UXgwVlUxVVBjVm9IZ0NkR3dkTWRMU3ZyTkdOL3BxY3ZPVTh4Vm45cWxS?= =?utf-8?B?aVFnZFRCRnNBblRsbFhwTTY3RU5ncEFlOGNCb1ZWTWd3eEh3eHRPaUw3VDl3?= =?utf-8?B?cWVKb0I4V1NSU2dkNkZPK2tRMUJqUkFWWm44RWpGMFRLTlk2Mmt2b1ZDZ3lv?= =?utf-8?B?RkdEUFNHaG1wTTJvbzdsM2ovb1V5ZWFRc0g2NDRGNEJUK3JWYTk1c2FMZmR6?= =?utf-8?B?d3FyYkVyMXdkK1VzVHkvM2VkanAvZ2Z6S05mVXlEbHRYVU1HT1d0THRrMS9Z?= =?utf-8?B?Z29DYmllSUZ5c1pXNm1pR2s4NklhSTBydEJsaUk5OWhOR2FmaklNQ1VPWGJN?= =?utf-8?B?dkZEVlJ0UC9DNUczU0RTV3JHSnNOVTlUdG83NFNWTEFUUGttb1liNWNyMG1Y?= =?utf-8?B?bXNJSVk3bEZHSnFFc2FGcXRxck1zMTJ2aU8xbjIybyttMlJ0VXNjZDB6Q095?= =?utf-8?B?NVlsV3FtNDRDZnF4anFVbUxJdkhPSFBuWTl1NC9FNWtLTUxDenFXcEtIS1Zo?= =?utf-8?B?RkNOckpTR0cxWjJEUmNyL0xFQTVFMkZsM0lIcTBUN214NVZVMWNFRWg1cURD?= =?utf-8?B?ZDlaSytpT1hNbFNJalhRR3kvR090c0hJL0ZYTldJUnRIcnYwUVZkK2hQb3N6?= =?utf-8?B?dzVBaEF5bHJKMGdLbmdMMHY4MG5PYlg1VGsrL1VQK3hTekJuOVRWYkxjRjli?= =?utf-8?B?OEEwSTIyaStrV0EwSmY2dThTb0dsNDFwMFpBWlh6dVA1Um85eWRlRWJ6TnpV?= =?utf-8?B?MTN5NmxWN25QdFdOODRiMzhQNXcrYUoyWW5YSkoyNWVrY0I2bytjMGQxaUdL?= =?utf-8?B?a3pVUlhlbGhNelk0aCtsWlcya2xWUSt3VUd5cDZkQnk2ZnYveUJKWTRuZk9h?= =?utf-8?B?aVEwNndlNkUreG1OVHZqZEt1N2hJUUpXMkp1VTdoR25tMnQzam5aRWsrWmpN?= =?utf-8?B?TVF5Q3BEZ2hkV1F3TzRqbHdscGJTTHpEVkRNdi9GSmZtdW5yZS9scU1WdjlX?= =?utf-8?B?aUdUM3R1anZIZ0sxai9nUWRVVzRBK0lyY2Y3ZnVzNHVyWWdza01jMU5uRXZv?= =?utf-8?B?NmVWU21RRmlNRmFBSmp4SWhnaENRNzd4QmY3a1hyN3ZLSVZ3YUUrS2NzbnlY?= =?utf-8?B?eVM2WG1iOGR2YzVyVVorZU5sNkZJVTRpMjBkY2JUSUduSTViVTg0bUpMWkQ1?= =?utf-8?B?dW05ME9RSnF5R2EyaGpLNHpVVzJHeVdQMkcrSU5zd1kxTjNET2RXZkt3VjNk?= =?utf-8?B?RXhCVjAvblFQYTJWaGo5cGJPeDFEQmMrRzY2c3BndGVBZCtRVEptNVppZ0FL?= =?utf-8?B?b2Q3WHhLNkxvYTNITFMwRmNiT0JETjVyTXh6ZXkwMEhGRTNuem1CT2lrcDNW?= =?utf-8?B?ckoxcjVuMVBOZnk4bUpzcmk5QVZZTG1XVEJvbFVJYzRUOXFKallIc0NRPT0=?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:0/nycMlotd6xeluxcJp0Z4mgG9qiZq78QP4lun6FSQuZb80ajaX8iAfnzUX4mN9C9+chk30svCnrwQ8F/eArNR5aFINRXQs6VxynFkS3QEHy14TMnOmzBqWsNskfl9lOYtdG42ffxnswTIl0sAkKYETFRS62PSXVxZC4XCB6zCWzyhKaYZJOb4LIYapObBIRO4ucNlX3Nl2lGNVJU13rfTfOrxbmtREPgmVaTnNSxMJwNTBbVuGaoSbKq+qFWlMGlwqQy6Tzr6axKtOqd1lKrK/c8ktFQb6JbjxjLavCDxxffjoNs7uKKk3m54Iq9AJXnL/5gdsjuMrglP00Q7R7XaZfK2Brm/EILtC3YLygaFI=; 5:KWsiKc0hWnYLcA+cSW1weeLrwweWE6N8MVw71xAGQY3O+vjobfCphHxytIw7f8+Hb8TQPwf63m8+vTlOhNjZmVdshBWQ42daTuHXfYZW/s6+oUdh/oKLev1ubAc5jLUc7a9iLtqHQlK1Np/PBmzDgcrqge2b8QiUeDTdww/ERgg=; 24:0lPtx8nJGGBYcp28dzqapbGH1cGUxf76mlub7Dl+Cx9OYAe9Y5xaDkPoWqySSVtFxRp2zWSG9BK5/TRasjffpYEO2Afv64qTIbJHKu3UJ3k=; 7:U5QURb5WtSmEH27ahr+DCcfsnrpmHwgH9hBKoIV2dKOx5FEcDGMZjJL7p9PWfcCLP8hgKOIGTTsPjIREtEpMp9NyysIlyQnF0AF16NL9ecGdwVp/m3rnUtZ33DGg5lTjlKYqLXbaZ1H7+HF4ifFdW+wftWqkMWrOx3n8XZNmWLU6aokYbs374zJjxiC43mYUj4SDa34FK0F00aysjFmvi2c6GNqCBq/AsmiqeVPVZpe1Ekk9s/JyqDmVlzMgF43i SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2017 20:33:14.1554 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 54ae2d84-47d8-4040-2ec9-08d5458d6625 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] syslog-model-17 shepherd writeup issues -references X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Dec 2017 20:33:23 -0000 Clyde Sorry for being unclear OLD This module imports typedefs from [RFC6021], [RFC7223], groupings from [RFC yyyy], and [RFC xxxx], and it references [RFC5424], [RFC5425], [RFC5426], [RFC6587], and [RFC5848]. NEW This module imports typedefs from [RFC6021], [RFC7223], groupings from [RFC yyyy], and [RFC xxxx], and it references [RFC5424], [RFC5425], [RFC5426], [RFC6587], [RFC5848], and [Std-1003.1-2008]. would satisfy me. Tom Petch ----- Original Message ----- From: "Clyde Wildes (cwildes)" Sent: Thursday, December 14, 2017 5:05 PM > Tom, > > This does not satisfy the reference requirement? > > leaf pattern-match { > if-feature select-match; > type string; > description > "This leaf describes a Posix 1003.2 regular expression > string that can be used to select a syslog message for > logging. The match is performed on the SYSLOG-MSG field."; > reference > "RFC 5424: The Syslog Protocol > Std-1003.1-2008 Regular Expressions"; > } > > Please help me understand what more you want. > > Thanks, > > Clyde > > On 12/14/17, 3:55 AM, "t.petch" wrote: > > Clyde > > A quick glance at -18 shows that there is now a Normative Reference for > Posix - good- but I do not see it referenced - not so good:-( > > I think that there needs to be a reference in 4.1 > > Tom Petch > > > ----- Original Message ----- > From: "Clyde Wildes (cwildes)" > To: "Benoit Claise (bclaise)" ; "Kent Watsen" > ; "t.petch" ; > > Cc: > Sent: Wednesday, September 27, 2017 5:26 PM > Subject: Re: [netmod] syslog-model-17 shepherd writeup > issues -references > > > > Benoit, > > > > There were approximately 24 changes requested from you, Kent, Robert > Wilton, and Tom Petch. I have made approximately half of them and will > try to finish another revision of the draft by Friday. > > > > Thanks, > > > > Clyde > > > > On 9/27/17, 3:24 AM, "Benoit Claise (bclaise)" > wrote: > > > > Clyde, > > > > Do you know your next step to progress this document? > > > > Regards, Benoit > > > I meant to say something about the .1 vs .2 difference. My > comment > > > assumes that it's supposed to be .1, but we of course should use > > > whatever is correct. > > > > > > I also don't know much about that standards body. > > > > > > K. > > > > > > > > > > > > ----- Original Message ----- > > > From: "Kent Watsen" > > > Sent: Wednesday, September 13, 2017 6:08 PM > > > > > >> Hi Tom, > > >> > > >> Thanks. The fix I'm looking for is for the 'pattern-match' > leaf > > >> to have a 'reference' statement to Std-1003.1-2008, and for > S4.1 > > >> to also list Std-1003.1-2008 as a draft-level reference. > > > and I am unfamiliar with that standards body so am looking for a > little > > > more. > > > > > > Is STD-nnnn always Posix or do we need to say Posix 1003 or > Posix > > > Std-1003 or is Std-1003 completely unrelated to Posix 1003? > > > > > > Is there a difference between Std-1003.1-2008 and Posix 1003.2 > ie is the > > > .1 or .2 significant? You want Std-1003.1; the description > contains > > > Posix 1003.2; the normative Reference is to Std-1003.1-2008. > > > > > > You pointed out that the Normative Reference is not used; well > if we can > > > sort out what the standard is and get the right label in > Normative > > > References then we can - must - include this in Section 4.1 > which will > > > resolve that comment of yours. > > > > > > The discussions last July had Clyde saying he wants Posix 1003.2 > so if > > > Std-1003 and Posix 1003 are the same but .1 and.2 are different, > then > > > you are asking for a semantic change against Clyde's wishes. > > > > > > I hope my confusion is sufficiently clear, at least to Clyde! > > > > > > Tom Petch > > > > > >> I was going to point out the typo "the the" as well, but > figured > > >> that the RFC Editor would get it. > > >> > > >> K. // shepherd > > >> > > >> > > >> -- > > >> > > >> Kent > > >> > > >> You flag Std-1003.1-2008 as listed as a normative reference but > not > > > used > > >> anywhere in the document. In the Descriptions, but not in the > s.4.1 > > >> references, I see > > >> > > >> This leaf describes a Posix 1003.2 regular expression ... > > >> > > >> twice, which may, or may not, relate to this issue. > > >> > > >> Back in July, clyde said > > >> "I will insert a normative reference to POSIX 1003.2 in the > next > > >> revision of the draft." > > >> > > >> In a similar vein, RFC6991 appears in a reference statement but > > > nowhere > > >> else. > > >> > > >> As you point out, RFC6021 is referenced but is obsoleted by > RFC6991 so > > >> should not be. > > >> > > >> And in a slightly different vein, > > >> > > >> registry [RFC7895]/>. Following the format in [RFC7950]/>, > the the > > >> > > >> looks odd for plain text and for the repetition of 'the'.. > > >> > > >> Tom Petch > > >> > > >> ----- Original Message ----- > > >> From: "Kent Watsen" > > >> To: > > >> Cc: > > >> Sent: Tuesday, September 12, 2017 10:50 PM > > >> Subject: [netmod] syslog-model-17 shepherd writeup issues > > >> > > >> > > >>> Clyde, all, > > >>> > > >>> In reviewing the draft for Shepherd writeup, I found the > following > > >> issues that I think need to be addressed before the document > can be > > > sent > > >> to Benoit for AD review: > > >>> > > >>> 1. Idnits found the following: > > >>> > > >>> Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 > comment > > >> (--). > > >>> ** There are 2 instances of too long lines in the > document, the > > >> longest one > > >>> being 3 characters in excess of 72. > > >>> > > >>> ** Obsolete normative reference: RFC 6021 (Obsoleted by > RFC > > > 6991) > > >>> ** Downref: Normative reference to an Historic RFC: RFC > 6587 > > >>> > > >>> == Missing Reference: 'RFC5425' is mentioned on line 359, > but > > > not > > >> defined > > >>> '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]....' > > >>> > > >>> == Unused Reference: 'RFC7895' is defined on line 1406, > but no > > >> explicit > > >>> reference was found in the text > > >>> '[RFC7895] Bierman, A., Bjorklund, M., and K. > Watsen, > > > "YANG > > >> Module L...' > > >>> == Unused Reference: 'RFC6242' is defined on line 1435, > but no > > >> explicit > > >>> reference was found in the text > > >>> '[RFC6242] Wasserman, M., "Using the NETCONF > Protocol > > > over > > >> Secure Sh...' > > >>> > > >>> 2. `rfcstrip` extracted "ietf-syslog.yang", which is missing > > >> "@yyyy-mm-dd" in its name > > >>> 3. neither `pyang` nor `yanglint` found any errors with > > >> ietf-syslog.yang. pyang says > > >>> for vendor-syslog-types-example: statement "identity" > must > > > have > > >> a "description" > > >>> substatement. > > >>> > > >>> 4. testing the examples in the draft against yanglint: > > >>> - for both examples: Missing element's "namespace". > (/config) > > >>> - just removing the "" element envelop resolves > this > > >> error. > > >>> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but > this > > >> SHOULD be a > > >>> domain name (e.g., foo.example.com) > > >>> > > >>> 6. in the YANG module, anywhere you have an RFC listed in a > > >> 'description' statement, > > >>> there should be a 'reference' statement for that RFC. > > >>> > > >>> 7. in the tree diagram, the leafrefs no longer indicate what > they > > >> point at, they now all > > >>> just say "leafref". Did you do this on purpose, or are > you > > > using > > >> a different tree > > >>> output generator from -15? > > >>> > > >>> 8. RFC6536 is listed as a normative reference, but it probably > > > should > > >> be informative. > > >>> 9. Std-1003.1-2008 is listed as a normative reference, but it > is not > > >> used anywhere in the document. > > >>> 10. RFC6242 is listed as an informative reference, but it is > not > > > used > > >> anywhere in the document. > > >>> 11. the document fails to declare its normative references to > > >> ietf-keystore and ietf-tls-client-server. > > >>> Note: you manually entered the "[RFC yyyy], and [RFC > xxxx]" > > >> references… > > >>> 12. The IANA considerations section seems asymmetric. Either > put > > >> both registry insertions into > > >>> subsections, or keep them both at the top-level… > > >>> > > >>> 13. reviewing the final document against my original YD > review, I > > > have > > >> the following responses. Let's be sure to close out these > items as > > >> well. Ref: > > > https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11 > > >> s-0gOfCe8NSE > > >>> 1. ok > > >>> 2. better > > >>> 3. should be: s/the message/these messages/ [RFC Editor > might've > > >> caught this] > > >>> 4. better > > >>> 5. still feel the same way, but no biggee > > >>> 6. better, but from 8174, you should add the part "when, and > only > > >> when, they appear in all capitals, as shown here." > > >>> 7. fixed > > >>> 8. fixed > > >>> 9. you did what I asked, but the result still isn't > satisfying... > > >>> 10. some improvements made in this area, but my ask wasn't > among > > > them > > >>> 11. better > > >>> 12. better, but I think the 4th line should be indented too, > right? > > >>> 13. better, but I wish you called S1.3 "Tree Diagram Notation" > > >>> 14. fixed > > >>> 15. fixed > > >>> 16. fixed > > >>> 17. fine > > >>> 18. still a weird line brake here. try putting the quoted > string on > > >> the next line. > > >>> 19. fixed > > >>> 20. fixed > > >>> 21. not fixed (re: yang-security-guidelines) > > >>> 22. fine > > >>> > > >>> > > >>> PS: please also be sure to follow-up with Benoit on his AD > review. > > >>> > > >>> Thanks, > > >>> Kent // shepherd & yang doctor > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> 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 Sun Dec 17 16:59:45 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8047D1270B4 for ; Sun, 17 Dec 2017 16:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 YX3_NgRUCVz2 for ; Sun, 17 Dec 2017 16:59:41 -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 D8B861200C5 for ; Sun, 17 Dec 2017 16:59:40 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 849E7BC03DC66 for ; Mon, 18 Dec 2017 00:59:36 +0000 (GMT) Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 18 Dec 2017 00:59:38 +0000 Received: from DGGEML504-MBS.china.huawei.com ([169.254.11.87]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 08:59:32 +0800 From: wangzitao To: Kent Watsen , Lou Berger CC: "EXT - joelja@bogus.com" , NETMOD Working Group Thread-Topic: [netmod] Joel Jaeggli as a third NETMOD co-chair Thread-Index: AdN3m1ye1UisGrJUQs2fPtLcQhBZog== Date: Mon, 18 Dec 2017 00:59:31 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.152] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2B8A7097DGGEML504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 18 Dec 2017 00:59:43 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2B8A7097DGGEML504MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsY29tZSBKb2VsIQ0KDQpCLlIhDQotTWljaGFlbA0KDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggS2VudCBXYXRzZW4NCuWPkemAgeaX tumXtDogMjAxN+W5tDEy5pyIMTbml6UgNTowNA0K5pS25Lu25Lq6OiBMb3UgQmVyZ2VyIDxsYmVy Z2VyQGxhYm4ubmV0Pg0K5oqE6YCBOiBFWFQgLSBqb2VsamFAYm9ndXMuY29tIDxqb2VsamFAYm9n dXMuY29tPjsgTkVUTU9EIFdvcmtpbmcgR3JvdXAgPG5ldG1vZEBpZXRmLm9yZz4NCuS4u+mimDog UmU6IFtuZXRtb2RdIEpvZWwgSmFlZ2dsaSBhcyBhIHRoaXJkIE5FVE1PRCBjby1jaGFpcg0KDQoN CkluZGVlZCwgY29uZ3JhdHMhDQoNCksuDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIERlYyAx NSwgMjAxNywgYXQgMTI6MTkgUE0sIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRv OmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCkpvZWwsDQoNCiAgICBXZWxjb21lIGFib2FyZCEN Cg0KTG91DQoNCk9uIDEyLzE1LzIwMTcgMTI6MjEgUE0sIEJlbm9pdCBDbGFpc2Ugd3JvdGU6DQoN CkRlYXIgYWxsLA0KDQpBIGxvdCBpcyBoYXBwZW5pbmcgdGhlc2UgZGF5cyBpbiB0aGUgd29ybGQg b2YgZGF0YSBtb2RlbGluZy1kcml2ZW4NCm1hbmFnZW1lbnQgYXQgdGhlIElFVEY6DQogICAgTk1E QSBhcmNoaXRlY3R1cmUsIE5FVENPTkYsIFJFU1RDT05GDQogICAgTk1EQS1jb21wbGlhbnQgWUFO RyBtb2R1bGVzOiBzb21lIFJGQyBiaXMgbW9kdWxlcyBidXQgYWxzbyBuZXcgb25lcw0KICAgIEd1 aWRlbGluZXM6IFJGQzYwODdiaXMgYW5kIHRoZSB0cmVlIGRpYWdyYW0NCiAgICBUaGUgaW50ZXJh Y3Rpb24gd2l0aCBORVRDT05GOiBUaGUgc2NoZW1hIG1vdW50LCBJRVRGLVlBTkctTElCUkFSWSwN CnRlbGVtZXRyeQ0KICAgIFRoZSBpbnRlcmFjdGlvbiB3aXRoIHJvdXRpbmcsIHdoZXJlIG1hbnkg WUFORyBtb2R1bGVzIGNvbWUgZnJvbS4NCiAgICBldGMuDQpUaGVyZSBhcmUgYSBsb3Qgb2YgZGVw ZW5kZW5jaWVzIGJldHdlZW4gYWxsIHRoZXNlIHRhc2tzLCB3aGljaCBtdXN0IHRha2UNCnBsYWNl IGluIHBhcmFsbGVsLCBhbmQsIG9idmlvdXNseSwgYmUgY29tcGxldGVkIEFTQVAuDQoNCktlbnQg YW5kIExvdSBoYXZlIGEgbG90IG9uIHRoZWlyIHNob3VsZGVycyB0aGVzZSBkYXlzLg0KVG8gaGVs cCB3aXRoIHRoZSBzaXR1YXRpb24gYW5kIHByb2FjdGl2ZWx5IHByb2dyZXNzIGRvY3VtZW50cywg SSdtIGhhcHB5DQp0byBhbm5vdW5jZSB0aGF0IEpvZWwgSmFlZ2dsaSBhY2NlcHRlZCB0byBzZXJ2 ZSBhcyBhIHRoaXJkIE5FVE1PRA0KY28tY2hhaXIuIFRoYW5rIHlvdSBKb2VsLg0KDQpQbGVhc2Ug d2VsY29tZSBKb2VsLg0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBp ZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19uZXRtb2QmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWFR dHJjWV9HSGdSa0ZmV0tzOThzU2xfeVl5N01Bcm9tUnRSbTYzbWl3RlEmcz1teHUweTljaDdKN0Zl TlNwRGdaa2dGYU5vXzIyVWNvdjlOWHVzSTM1NkRFJmU9DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fbmV0bW9kJmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RU WGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1h UXRyY1lfR0hnUmtGZldLczk4c1NsX3lZeTdNQXJvbVJ0Um02M21pd0ZRJnM9bXh1MHk5Y2g3SjdG ZU5TcERnWmtnRmFOb18yMlVjb3Y5Tlh1c0kzNTZERSZlPQ0K --_000_E6BC9BBCBCACC246846FC685F9FF41EA2B8A7097DGGEML504MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAu MHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2VsY29tZSBKb2VsITxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Qi5SITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LU1pY2hhZWw8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi PuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPjo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mb hem7kSZxdW90OyxzYW5zLXNlcmlmIj4gbmV0bW9kDQogW21haWx0bzpuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZ10gPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuS7o+ihqCA8L3NwYW4+PC9iPktlbnQgV2F0 c2VuPGJyPg0KPGI+PHNwYW4gbGFuZz0iWkgtQ04iPuWPkemAgeaXtumXtDwvc3Bhbj46PC9iPiAy MDE3PHNwYW4gbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj4xMjxzcGFuIGxhbmc9IlpILUNOIj7mnIg8 L3NwYW4+MTY8c3BhbiBsYW5nPSJaSC1DTiI+5pelPC9zcGFuPiA1OjA0PGJyPg0KPGI+PHNwYW4g bGFuZz0iWkgtQ04iPuaUtuS7tuS6ujwvc3Bhbj46PC9iPiBMb3UgQmVyZ2VyICZsdDtsYmVyZ2Vy QGxhYm4ubmV0Jmd0Ozxicj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIj7mioTpgIE8L3NwYW4+Ojwv Yj4gRVhUIC0gam9lbGphQGJvZ3VzLmNvbSAmbHQ7am9lbGphQGJvZ3VzLmNvbSZndDs7IE5FVE1P RCBXb3JraW5nIEdyb3VwICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+PHNwYW4gbGFu Zz0iWkgtQ04iPuS4u+mimDwvc3Bhbj46PC9iPiBSZTogW25ldG1vZF0gSm9lbCBKYWVnZ2xpIGFz IGEgdGhpcmQgTkVUTU9EIGNvLWNoYWlyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQsIGNvbmdyYXRzISA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Sy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCk9uIERlYyAxNSwgMjAxNywgYXQgMTI6MTkgUE0sIExvdSBCZXJnZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkpvZWwsPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFdlbGNvbWUgYWJvYXJkITxi cj4NCjxicj4NCkxvdTxicj4NCjxicj4NCk9uIDEyLzE1LzIwMTcgMTI6MjEgUE0sIEJlbm9pdCBD bGFpc2Ugd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QSBsb3QgaXMgaGFwcGVuaW5nIHRoZXNlIGRheXMgaW4gdGhlIHdv cmxkIG9mIGRhdGEgbW9kZWxpbmctZHJpdmVuDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWFuYWdlbWVudCBhdCB0aGUgSUVURjo8bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IE5NREEgYXJjaGl0ZWN0dXJlLCBORVRDT05GLCBSRVNUQ09ORjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsm bmJzcDsgTk1EQS1jb21wbGlhbnQgWUFORyBtb2R1bGVzOiBzb21lIFJGQyBiaXMgbW9kdWxlcyBi dXQgYWxzbyBuZXcgb25lczxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgR3VpZGVsaW5lczogUkZDNjA4N2JpcyBh bmQgdGhlIHRyZWUgZGlhZ3JhbTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGludGVyYWN0aW9uIHdpdGgg TkVUQ09ORjogVGhlIHNjaGVtYSBtb3VudCwgSUVURi1ZQU5HLUxJQlJBUlksDQo8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGVsZW1ldHJ5PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyBUaGUgaW50ZXJhY3Rpb24gd2l0aCByb3V0aW5nLCB3aGVyZSBtYW55IFlB TkcgbW9kdWxlcyBjb21lIGZyb20uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyBldGMuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBhIGxvdCBv ZiBkZXBlbmRlbmNpZXMgYmV0d2VlbiBhbGwgdGhlc2UgdGFza3MsIHdoaWNoIG11c3QgdGFrZQ0K PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBs YWNlIGluIHBhcmFsbGVsLCBhbmQsIG9idmlvdXNseSwgYmUgY29tcGxldGVkIEFTQVAuPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50 IGFuZCBMb3UgaGF2ZSBhIGxvdCBvbiB0aGVpciBzaG91bGRlcnMgdGhlc2UgZGF5cy48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gaGVscCB3 aXRoIHRoZSBzaXR1YXRpb24gYW5kIHByb2FjdGl2ZWx5IHByb2dyZXNzIGRvY3VtZW50cywgSSdt IGhhcHB5DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dG8gYW5ub3VuY2UgdGhhdCBKb2VsIEphZWdnbGkgYWNjZXB0ZWQgdG8gc2VydmUgYXMg YSB0aGlyZCBORVRNT0QNCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5jby1jaGFpci4gVGhhbmsgeW91IEpvZWwuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugd2VsY29tZSBK b2VsLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5uZXRtb2QgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v cmciPm5ldG1vZEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u ZXRtb2QmYW1wO2Q9RHdJR2FRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz dm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK ZGNabyZhbXA7bT1hUXRyY1lfR0hnUmtGZldLczk4c1NsX3lZeTdNQXJvbVJ0Um02M21pd0ZRJmFt cDtzPW14dTB5OWNoN0o3RmVOU3BEZ1prZ0ZhTm9fMjJVY292OU5YdXNJMzU2REUmYW1wO2U9Ij5o dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lHYVEmYW1wO2M9SEFrWXVo NjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdK OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPWFRdHJjWV9HSGdSa0ZmV0tzOThz U2xfeVl5N01Bcm9tUnRSbTYzbWl3RlEmYW1wO3M9bXh1MHk5Y2g3SjdGZU5TcERnWmtnRmFOb18y MlVjb3Y5Tlh1c0kzNTZERSZhbXA7ZT08L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJR2FRJmFtcDtjPUhB a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpV dlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1hUXRyY1lfR0hnUmtGZldL czk4c1NsX3lZeTdNQXJvbVJ0Um02M21pd0ZRJmFtcDtzPW14dTB5OWNoN0o3RmVOU3BEZ1prZ0Zh Tm9fMjJVY292OU5YdXNJMzU2REUmYW1wO2U9Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25l dG1vZCZhbXA7ZD1Ed0lHYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2 b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk Y1pvJmFtcDttPWFRdHJjWV9HSGdSa0ZmV0tzOThzU2xfeVl5N01Bcm9tUnRSbTYzbWl3RlEmYW1w O3M9bXh1MHk5Y2g3SjdGZU5TcERnWmtnRmFOb18yMlVjb3Y5Tlh1c0kzNTZERSZhbXA7ZT08L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EA2B8A7097DGGEML504MBSchi_-- From nobody Sun Dec 17 17:33:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C35127337 for ; Sun, 17 Dec 2017 17:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 y3B585UMn6Ta for ; Sun, 17 Dec 2017 17:33:19 -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 59A341200C5 for ; Sun, 17 Dec 2017 17:33:19 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EF6A6DBC01365 for ; Mon, 18 Dec 2017 01:33:15 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 18 Dec 2017 01:33:15 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Mon, 18 Dec 2017 09:33:11 +0800 From: Tianran Zhou To: Mehmet Ersue , 'Mahesh Jethanandani' , 'Joel jaeggli' CC: 'NETMOD Working Group' Thread-Topic: [netmod] Joel Jaeggli as a third NETMOD co-chair Thread-Index: AQHTdclCV29V98WpK0WzNxL6vLD4AaNE8XwAgACvB4CAArQfAA== Date: Mon, 18 Dec 2017 01:33:10 +0000 Message-ID: References: <1152A14B-B19C-4411-87A0-879AFE60CAD7@gmail.com> <003801d37689$1a1f6aa0$4e5e3fe0$@gmail.com> In-Reply-To: <003801d37689$1a1f6aa0$4e5e3fe0$@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] 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] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 18 Dec 2017 01:33:21 -0000 Welcome Joel! Cheers, Tianran > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mehmet Ersue > Sent: Sunday, December 17, 2017 12:16 AM > To: 'Mahesh Jethanandani'; 'Joel jaeggli' > Cc: 'NETMOD Working Group' > Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair >=20 > +1 >=20 > Mehmet >=20 > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh > > Jethanandani > > Sent: Saturday, December 16, 2017 6:49 AM > > To: Joel jaeggli > > Cc: NETMOD Working Group > > Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair > > > > Joel, > > > > Welcome. Look forward to the interaction with NETCONF. > > > > Cheers. > > > > > On Dec 15, 2017, at 9:21 AM, Benoit Claise wrote: > > > > > > Dear all, > > > > > > A lot is happening these days in the world of data modeling-driven > > management at the IETF: > > > NMDA architecture, NETCONF, RESTCONF > > > NMDA-compliant YANG modules: some RFC bis modules but also new > > ones > > > Guidelines: RFC6087bis and the tree diagram > > > The interaction with NETCONF: The schema mount, > > > IETF-YANG-LIBRARY, > > telemetry > > > The interaction with routing, where many YANG modules come from. > > > etc. > > > There are a lot of dependencies between all these tasks, which must > > > take > > place in parallel, and, obviously, be completed ASAP. > > > > > > Kent and Lou have a lot on their shoulders these days. > > > To help with the situation and proactively progress documents, I'm > > > happy > > to announce that Joel Jaeggli accepted to serve as a third NETMOD > co-chair. > > Thank you Joel. > > > > > > Please welcome Joel. > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > 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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Dec 18 01:37:27 2017 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 711A7127419; Mon, 18 Dec 2017 01:37:21 -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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151358984141.28794.3169667694911973561@ietfa.amsl.com> Date: Mon, 18 Dec 2017 01:37:21 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-entity-06.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, 18 Dec 2017 09:37:21 -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-06.txt Pages : 54 Date : 2017-12-18 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 18 01:40:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43325127419 for ; Mon, 18 Dec 2017 01:40:25 -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 T4w3hnUPhSY2 for ; Mon, 18 Dec 2017 01:40: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 8F950127599 for ; Mon, 18 Dec 2017 01:40:23 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 6AB5B1AE0311 for ; Mon, 18 Dec 2017 10:40:22 +0100 (CET) Date: Mon, 18 Dec 2017 10:39:03 +0100 (CET) Message-Id: <20171218.103903.1338730940312800102.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151358984141.28794.3169667694911973561@ietfa.amsl.com> References: <151358984141.28794.3169667694911973561@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] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 09:40:25 -0000 Hi, This version addresses the WGLC comments received. Specifically, I have added ietf-hardware-state, a config false version of ietf-hardware for non-NMDA implementations, in an Appendix. Please review the new text and the description statement in that module. I have also added a reference to the tree diagram draft and use the latest security guidelines template text. /martin 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 Hardware Management > Authors : Andy Bierman > Martin Bjorklund > Jie Dong > Dan Romascanu > Filename : draft-ietf-netmod-entity-06.txt > Pages : 54 > Date : 2017-12-18 > > 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-06 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 > From nobody Mon Dec 18 02:46:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2202127517 for ; Mon, 18 Dec 2017 02:46:38 -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 Deef_K2DjGBA for ; Mon, 18 Dec 2017 02:46:36 -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 93AFF126BFD for ; Mon, 18 Dec 2017 02:46:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id F3E7615605E0; Mon, 18 Dec 2017 11:46:33 +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 Hao2hGFMEnBb; Mon, 18 Dec 2017 11:46:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id CBB1A15605D4; Mon, 18 Dec 2017 11:46:33 +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 wZpNMie3BH_S; Mon, 18 Dec 2017 11:46:33 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id AB41915605CB; Mon, 18 Dec 2017 11:46:33 +0100 (CET) To: Martin Bjorklund Cc: netmod@ietf.org References: <20171213.154734.273404682004037071.mbj@tail-f.com> <500e497e-9a80-8d00-22ca-6fe271fcd725@transpacket.com> <937fadab-b3f0-1246-8543-00cb4d6a5acd@transpacket.com> <20171216.104645.2140965470373068531.mbj@tail-f.com> From: Vladimir Vassilev Message-ID: Date: Mon, 18 Dec 2017 11:46:33 +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: <20171216.104645.2140965470373068531.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 18 Dec 2017 10:46:39 -0000 On 12/16/2017 10:46 AM, Martin Bjorklund wrote: > Hi, > > Vladimir Vassilev wrote: >> On 12/13/2017 04:26 PM, Vladimir Vassilev wrote: >>> Hi, >>> >>> On 12/13/2017 03:47 PM, Martin Bjorklund wrote: >>> >>>> Hi, >>>> >>>> Thanks for reporting this.=C2=A0 I'll add the missing origin.=C2=A0 = But why did >>>> you think forwarding and mtu should be removed? >>> 1. IMO since is not present in the container in the >>> Appendix A () example and does not have default value in >>> the model I still think it should be removed. >> Alternatively the ipv4/mtu node can be a good example of a >> origin=3D"or:system" configuration. > Yes. > >>>> =C2=A0=C2=A0 In fact, I think I >>>> missed , >>> 2. IMO both fixes adding or removing should be >>> OK depending on the RFC6243 defined with-defaults capability >>> 'basic-mode' parameter advertised by the server. I was running the >>> example with basic-mode=3Dexplicit > Right. I now have this: > > > > > true > false > 1500 >
> 192.0.2.1 > 24 > static >
> > 192.0.2.2 > 00:01:02:03:04:05 > > > > true > false > 1280 > ... > > Do you think this is ok? Yes. The or:default data makes the example even better. 1. However there is one more default value missing=20 (/interfaces/interface[name=3D'eth0']/enabled) for the example to be=20 consistent 2. ... and in the last diff I unintentionally omitted the get-data=20 output node required namespace addition (this is also applicable=20 to draft-ietf-netmod-7223bis-01): diff -u before2.xml after2.xml --- before2.xml=C2=A0=C2=A0=C2=A0 2017-12-18 11:41:54.029279321 +0100 +++ after2.xml=C2=A0=C2=A0=C2=A0 2017-12-18 11:36:25.973850340 +0100 @@ -1,4 +1,4 @@ -=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 eth0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ianaift:ethernetCsmacd +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 true =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 true Vladimir > > > /martin From nobody Mon Dec 18 03:24:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7130B126CBF; Mon, 18 Dec 2017 03:24:14 -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 I_4XDxZc9ZyE; Mon, 18 Dec 2017 03:24:12 -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 BB643124B09; Mon, 18 Dec 2017 03:24:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 1F52A1560606; Mon, 18 Dec 2017 12:24:10 +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 HQhlO5LZMH8n; Mon, 18 Dec 2017 12:24:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 82D0D1560605; Mon, 18 Dec 2017 12:24:09 +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 cjatlc_Ky4gU; Mon, 18 Dec 2017 12:24:09 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 5F63E15605FD; Mon, 18 Dec 2017 12:24:09 +0100 (CET) To: "Acee Lindem (acee)" , Lou Berger , NetMod WG Cc: NetMod WG Chairs References: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net> <44e5318a-4157-b825-b688-5185ab2458cb@labn.net> From: Vladimir Vassilev Message-ID: <43f78a5f-9485-05cc-dd11-2ff29ced6120@transpacket.com> Date: Mon, 18 Dec 2017 12:24:09 +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] WG Last Call: draft-ietf-netmod-rfc8022bis-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, 18 Dec 2017 11:24:14 -0000 On 12/17/2017 05:57 PM, Acee Lindem (acee) wrote: > Hi Lou, et al, > > The only issue we are struggling with is whether we need to specify the > version in the ietf-interfaces import. We have noted that > draft-ietf-netmod-rfc7277bis-01.txt does not import by revision. > > We also have so nits: > > 1. Add an informative reference for > [I-D.ietf-netmod-yang-tree-diagrams]. > 2. Based on a comment from Vladimir, we added the prefix for > ietf-routing.yang, =E2=80=9Crt:=E2=80=9D, to several references within = ietf-routing.yang. > Was this necessary? Of course, the model compiles with or without the > prefix. I reverted this in a follow-up comment on the same thread. I believe the=20 local prefixes are redundant. Vladimir > > Thanks, > Acee > > On 12/15/17, 3:55 PM, "netmod on behalf of Lou Berger" > wrote: > >> All, >> This last call is closed. >> >> We note that there was an update during the LC and that no comments we= re >> received during the LC period. As this is simply a mechanical update >> that has been discussed in the WG we plan to proceed with the >> publication process. >> >> Authors, >> Please let/us the WG know when you have published a version ready for >> publication. Also please let the WG know what has changed in the >> document since the start of LC (rev -01) >> >> Thank you, >> NetMod Chairs >> >> >> >> On 11/29/2017 12:26 PM, Lou Berger wrote: >>> All, >>> >>> This starts a two-week working group last call on >>> draft-ietf-netmod-rfc8022bis-01. >>> >>> Please recall that this update's intention is to >>> modify the YANG module to be in line with the NMDA >>> guidelines [1]. Reviewing the diff between the two >>> drafts [2] should reveal just this. >>> >>> The working group last call ends on December 13. >>> 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. >>> >>> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 >>> [2] >>> https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Drfc8022.txt= &url2=3Ddr >>> aft-ietf-netmod-rfc8022bis-01.txt >>> >>> Thank you, >>> Netmod 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 Dec 18 03:34:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED85E124B09 for ; Mon, 18 Dec 2017 03:34:17 -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 Ph2ktBcPuKkl for ; Mon, 18 Dec 2017 03:34: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 357A8124239 for ; Mon, 18 Dec 2017 03:34:16 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id ED37A1AE0311; Mon, 18 Dec 2017 12:34:14 +0100 (CET) Date: Mon, 18 Dec 2017 12:32:56 +0100 (CET) Message-Id: <20171218.123256.987905036621498990.mbj@tail-f.com> To: vladimir@transpacket.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <937fadab-b3f0-1246-8543-00cb4d6a5acd@transpacket.com> <20171216.104645.2140965470373068531.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] WG Last Call: draft-ietf-netmod-rfc7277bis-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 18 Dec 2017 11:34:18 -0000 Hi, Vladimir Vassilev wrote: > On 12/16/2017 10:46 AM, Martin Bjorklund wrote: > = > > Hi, > > > > Vladimir Vassilev wrote: > >> On 12/13/2017 04:26 PM, Vladimir Vassilev wrote: > >>> Hi, > >>> > >>> On 12/13/2017 03:47 PM, Martin Bjorklund wrote: > >>> > >>>> Hi, > >>>> > >>>> Thanks for reporting this.=A0 I'll add the missing origin.=A0 Bu= t why did > >>>> you think forwarding and mtu should be removed? > >>> 1. IMO since is not present in the container in the > >>> Appendix A () example and does not have default value= in > >>> the model I still think it should be removed. > >> Alternatively the ipv4/mtu node can be a good example of a > >> origin=3D"or:system" configuration. > > Yes. > > > >>>> =A0=A0 In fact, I think I > >>>> missed , > >>> 2. IMO both fixes adding or removing shoul= d be > >>> OK depending on the RFC6243 defined with-defaults capability > >>> 'basic-mode' parameter advertised by the server. I was running th= e > >>> example with basic-mode=3Dexplicit > > Right. I now have this: > > > > > > > > > > true > > false > > 1500 > >
> > 192.0.2.1 > > 24 > > static > >
> > > > 192.0.2.2 > > 00:01:02:03:04:05 > > > > > > > > true > > false > > 1280 > > ... > > > > Do you think this is ok? > Yes. The or:default data makes the example even better. > = > 1. However there is one more default value missing > (/interfaces/interface[name=3D'eth0']/enabled) for the example to be > consistent Note that the example has: This covers the 'enabled' leaf (and more). The idea is to let this document focus on the ip parameters. > 2. ... and in the last diff I unintentionally omitted the get-data > output node required namespace addition (this is also > applicable to draft-ietf-netmod-7223bis-01): Good catch! I have applied this in both documents. I also realized that the drafts don't use text from the latest Security Considerations template; I have fixed that as well. /martin > = > diff -u before2.xml after2.xml > --- before2.xml=A0=A0=A0 2017-12-18 11:41:54.029279321 +0100 > +++ after2.xml=A0=A0=A0 2017-12-18 11:36:25.973850340 +0100 > @@ -1,4 +1,4 @@ > -=A0=A0=A0=A0 > +=A0=A0=A0=A0 xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-netconf-datastores"> > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 xmlns=3D"urn:ietf:params:xml:ns:yan= g:ietf-interfaces" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 xmlns:ianaift=3D"urn:ietf:params:xm= l:ns:yang:iana-if-type" > @@ -7,6 +7,7 @@ > =A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 eth0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ianaift:ethernetCsmacd= > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tru= e > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 true > = > = > Vladimir > > > > > > /martin > = From nobody Mon Dec 18 04:31:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442F2126CBF for ; Mon, 18 Dec 2017 04:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.61 X-Spam-Level: X-Spam-Status: No, score=-12.61 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_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 cwF7ayCa8poe for ; Mon, 18 Dec 2017 04:31: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 99EB71241F8 for ; Mon, 18 Dec 2017 04:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113229; q=dns/txt; s=iport; t=1513600297; x=1514809897; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=0dQwACUpQKty+JG7sZBW2JmlMXjB5Ff6BDtqoIvj2qk=; b=bndugneDNjU9tmgwvLgpN8LL9ApJUEVvpLGe7NKToZ6+2Pc3BaMIftYa OZhVKW79AuwPrzDXrkDLTYQdQ83loKguD8vRnkEPhafyfHMFoL6z3tMRG HiepvsW3SZNs7U+a3wqPFb4XMcmgZOZH/CLgzWWJ2cGx4Oz2psSjp6Aj8 s=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.45,422,1508803200"; d="asc'?scan'208,217";a="936435" 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; 18 Dec 2017 12:31:36 +0000 Received: from [10.61.162.193] ([10.61.162.193]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBICVZ0U002443; Mon, 18 Dec 2017 12:31:35 GMT To: "Einar Nilsen-Nygaard (einarnn)" Cc: "netmod@ietf.org" , Kristian Larsson 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> From: Eliot Lear Message-ID: <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> Date: Mon, 18 Dec 2017 13:31:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bO47PHitjwMhuEuOE9E994HSX50p9BPui" 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: Mon, 18 Dec 2017 12:31:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bO47PHitjwMhuEuOE9E994HSX50p9BPui Content-Type: multipart/mixed; boundary="7BHQ3TjKjvAsJST6VRKc53b4AX6OKFqV1"; protected-headers="v1" From: Eliot Lear To: "Einar Nilsen-Nygaard (einarnn)" Cc: "netmod@ietf.org" , Kristian Larsson Message-ID: <5dd3a635-61ce-8dee-3472-589cda19fcbb@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> In-Reply-To: <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> --7BHQ3TjKjvAsJST6VRKc53b4AX6OKFqV1 Content-Type: multipart/alternative; boundary="------------FBF992787B1F134B8E13B6C4" Content-Language: en-US This is a multi-part message in MIME format. --------------FBF992787B1F134B8E13B6C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U28gbG9uZyBhcyBub2JvZHkgZXhwZWN0cyBhbiBpbnRlcmZhY2UgY29uc3RydWN0IGluIGEg TVVEIGZpbGUsIEknbSBoYXBweS4KCgpPbiAxNy4xMi4xNyAxNTozNCwgRWluYXIgTmlsc2Vu LU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOgo+IEVsaW90LAo+Cj4gTm90aGluZyBjYW4gZm9y Y2UgYW4gaW1wbGVtZW50YXRpb24gdG8gaGF2ZSB0byBpbXBsZW1lbnQgZWl0aGVyCj4gdGhl wqBpZXRmLWludGVyZmFjZXMgbW9kZWwgb3IgdGhlIGF1Z21lbnRhdGlvbiBpbiB0aGUKPiBp ZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QgbW9kZWwuIEkgYXBwcmVjaWF0ZSB5b3VyIGRlc2ly ZSBmb3IKPiBtb2R1bGFyaXR5IGFuZCBjb2hlc2l2ZW5lc3MsIGJ1dCBJIHdvdWxkIHJlc2lz dCAjMSwgYmVjYXVzZSBJIGZlZWwKPiB0aGF0IHRoZSBtYWpvcml0eSBvZiB1c2VycyB3aWxs IGJlIHRhcmdldGluZyBpbnRlcmZhY2UtYmFzZWQKPiBhdHRhY2htZW50IG92ZXIgdGltZS4g SeKAmXZlIGFkZGUgYmFjayBpbiB1c2Ugb2YgdGhlCj4g4oCcaW50ZXJmYWNlLWF0dGFjaG1l bnTigJ0gZmVhdHVyZSAod2hpY2ggSSB0b29rIG91dCBhcyBwYXJ0IG9mCj4gcmVmYWN0b3Jp bmcgaW50ZXJmYWNlIGF0dGFjaG1lbnQpLiBQYXJ0IG9mOgo+Cj4gICAgIGh0dHBzOi8vZ2l0 aHViLmNvbS9uZXRtb2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjEKPgo+Cj4gVGhlIGF1Z21lbnRz IHBhcnQgb2YgdGhlIHRyZWUgbm93IGxvb2tzIGxpa2U6Cj4KPiDCoCBhdWdtZW50IC9pZjpp bnRlcmZhY2VzL2lmOmludGVyZmFjZToKPiDCoCDCoCArLS1ydyBhY2xzICp7aW50ZXJmYWNl LWF0dGFjaG1lbnR9Kj8KPiDCoCDCoCDCoCDCoCstLXJ3IGluZ3Jlc3MKPiDCoCDCoCDCoCDC oHwgwqArLS1ydyBhY2wtc2V0cwo+IMKgIMKgIMKgIMKgfCDCoCDCoCArLS1ydyBhY2wtc2V0 KiBbbmFtZV0KPiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqArLS1ydyBuYW1lIMKgIMKgIMKg IMKgIMKgIMKgIMKgLT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+IMKgIMKgIMKgIMKgfCDC oCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlz dHMvYWNsL3R5cGUKPiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqArLS1ybyBhY2Utc3RhdGlz dGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pwo+IMKgIMKgIMKgIMKgfCDCoCDCoCDC oCDCoCDCoCArLS1ybyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0+Cj4gL2FjY2Vzcy1s aXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCAr LS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlhbmc6Y291bnRlcjY0Cj4gwqAgwqAgwqAgwqB8 IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRl cjY0Cj4gwqAgwqAgwqAgwqArLS1ydyBlZ3Jlc3MKPiDCoCDCoCDCoCDCoCDCoCArLS1ydyBh Y2wtc2V0cwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcncgYWNsLXNldCogW25hbWVdCj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDC oC0+IC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAr LS1ydyB0eXBlPyDCoCDCoCDCoCDCoCDCoCDCoCAtPiAvYWNjZXNzLWxpc3RzL2FjbC90eXBl Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1l XSB7aW50ZXJmYWNlLXN0YXRzfT8KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCst LXJvIG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLT4KPiAvYWNjZXNzLWxpc3RzL2FjbC9h Y2VzL2FjZS9uYW1lCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRj aGVkLXBhY2tldHM/IMKgIHlhbmc6Y291bnRlcjY0Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqArLS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNvdW50ZXI2NAo+Cj4g Q2hlZXJzLAo+Cj4gRWluYXIKPgo+Cj4+IE9uIDE3IERlYyAyMDE3LCBhdCAxMToyOSwgRWxp b3QgTGVhciA8bGVhckBjaXNjby5jb20KPj4gPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdy b3RlOgo+Pgo+PiBFaW5hciwKPj4KPj4gSSB0aGluayB0aGlzIGNoYW5nZSBpcyBmaW5lLCB3 aXRoIG9uZSBleGNlcHRpb24uwqAgSSB3b3VsZCByYXRoZXIgdGhlCj4+IGF1Z21lbnQgdG8g dGhlIGludGVyZmFjZSBub3QgYmUgcmVxdWlyZWQgZm9yIGltcGxlbWVudGF0aW9ucyB0aGF0 Cj4+IGRvbid0IGFjdHVhbGx5IGhhdmUgaW50ZXJmYWNlcy7CoCBJIHVuZGVyc3RhbmQgdGhh dCB0aGVyZSBtYXkgYmUgdHdvCj4+IHdheXMgdG8gZ28gYWJvdXQgdGhpczoKPj4KPj4gIDEu IFNlcGFyYXRlIG91dCB0aGUgYXVnbWVudCBpbnRvIGEgc2VwYXJhdGUgbW9kdWxlIChzYW1l IGRvYyBpcwo+PiAgICAgZmluZSk7IG9yCj4+ICAyLiBTb21laG93ICJmZWF0dXJlLWl6ZSIg dGhlIGF1Z21lbnQuCj4+Cj4+IEkgZG9uJ3Qga25vdyBob3cgdG8gZG8gKDIpIGJ1dCBpZiB5 b3UgZG8sIHRoYXQncyBva2F5IGJ5IG1lLgo+Pgo+PiBFbGlvdAo+Pgo+Pgo+PiBPbiAxNi4x Mi4xNyAxNDoxOSwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOgo+Pj4g QWxsLAo+Pj4KPj4+IEFmdGVyIGEgc2VyaWVzIG9mIGRpc2N1c3Npb25zIG9uLSBhbmQgb2Zm LWxpc3QsIEkgaGF2ZSBhIGNhbmRpZGF0ZQo+Pj4gUFIgdGhhdCBpbmNsdWRlcyB0aGUgY2hh bmdlcyBpbiB0aGUgUFIgTWFoZXNoIHNlbnQgb3V0IHBsdXMgc29tZQo+Pj4gbW9yZSBlZGl0 cy4gUGxlYXNlIHNlZSBjb25zb2xpZGF0ZWQgUFIgaGVyZToKPj4+Cj4+PiAgICAgaHR0cHM6 Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yMQo+Pj4KPj4+Cj4+PiBN YWluIGNoYW5nZXMgaW4gYWRkaXRpb24gdG8gTWFoZXNo4oCZcyBQUiBhcmU6Cj4+Pgo+Pj4g ICAqIE1vdmVkIGludGVyZmFjZSBhdHRhY2htZW50IHRvIGJlIHZpYSBhbiBpbnRlcmZhY2Ug YXVnbWVudGF0aW9uLgo+Pj4gICAqIFJlc3RydWN0dXJlZCBwb3J0IG1hdGNoZXMgc2xpZ2h0 bHkgdW5kZXIgYm90aCBJUHY0IGFuZCBJUHY2Cj4+PiAgICAgY29udGFpbmVycy4KPj4+ICAg KiBSZW1vdmVkIHVubmVjZXNzYXJ5IGlkZW50aXR5ICdpbnRlcmZhY2UtYWNsLWFnZ3JlZ2F0 ZeKAmS4KPj4+ICAgKiBSZW1vdmVkIGFjdGlvbiDigJhpY21wLW9mZuKAmSwgY2FuIGJlIGF1 Z21lbnRlZCBsYXRlci4KPj4+Cj4+Pgo+Pj4gRm9yIHJlZmVyZW5jZSwgaGVyZSBpcyB0aGUg Y3VycmVudCBZQU5HIHRyZWUgcGx1cyDigJwtLWlldGbigJ0gbG9nczoKPj4+Cj4+PiAxMzox MiAkIHB5YW5nIC0taWV0ZiAtLWxpbnQgLWYgdHJlZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxp c3QueWFuZwo+Pj4gaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Lnlhbmc6NTE6IGVycm9yOiBi YWQgdmFsdWUgIllZWVktTU0tREQiCj4+PiAoc2hvdWxkIGJlIGRhdGUpCj4+PiBtb2R1bGU6 IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdAo+Pj4gwqAgwqAgKy0tcncgYWNjZXNzLWxpc3Rz Cj4+PiDCoCDCoCDCoCDCoCstLXJ3IGFjbCogW25hbWVdCj4+PiDCoCDCoCDCoCDCoCDCoCAr LS1ydyBuYW1lIMKgIMKgc3RyaW5nCj4+PiDCoCDCoCDCoCDCoCDCoCArLS1ydyB0eXBlPyDC oCBhY2wtdHlwZQo+Pj4gwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNlcwo+Pj4gwqAgwqAgwqAg wqAgwqAgwqAgwqArLS1ydyBhY2UqIFtuYW1lXQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoHN0cmluZwo+Pj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgKy0tcncgbWF0Y2hlcwo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oCstLXJ3IChsMik/Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLToo ZXRoKQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgKy0tcncgZXRo IHttYXRjaC1vbi1ldGh9Pwo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAg wqAgwqAgwqArLS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcz8gwqAgwqAgwqAKPj4+IMKg eWFuZzptYWMtYWRkcmVzcwo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAg wqAgwqAgwqArLS1ydyBkZXN0aW5hdGlvbi1tYWMtYWRkcmVzcy1tYXNrPyDCoAo+Pj4geWFu ZzptYWMtYWRkcmVzcwo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAg wqAgwqArLS1ydyBzb3VyY2UtbWFjLWFkZHJlc3M/IMKgIMKgIMKgIMKgIMKgIMKgCj4+PiB5 YW5nOm1hYy1hZGRyZXNzCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDC oCDCoCDCoCstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcy1tYXNrPyDCoCDCoCDCoAo+Pj4gwqB5 YW5nOm1hYy1hZGRyZXNzCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDC oCDCoCDCoCstLXJ3IGV0aGVydHlwZT8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAK Pj4+IMKgZXRoOmV0aGVydHlwZQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCst LXJ3IChsMyk/Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLTooaXB2 NCkKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCstLXJ3IGlwdjQg e21hdGNoLW9uLWlwdjR9Pwo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8 IMKgIMKgICstLXJ3IGRzY3A/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlu ZXQ6ZHNjcAo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICst LXJ3IGVjbj8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IGxlbmd0aD8g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWludDE2Cj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgdHRsPyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHVpbnQ4Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 IMKgfCDCoHwgwqAgwqAgKy0tcncgcHJvdG9jb2w/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHVpbnQ4Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAg Ky0tcncgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8KPj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgKy0tOihyYW5nZSkKPj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgfCDCoCstLXJ3IHNvdXJj ZS1wb3J0LWxvd2VyIMKgIMKgIMKgIMKgIMKgCj4+PiBpbmV0OnBvcnQtbnVtYmVyCj4+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoHwgwqArLS1ydyBz b3VyY2UtcG9ydC11cHBlciDCoCDCoCDCoCDCoCDCoAo+Pj4gaW5ldDpwb3J0LW51bWJlcgo+ Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqArLS06KG9w ZXJhdG9yKQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwg wqAgwqAgKy0tcncgc291cmNlLW9wZXJhdG9yIMKgIMKgIMKgIMKgIMKgIMKgCj4+PiBvcGVy YXRvcgo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqAg wqAgKy0tcncgc291cmNlLXBvcnQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAKPj4+IGluZXQ6 cG9ydC1udW1iZXIKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDC oCArLS1ydyAoZGVzdGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVyYXRvcik/Cj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoCstLToocmFuZ2UpCj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoHwgwqArLS1y dyBkZXN0aW5hdGlvbi1wb3J0LWxvd2VyIMKgIMKgCj4+PiDCoGluZXQ6cG9ydC1udW1iZXIK Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgfCDCoCst LXJ3IGRlc3RpbmF0aW9uLXBvcnQtdXBwZXIgwqAgwqAKPj4+IMKgaW5ldDpwb3J0LW51bWJl cgo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgIHwgwqArLS06 KG9wZXJhdG9yKQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKg IHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24tb3BlcmF0b3IgwqAgwqAgwqAKPj4+IMKgb3Bl cmF0b3IKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKg IMKgICstLXJ3IGRlc3RpbmF0aW9uLXBvcnQgwqAgwqAgwqAgwqAgwqAKPj4+IMKgaW5ldDpw b3J0LW51bWJlcgo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKg ICstLXJ3IGlobD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+ Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IGZsYWdz PyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJpdHMKPj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBvZmZzZXQ/IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQxNgo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgICstLXJ3IGlkZW50aWZpY2F0aW9uPyDCoCDCoCDCoCDCoCDCoCDC oCB1aW50MTYKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCAr LS1ydyBkZXN0aW5hdGlvbi1pcHY0LW5ldHdvcms/IMKgCj4+PiBpbmV0OmlwdjQtcHJlZml4 Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgc291 cmNlLWlwdjQtbmV0d29yaz8gwqAgwqAgwqAKPj4+IMKgaW5ldDppcHY0LXByZWZpeAo+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqArLS06KGlwdjYpCj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCArLS1ydyBpcHY2IHttYXRjaC1vbi1pcHY2 fT8KPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncg ZHNjcD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5ldDpkc2NwCj4+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGVjbj8gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBsZW5ndGg/IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQxNgo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqAgwqAgwqAgwqArLS1ydyB0dGw/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgdWludDgKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKg IMKgIMKgKy0tcncgcHJvdG9jb2w/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4 Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IChz b3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcik/Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqArLS06KHJhbmdlKQo+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgfCDCoCstLXJ3IHNvdXJjZS1wb3J0 LWxvd2VyIMKgIMKgIMKgIMKgIMKgCj4+PiBpbmV0OnBvcnQtbnVtYmVyCj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqB8IMKgKy0tcncgc291cmNl LXBvcnQtdXBwZXIgwqAgwqAgwqAgwqAgwqAKPj4+IGluZXQ6cG9ydC1udW1iZXIKPj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoCstLToob3BlcmF0 b3IpCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqAg wqAgKy0tcncgc291cmNlLW9wZXJhdG9yIMKgIMKgIMKgIMKgIMKgIMKgCj4+PiBvcGVyYXRv cgo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgIMKg ICstLXJ3IHNvdXJjZS1wb3J0IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgCj4+PiBpbmV0OnBv cnQtbnVtYmVyCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDC oCstLXJ3IChkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKT8KPj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoCstLToocmFuZ2UpCj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqB8IMKgKy0t cncgZGVzdGluYXRpb24tcG9ydC1sb3dlciDCoCDCoAo+Pj4gwqBpbmV0OnBvcnQtbnVtYmVy Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqB8IMKg Ky0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciDCoCDCoAo+Pj4gwqBpbmV0OnBvcnQtbnVt YmVyCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqAr LS06KG9wZXJhdG9yKQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAg wqAgwqB8IMKgIMKgICstLXJ3IGRlc3RpbmF0aW9uLW9wZXJhdG9yIMKgIMKgIMKgCj4+PiDC oG9wZXJhdG9yCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDC oHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24tcG9ydCDCoCDCoCDCoCDCoCDCoAo+Pj4gwqBp bmV0OnBvcnQtbnVtYmVyCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDC oCDCoCDCoCstLXJ3IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29yaz8gwqAKPj4+IGluZXQ6aXB2 Ni1wcmVmaXgKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKg Ky0tcncgc291cmNlLWlwdjYtbmV0d29yaz8gwqAgwqAgwqAKPj4+IMKgaW5ldDppcHY2LXBy ZWZpeAo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1y dyBmbG93LWxhYmVsPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoAo+Pj4gaW5ldDppcHY2LWZs b3ctbGFiZWwKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyAobDQpPwo+ Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqArLS06KHRjcCkKPj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCstLXJ3IHRjcCB7bWF0Y2gtb24tdGNw fT8KPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBz ZXF1ZW5jZS1udW1iZXI/IMKgIMKgIMKgIMKgIMKgdWludDMyCj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgYWNrbm93bGVkZ2VtZW50LW51bWJl cj8gwqAgdWludDMyCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAg wqAgKy0tcncgZGF0YS1vZmZzZXQ/IMKgIMKgIMKgIMKgIMKgIMKgIMKgdWludDgKPj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyByZXNlcnZlZD8g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWludDgKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBmbGFncz8gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBiaXRzCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAg wqAgKy0tcncgd2luZG93LXNpemU/IMKgIMKgIMKgIMKgIMKgIMKgIMKgdWludDE2Cj4+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgdXJnZW50LXBv aW50ZXI/IMKgIMKgIMKgIMKgIMKgIHVpbnQxNgo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IG9wdGlvbnM/IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgdWludDMyCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLToo dWRwKQo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgKy0tcncgdWRw IHttYXRjaC1vbi11ZHB9Pwo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8 IMKgIMKgICstLXJ3IGxlbmd0aD8gwqAgdWludDE2Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgfCDCoCstLTooaWNtcCkKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqB8IMKgIMKgICstLXJ3IGljbXAge21hdGNoLW9uLWljbXB9Pwo+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyB0eXBlPyDCoCDCoCDCoCDCoCDC oCDCoCB1aW50OAo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAg wqArLS1ydyBjb2RlPyDCoCDCoCDCoCDCoCDCoCDCoCB1aW50OAo+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyByZXN0LW9mLWhlYWRlcj8gwqAg dWludDMyCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgKy0tcncgZWdyZXNzLWlu dGVyZmFjZT8gwqAgwqBpZjppbnRlcmZhY2UtcmVmCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgKy0tcncgaW5ncmVzcy1pbnRlcmZhY2U/IMKgIGlmOmludGVyZmFjZS1yZWYK Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IGFjdGlvbnMKPj4+IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyBmb3J3YXJkaW5nIMKgIMKgaWRlbnRpdHlyZWYK Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyBsb2dnaW5nPyDCoCDCoCDC oGlkZW50aXR5cmVmCj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBzdGF0aXN0 aWNzIHthY2wtYWdncmVnYXRlLXN0YXRzfT8KPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2NAo+Pj4gwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5 YW5nOmNvdW50ZXI2NAo+Pj4KPj4+IMKgIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50 ZXJmYWNlOgo+Pj4gwqAgwqAgKy0tcncgYWNscwo+Pj4gwqAgwqAgwqAgwqArLS1ydyBpbmdy ZXNzCj4+PiDCoCDCoCDCoCDCoHwgwqArLS1ydyBhY2wtc2V0cwo+Pj4gwqAgwqAgwqAgwqB8 IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKg IMKgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoC0+IC9hY2Nlc3MtbGlzdHMvYWNs L25hbWUKPj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKg IMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUKPj4+IMKgIMKgIMKgIMKgfCDC oCDCoCDCoCDCoCstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0 c30/Cj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbmFtZSDCoCDCoCDC oCDCoCDCoCDCoCDCoCAtPgo+Pj4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+ Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtcGFja2V0cz8g wqAgeWFuZzpjb3VudGVyNjQKPj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCArLS1y byBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNvdW50ZXI2NAo+Pj4gwqAgwqAgwqAgwqAr LS1ydyBlZ3Jlc3MKPj4+IMKgIMKgIMKgIMKgIMKgICstLXJ3IGFjbC1zZXRzCj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4gwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoC0+IC9hY2Nlc3Mt bGlzdHMvYWNsL25hbWUKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IHR5cGU/ IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUKPj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVy ZmFjZS1zdGF0c30/Cj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG5h bWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLT4KPj4+IC9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMv YWNlL25hbWUKPj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8gbWF0Y2hl ZC1wYWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2NAo+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqArLS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNvdW50ZXI2NAo+Pj4K Pj4+IENvbW1lbnRzIHdlbGNvbWUhCj4+Pgo+Pj4gQ2hlZXJzLAo+Pj4KPj4+IEVpbmFyCj4+ Pgo+Pj4KPj4+Cj4+Pj4gT24gMTQgRGVjIDIwMTcsIGF0IDE4OjUwLCBFaW5hciBOaWxzZW4t TnlnYWFyZCAoZWluYXJubikKPj4+PiA8ZWluYXJubkBjaXNjby5jb20gPG1haWx0bzplaW5h cm5uQGNpc2NvLmNvbT4+IHdyb3RlOgo+Pj4+Cj4+Pj4KPj4+Pgo+Pj4+PiBPbiAxNCBEZWMg MjAxNywgYXQgMDg6MjEsIFNvbmFsIEFnYXJ3YWwgPHNhZ2Fyd2FsMTJAZ21haWwuY29tCj4+ Pj4+IDxtYWlsdG86c2FnYXJ3YWwxMkBnbWFpbC5jb20+PiB3cm90ZToKPj4+Pj4KPj4+Pj4g SGkgRWluYXIsCj4+Pj4+Cj4+Pj4+IFlvdSBoYWQgMyBxdWVzdGlvbnMgZm9yIG1lIG9uIGFs bCB0aGUgc2V2ZXJhbCBlLW1haWwgdGhyZWFkcy7CoAo+Pj4+PiAxLiBHbG9iYWwgYXR0YWNo bWVudCBwb2ludAo+Pj4+PiAyLiBpY21wLW9mZgo+Pj4+PiAzLiBhY2wtYWdncmVnYXRlLWlu dGVyZmFjZSBzdGF0cy4KPj4+Pj4KPj4+Pj4gRm9yICgxKSwgbXkgZmlyc3QgcHJlZmVyZW5j ZSBpcyB0byBoYXZlIHRoZSBtb2RlbCBkZWZpbmUKPj4+Pj4gYXR0YWNobWVudCBwb2ludCBm b3IgaW50ZXJmYWNlcyBvbmx5Lgo+Pj4+Cj4+Pj4gZWluYXJubj4gSSBoYXZlIHNvbWUgZGlm ZnMsIGxheWVyZWQgb24gdG9wIG9mIE1haGVzaOKAmXMgUFIgdG8KPj4+PiBuZXRtb2Qtd2cv YWNsLW1vZGVsIHRoYXQgZG8gdGhpcy4gTmVhcmx5IGxpa2UgdGhlIGF1Z21lbnRhdGlvbiBJ Cj4+Pj4gaGF2ZSBiZWxvdy4gRmVlbCBmcmVlIHRvIHRha2UgYSBsb29rIGF0Ogo+Pj4+Cj4+ Pj4gICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9tamV0aGFuYW5kYW5pL2FjbC1tb2RlbC9wdWxs LzMKPj4+Pgo+Pj4+Cj4+Pj4+IEhvd2V2ZXIsIEtyaXN0aWFuIHdhbnRzIHRoZSBnbG9iYWwg YXR0YWNobWVudCBwb2ludCBhcyB3ZWxsIHNvCj4+Pj4+IHRoYXQgaGUgY2FuIGFkZCB0aGUg QUNMIHRvIHRoZSBsaW51eCB0YWJsZXMuCj4+Pj4KPj4+PiBlaW5hcm5uPiBJIHRoaW5rIEty aXN0aWFuIGRvZXNu4oCZdCBmZWVsIGEgZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnQKPj4+PiBu ZWVkcyB0byBiZSBpbiB0aGlzIGZpcnN0IHJldmlzaW9uLiBCdXQgaGUgY2FuIGNvbmZpcm0u Cj4+Pj4KPj4+Pj4gSWYgYW4gQUNMIGlzIGF0dGFjaGVkIGdsb2JhbGx5LCBkb2VzIHRoaXMg bWVhbiBpdCBpcyBwZXIgZGlyZWN0aW9uCj4+Pj4+IG9yIGRvZXMgaXQgbWVhbiBpdCBpcyBh Y3Jvc3MgZGlyZWN0aW9ucz8KPj4+Pgo+Pj4+IGVpbmFybm4+IEkgZG9u4oCZdCBrbm93IHJp Z2h0IG5vdyA6LSkKPj4+Pgo+Pj4+PiBUaGlzIGdsb2JhbCBBQ0wgbWF5IG5vdCBiZSBhcHBs aWNhYmxlIHRvIGFueSBvZiBDaXNjbydzIHNlcnZpY2UKPj4+Pj4gcHJvdmlkZXIgcm91dGVy cyBhcyBJIGRvbid0IHNlZSBhbnkgcGxhdGZvcm0gYWN0dWFsbHkgcmVwbGljYXRpbmcKPj4+ Pj4gdGhlIEFDTCB0byBhbGwgbGluZSBjYXJkcyBhbmQgYXR0YWNoaW5nIGl0IGluIGluZ3Jl c3MgYW5kIGVncmVzcwo+Pj4+PiBkaXJlY3Rpb25zIGFjcm9zcyBhbGwgaW50ZXJmYWNlcy4K Pj4+Pgo+Pj4+IGVpbmFybm4+IFBlciBvdGhlciBlbWFpbHMsIEkgZG9u4oCZdCB0aGluayB3 ZSB1bmRlcnN0YW5kIHRoaXMgZW5vdWdoCj4+Pj4geWV0IHRvIHNwZWNpZnkgaXQsIHNvIEkg c3VnZ2VzdCB3ZSBqdXN0IGxlYXZlIGl0IG91dCBmb3Igbm93Lgo+Pj4+IE5vdGhpbmcgaW4g dGhlIG1vZGVsIHByZXZlbnRzIGEg4oCcZ2xvYmFsIGF0dGFjaG1lbnQgcG9pbnTigJ0gYmVp bmcKPj4+PiBhZGRlZCBsYXRlciBvbmNlIHdlIHVuZGVyc3RhbmQgd2hhdCBpdCByZWFsbHkg bWVhbnMuCj4+Pj4KPj4+Pj4gRm9yICgyKSwgSSBhbSBvayB3aXRoIHJlbW92aW5nIGljbXAt b2ZmLgo+Pj4+Cj4+Pj4gZWluYXJubj4gRG9uZSBpbiBteSBQUiBhYm92ZS4KPj4+Pgo+Pj4+ PiBGb3IgKDMpLCB0aGlzIHdvdWxkIGhhdmUgdG8gYmUgYSBjb21iaW5hdGlvbiBvZiBBQ0wg c3RhdHMgYWNyb3NzCj4+Pj4+IGFsbCBpbnRlcmZhY2VzIGZvciBhbGwgQUNMJ3MuIFNvbWV0 aGluZyBsaWtlIHRoaXMgaXMgcG9zc2libGUgb24KPj4+Pj4gYW4gWFIgYm94IHdoZXJlIEFD RVMgaGF2ZSBjb3VudGVyIG5hbWVzIGFzc29jaWF0ZWQgd2l0aCBpdC4gTGV0J3MKPj4+Pj4g Y2hhdCBhYm91dCB0aGlzIG9mZmxpbmUgdG9tb3Jyb3cuCj4+Pj4KPj4+PiBlaW5hcm5uPiBJ 4oCZbGwgcGluZyB5b3UgdG8gY2xhcmlmeSwgYW5kIHdlIGNhbiBicmluZyBhbnkgY29uY2x1 c2lvbgo+Pj4+IGJhY2sgdG8gdGhlIGxpc3QuCj4+Pj4KPj4+PiBDaGVlcnMsCj4+Pj4KPj4+ PiBFaW5hcgo+Pj4+Cj4+Pj4KPj4+Pgo+Pj4+PiBTb25hbC4KPj4+Pj4KPj4+Pj4KPj4+Pj4g T24gV2VkLCBEZWMgMTMsIDIwMTcgYXQgMTI6MTAgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkK Pj4+Pj4gPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tIDxtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20+PiB3cm90ZToKPj4+Pj4KPj4+Pj4gICAgIFdlIHdhbnQgdG8gc3VwcG9ydCDi gJxnbG9iYWzigJ0gYXR0YWNobWVudCBwb2ludCBkb3duIHRoZSBsaW5lLAo+Pj4+PiAgICAg YW5kIHRoYXQg4oCcZ2xvYmFs4oCdIGF0dGFjaG1lbnQgcG9pbnQgd2lsbCBiZSBvbmUgb2Yg dGhlIGNob2ljZXMKPj4+Pj4gICAgICh0aGUgb3RoZXIgYmVpbmcgdGhlIGludGVyZmFjZSks IHdoYXQgd291bGQgdGhpcyBhdWdtZW50IGxvb2sKPj4+Pj4gICAgIGxpa2UuIE5vdGUsIGFz IGZhciBhcyBJIGtub3csIHlvdSBjYW5ub3QgYXVnbWVudCBpbnNpZGUgYQo+Pj4+PiAgICAg Y2hvaWNlIG5vZGUuCj4+Pj4+Cj4+Pj4+PiAgICAgT24gRGVjIDEzLCAyMDE3LCBhdCA2OjU3 IEFNLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikKPj4+Pj4+ICAgICA8ZWluYXJu bkBjaXNjby5jb20gPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+IHdyb3RlOgo+Pj4+Pj4K Pj4+Pj4+ICAgICBQZXJoYXBzIGxpa2UgdGhpcywgYXMgYW4gYXVnbWVudGF0aW9uIHRvIHRo ZSBpbnRlcmZhY2U6Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICDCoCBhdWdtZW50IC9pZjppbnRl cmZhY2VzL2lmOmludGVyZmFjZToKPj4+Pj4+ICAgICAgICAgwqAgwqAgKy0tcncgaW5ncmVz cy1hY2xzCj4+Pj4+PiAgICAgICAgIMKgIMKgIHwgwqArLS1ydyBhY2wtc2V0cwo+Pj4+Pj4g ICAgICAgICDCoCDCoCB8IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4+Pj4gICAg ICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDC oC0+Cj4+Pj4+PiAgICAgICAgIC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUKPj4+Pj4+ICAgICAg ICAgwqAgwqAgfCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+ Cj4+Pj4+PiAgICAgICAgIC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUKPj4+Pj4+ICAgICAgICAg wqAgwqAgfCDCoCDCoCDCoCDCoCstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVy ZmFjZS1zdGF0c30/Cj4+Pj4+PiAgICAgICAgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgKy0t cm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+Pj4+Pj4gICAgICAgICAvYWNjZXNz LWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lCj4+Pj4+PiAgICAgICAgIMKgIMKgIHwgwqAgwqAg wqAgwqAgwqAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2NAo+Pj4+ Pj4gICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtb2N0ZXRz PyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+Pj4+PiAgICAgICAgIMKgIMKgICstLXJ3IGVncmVz cy1hY2xzCj4+Pj4+PiAgICAgICAgIMKgIMKgIMKgIMKgKy0tcncgYWNsLXNldHMKPj4+Pj4+ ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldCogW25hbWVdCj4+Pj4+PiAg ICAgICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDC oCDCoC0+Cj4+Pj4+PiAgICAgICAgIC9hY2Nlc3MtbGlzdHMvYWNsL25hbWUKPj4+Pj4+ICAg ICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ydyB0eXBlPyDCoCDCoCDCoCDCoCDCoCDC oCAtPgo+Pj4+Pj4gICAgICAgICAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4+Pj4+PiAgICAg ICAgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7 aW50ZXJmYWNlLXN0YXRzfT8KPj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+Pj4+Pj4gICAgICAgICAv YWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9uYW1lCj4+Pj4+PiAgICAgICAgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtcGFja2V0cz8gwqAgeWFuZzpjb3VudGVy NjQKPj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbWF0Y2hl ZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAg IENvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPigJ0gY29udGFpbmVyIGFib3ZlIGJvdGggdGhl c2UgJiByZW5hbWUKPj4+Pj4+ICAgICDigJxpbmdyZXNzLWFjbHMiIHRvIOKAnGluZ3Jlc3Pi gJ0sIGV0Yy4gdG8gZ2l2ZSBhIHNpbmdsZSByb290IGZvcgo+Pj4+Pj4gICAgIHRoZSBhdWdt ZW50YXRpb24gaWYgcHJlZmVycmVkLgo+Pj4+Pj4KPj4+Pj4+ICAgICBDaGVlcnMsCj4+Pj4+ Pgo+Pj4+Pj4gICAgIEVpbmFyCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+PiAgICAgT24gNiBEZWMg MjAxNywgYXQgMTk6NDMsIEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tCj4+Pj4+Pj4gICAg IDxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToKPj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+ Pj4KPj4+Pj4+PiAgICAgT24gMTIvNi8xNyA3OjIzIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5p IHdyb3RlOgo+Pj4+Pj4+PiAgICAgSG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBh dHRhY2htZW50IHBvaW50LCBjdXJyZW50bHkgYW4KPj4+Pj4+Pj4gICAgICdpbnRlcmZhY2Ut cmVmJywgdG8gYW4gYXVnbWVudGF0aW9uIG9mIHRoZQo+Pj4+Pj4+PiAgICAgaWY6aW50ZXJm YWNlcy9pbnRlcmZhY2UsCj4+Pj4+Pj4+ICAgICBpbnNpZGUgb2YgdGhlIOKAmGFjbOKAmSDC oGNvbnRhaW5lcj8gRG93biB0aGUgbGluZSB3ZSBtaWdodCBuZWVkCj4+Pj4+Pj4+ICAgICB0 byBoYXZlIGFuCj4+Pj4+Pj4+ICAgICBjb250YWluZXIgZm9yICJhdHRhY2htZW50IHBvaW50 cyIgdG8gYWNjb21tb2RhdGUgdGhlCj4+Pj4+Pj4+ICAgICBwb3NzaWJpbGl0eSBvZgo+Pj4+ Pj4+PiAgICAgYXR0YWNoaW5nIGFuIEFDTCBlaXRoZXIgdG8gYW4gaW50ZXJmYWNlIG9yIOKA nGdsb2JhbGx54oCdLgo+Pj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gICAgIEtlZXBpbmcgaW4g bWluZCB0aGF0IG9uZSB1c2UgaXMgdGhhdCBhbiBBQ0wgZG9lc24ndCBhdHRhY2ggdG8gYW4K Pj4+Pj4+PiAgICAgaW50ZXJmYWNlIGF0IGFsbC4KPj4+Pj4+Pgo+Pj4+Pj4+ICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4+ICAg ICBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+Pj4gICAgIG5ldG1vZEBpZXRmLm9yZyA8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz4KPj4+Pj4+PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QKPj4+Pj4+PiAgICAgPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPgo+Pj4+Pj4KPj4+Pj4KPj4+Pj4gICAgIE1h aGVzaCBKZXRoYW5hbmRhbmkKPj4+Pj4gICAgIG1qZXRoYW5hbmRhbmlAZ21haWwuY29tIDxt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Cj4+Pj4+Cj4+Pj4+Cj4+Pj4+ICAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+PiAg ICAgbmV0bW9kIG1haWxpbmcgbGlzdAo+Pj4+PiAgICAgbmV0bW9kQGlldGYub3JnIDxtYWls dG86bmV0bW9kQGlldGYub3JnPgo+Pj4+PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QKPj4+Pj4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZD4KPj4+Pj4KPj4+Pj4KPj4+Pgo+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4gbmV0bW9kIG1h aWxpbmcgbGlzdAo+Pj4+IG5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+ Pj4KPj4+Cj4+Pgo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPj4+IG5ldG1vZEBpZXRmLm9yZwo+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKPj4KPgoK --------------FBF992787B1F134B8E13B6C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

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


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

Nothing can force an implementation to have to implement either the=C2=A0ietf-interfaces model or the augmentati= on 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 u= se 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:
=

=C2=A0 augment /if:interfaces/if:interface:
=C2=A0 =C2=A0 += --rw acls {interface-at= tachment}?
=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}?<= /div>
=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-&= gt; /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.
    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:

https://githu= b.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:
=

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" (should be date)<= /font>
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
=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 matche= s
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--r= w (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-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=A0= eth:ethertype
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--r= w (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<= /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 +--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<= /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 +--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=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-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<= /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 +--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-pref= ix
=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=A0= inet: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<= /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+--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<= /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+--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=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-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-pref= ix
=C2= =A0 =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=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 flow-label? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv6-fl= ow-label
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--r= w (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 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 {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-header? =C2=A0 uint32
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--r= w 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+--r= w ingress-interface? =C2=A0 if:interface-ref
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw action= s
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--r= w forwarding =C2=A0 =C2=A0identityref
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--r= w logging? =C2=A0 =C2=A0 =C2=A0identityref
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro statis= tics {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 class=3D"">
=C2= =A0 augment /if:interfaces/if:interface:
=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
=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-st= atistics* [name] {interface-stats}?
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--r= o 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 +--r= o matched-packets? =C2=A0 yang:counter64
=C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--r= o 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-st= atistics* [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 <s= agarwal12@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:

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 Kristia= n 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 understa= nd 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 atta= chment 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 pi= ng you to clarify, and we can bring any conclusion back to the list.

Cheers,

Einar



Sonal.


On Wed, De= c 13, 2017 at 12:10 PM, Mahesh Jethanandani <mjetha= nandani@gmail.com> wrote:
We want to support =E2=80=9Cglobal=E2=80=9D attach= ment point down the line, and that =E2=80=9Cglo= bal=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 De= c 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:

Perhap= s like this, as an augmentation to the interface:
<= br class=3D"">
=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
<= br class=3D"">
C= ould 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.
<= br class=3D"">
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


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



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



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



--------------FBF992787B1F134B8E13B6C4-- --7BHQ3TjKjvAsJST6VRKc53b4AX6OKFqV1-- --bO47PHitjwMhuEuOE9E994HSX50p9BPui Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlo3tScACgkQh7ZrRtnS ejPLvggAxsjeb5nylSBvDslmAx2zrNNBlrutkDyqQM4GWhBCyiEHAfXr7Zusa9tO s0C3Dz4Qamk6oxUq+JvUmy+De+XQudypp2FSNhUQDbdiuM6z5HITWsIar3exwVF5 fs1ecIOmgFa34KmgfD50ASUzstbO+fRRkKECxpa7JpALOLlwIKkQa/wlugG/l7cF OAbor1J2Dt91cKKLSereZQDKb0xGQQqVVaT9ISENUTgPmQh4F7JrITMJkUrHpeRU pTz72MK204GgWA7AvRYTBtj79SjyvOZdpK2rs7Gbl43S6PXS3FZliXmesTJ7QaGL U8mPZ2lF6/viVQCW/WaBFVJLqvEO4Q== =+XD8 -----END PGP SIGNATURE----- --bO47PHitjwMhuEuOE9E994HSX50p9BPui-- From nobody Mon Dec 18 04:54:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3644126CBF; Mon, 18 Dec 2017 04:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.631 X-Spam-Level: X-Spam-Status: No, score=-12.631 tagged_above=-999 required=5 tests=[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 aTwLr_ZfvZuA; Mon, 18 Dec 2017 04:54:50 -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 27B34120727; Mon, 18 Dec 2017 04:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4070; q=dns/txt; s=iport; t=1513601690; x=1514811290; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IzigOWqOu+mj+Bu6sPjkQcks6Npr3ZcLh03GDZa7oFw=; b=UX8tGUnTlyKnXP2gbDu+lA+d6dbVTcJt40v3lCGQpuoLqxaje9d3mL+p 7OWkoqyb2PCJlqxWL6UDzM4u6HVkBmdBNCsreaPNeGvYJGyE/hPd32Nri pZJLMwy/lEzZq+gKUHPdeXsvUMR6djfwzjCrVNLe+xi/Z/GJ9AG/1LsaJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAAA2ujda/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N/iiGPCIIAlyGCFQoYC4RJTwIahGs/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSQBAQQBASEROgsQAgEIGAICJgICAiULFRACBAENBYoqEKoTgieKZwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CX4IOgz+DLIMuARiBVheCfoJjBaM8Aod?= =?us-ascii?q?9jS2CFoYTi0qKTYJOiTACERkBgToBHzmBT28VPIIphFZ4AYkAgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,422,1508803200"; d="scan'208";a="333493505" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Dec 2017 12:54:49 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBICsmbF005561 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Dec 2017 12:54:49 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; Mon, 18 Dec 2017 07:54:47 -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, 18 Dec 2017 07:54:48 -0500 From: "Acee Lindem (acee)" To: Vladimir Vassilev , Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-01 Thread-Index: AQHTdecPhSAo6kKOv0CHaR8SVGCwjKNHxIIAgAGI84D//8VpgA== Date: Mon, 18 Dec 2017 12:54:48 +0000 Message-ID: References: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net> <44e5318a-4157-b825-b688-5185ab2458cb@labn.net> <43f78a5f-9485-05cc-dd11-2ff29ced6120@transpacket.com> In-Reply-To: <43f78a5f-9485-05cc-dd11-2ff29ced6120@transpacket.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: <87585530BDFEDD40990D3F506093C32E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-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, 18 Dec 2017 12:54:51 -0000 SGkgVmxhZGltaXIsIA0KDQpPbiAxMi8xOC8xNywgNjoyNCBBTSwgIlZsYWRpbWlyIFZhc3NpbGV2 IiA8dmxhZGltaXJAdHJhbnNwYWNrZXQuY29tPiB3cm90ZToNCg0KPg0KPg0KPk9uIDEyLzE3LzIw MTcgMDU6NTcgUE0sIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4+IEhpIExvdSwgZXQgYWws DQo+Pg0KPj4gVGhlIG9ubHkgaXNzdWUgd2UgYXJlIHN0cnVnZ2xpbmcgd2l0aCBpcyB3aGV0aGVy IHdlIG5lZWQgdG8gc3BlY2lmeSB0aGUNCj4+IHZlcnNpb24gaW4gdGhlIGlldGYtaW50ZXJmYWNl cyBpbXBvcnQuIFdlIGhhdmUgbm90ZWQgdGhhdA0KPj4gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzI3 N2Jpcy0wMS50eHQgZG9lcyBub3QgaW1wb3J0IGJ5IHJldmlzaW9uLg0KPj4NCj4+IFdlIGFsc28g aGF2ZSBzbyBuaXRzOg0KPj4NCj4+ICAgICAxLiBBZGQgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNl IGZvcg0KPj4gW0ktRC5pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXNdLg0KPj4gICAgIDIu IEJhc2VkIG9uIGEgY29tbWVudCBmcm9tIFZsYWRpbWlyLCB3ZSBhZGRlZCB0aGUgcHJlZml4IGZv cg0KPj4gaWV0Zi1yb3V0aW5nLnlhbmcsIOKAnHJ0OuKAnSwgdG8gc2V2ZXJhbCByZWZlcmVuY2Vz IHdpdGhpbg0KPj5pZXRmLXJvdXRpbmcueWFuZy4NCj4+IFdhcyB0aGlzIG5lY2Vzc2FyeT8gT2Yg Y291cnNlLCB0aGUgbW9kZWwgY29tcGlsZXMgd2l0aCBvciB3aXRob3V0IHRoZQ0KPj4gcHJlZml4 Lg0KPkkgcmV2ZXJ0ZWQgdGhpcyBpbiBhIGZvbGxvdy11cCBjb21tZW50IG9uIHRoZSBzYW1lIHRo cmVhZC4gSSBiZWxpZXZlIHRoZQ0KPmxvY2FsIHByZWZpeGVzIGFyZSByZWR1bmRhbnQuDQoNCkni gJlkIGFscmVhZHkgdXBkYXRlZCB0aGUgZ2l0IHJlcG9zaXRvcnkgYW5kIG5lZ2xlY3RlZCB0byBy ZXZlcnQgaXQuIEkgd2lsbA0KcmV2ZXJ0IGFmdGVyIHJldmlld2luZyBSRkM2MDg3QklTIHJ1bGVz Lg0KDQpUaGFua3MsDQpBY2VlDQoNCj4NCj5WbGFkaW1pcg0KPj4NCj4+IFRoYW5rcywNCj4+IEFj ZWUNCj4+DQo+PiBPbiAxMi8xNS8xNywgMzo1NSBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTG91 IEJlcmdlciINCj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGJlcmdl ckBsYWJuLm5ldD4gd3JvdGU6DQo+Pg0KPj4+IEFsbCwNCj4+PiAJVGhpcyBsYXN0IGNhbGwgaXMg Y2xvc2VkLg0KPj4+DQo+Pj4gV2Ugbm90ZSB0aGF0IHRoZXJlIHdhcyBhbiB1cGRhdGUgZHVyaW5n IHRoZSBMQyBhbmQgdGhhdCBubyBjb21tZW50cw0KPj4+d2VyZQ0KPj4+IHJlY2VpdmVkIGR1cmlu ZyB0aGUgTEMgcGVyaW9kLiAgQXMgdGhpcyBpcyBzaW1wbHkgYSBtZWNoYW5pY2FsIHVwZGF0ZQ0K Pj4+IHRoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBXRyB3ZSBwbGFuIHRvIHByb2NlZWQg d2l0aCB0aGUNCj4+PiBwdWJsaWNhdGlvbiBwcm9jZXNzLg0KPj4+DQo+Pj4gQXV0aG9ycywNCj4+ PiAJUGxlYXNlIGxldC91cyB0aGUgV0cga25vdyB3aGVuIHlvdSBoYXZlIHB1Ymxpc2hlZCBhIHZl cnNpb24gcmVhZHkgZm9yDQo+Pj4gcHVibGljYXRpb24uICBBbHNvIHBsZWFzZSBsZXQgdGhlIFdH IGtub3cgd2hhdCBoYXMgY2hhbmdlZCBpbiB0aGUNCj4+PiBkb2N1bWVudCBzaW5jZSB0aGUgc3Rh cnQgb2YgTEMgKHJldiAtMDEpDQo+Pj4NCj4+PiBUaGFuayB5b3UsDQo+Pj4gTmV0TW9kIENoYWly cw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIDExLzI5LzIwMTcgMTI6MjYgUE0sIExvdSBCZXJnZXIg d3JvdGU6DQo+Pj4+IEFsbCwNCj4+Pj4NCj4+Pj4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPj4+PiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM4MDIyYmlz LTAxLg0KPj4+Pg0KPj4+PiBQbGVhc2UgcmVjYWxsIHRoYXQgdGhpcyB1cGRhdGUncyBpbnRlbnRp b24gaXMgdG8NCj4+Pj4gbW9kaWZ5IHRoZSBZQU5HIG1vZHVsZSB0byBiZSBpbiBsaW5lIHdpdGgg dGhlIE5NREENCj4+Pj4gZ3VpZGVsaW5lcyBbMV0uICBSZXZpZXdpbmcgdGhlIGRpZmYgYmV0d2Vl biB0aGUgdHdvDQo+Pj4+IGRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRoaXMuDQo+Pj4+ DQo+Pj4+IFRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIERlY2VtYmVyIDEzLg0K Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBuZXRtb2QgbWFpbGluZyBsaXN0 Lg0KPj4+Pg0KPj4+PiBQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudA0KPj4+PiBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24i LCBhcmUgd2VsY29tZSENCj4+Pj4gVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBm cm9tIGF1dGhvcnMuDQo+Pj4+DQo+Pj4+IFsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDENCj4+Pj4gWzJdDQo+Pj4+IA0KPj4+Pmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZ1cmwxPXJmYzgwMjIu dHh0JnVybDI9DQo+Pj4+ZHINCj4+Pj4gYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDEudHh0 DQo+Pj4+DQo+Pj4+IFRoYW5rIHlvdSwNCj4+Pj4gTmV0bW9kIENoYWlycw0KPj4+Pg0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9k QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KPg0KDQo= From nobody Mon Dec 18 04:55:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E24126CBF; Mon, 18 Dec 2017 04:55:38 -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=[none] 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 SR53-lZKpshm; Mon, 18 Dec 2017 04:55:36 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9A60C120727; Mon, 18 Dec 2017 04:55:35 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id A567B18203FB; Mon, 18 Dec 2017 13:19:36 +0100 (CET) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id B6C4418203F5; Mon, 18 Dec 2017 13:19:33 +0100 (CET) From: Ladislav Lhotka To: "Acee Lindem \(acee\)" , Lou Berger , NetMod WG Cc: NetMod WG Chairs In-Reply-To: References: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net> <44e5318a-4157-b825-b688-5185ab2458cb@labn.net> Mail-Followup-To: "Acee Lindem \(acee\)" , Lou Berger , NetMod WG , NetMod WG Chairs Date: Mon, 18 Dec 2017 13:19:42 +0100 Message-ID: <8737482ppd.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-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, 18 Dec 2017 12:55:38 -0000 Hi Acee, "Acee Lindem (acee)" writes: > Hi Lou, et al,=20 > > The only issue we are struggling with is whether we need to specify the > version in the ietf-interfaces import. We have noted that > draft-ietf-netmod-rfc7277bis-01.txt does not import by revision. I would suggest to import *without* revision but add a description indicating that the NMDA-compatible revisions are needed. Importing by revision is clearly suboptimal. Hopefully a new mechanism such as semantic versioning will be introduced soon to alleviate this issue. > > We also have so nits: > > 1. Add an informative reference for > [I-D.ietf-netmod-yang-tree-diagrams]. > 2. Based on a comment from Vladimir, we added the prefix for > ietf-routing.yang, =E2=80=9Crt:=E2=80=9D, to several references within ie= tf-routing.yang. > Was this necessary? Of course, the model compiles with or without the > prefix. RFC6087bis has some rules in sec. 4.2, and these should be followed. Also, the security considerations should IMO be changed, see my recent message: https://www.ietf.org/mail-archive/web/netmod/current/msg19610.html Of course, the NEW formulation needn't be exactly as I suggested, but the text "The YANG module [...] is designed to be accessed ..." is apparently wrong and shouldn't be used any more. Thanks, Lada > > Thanks, > Acee > > On 12/15/17, 3:55 PM, "netmod on behalf of Lou Berger" > wrote: > >>All, >> This last call is closed. >> >>We note that there was an update during the LC and that no comments were >>received during the LC period. As this is simply a mechanical update >>that has been discussed in the WG we plan to proceed with the >>publication process. >> >>Authors, >> Please let/us the WG know when you have published a version ready for >>publication. Also please let the WG know what has changed in the >>document since the start of LC (rev -01) >> >>Thank you, >>NetMod Chairs >> >> >> >>On 11/29/2017 12:26 PM, Lou Berger wrote: >>> All, >>>=20 >>> This starts a two-week working group last call on >>> draft-ietf-netmod-rfc8022bis-01. >>>=20 >>> Please recall that this update's intention is to >>> modify the YANG module to be in line with the NMDA >>> guidelines [1]. Reviewing the diff between the two >>> drafts [2] should reveal just this. >>>=20 >>> The working group last call ends on December 13. >>> 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 >>> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 >>> [2]=20 >>>https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Drfc8022.txt&ur= l2=3Ddr >>>aft-ietf-netmod-rfc8022bis-01.txt >>>=20 >>> Thank you, >>> Netmod Chairs >>>=20 >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Dec 18 04:56:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120AB128954; Mon, 18 Dec 2017 04:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.631 X-Spam-Level: X-Spam-Status: No, score=-12.631 tagged_above=-999 required=5 tests=[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 HXmhqbqlC5eA; Mon, 18 Dec 2017 04:56:36 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79441128896; Mon, 18 Dec 2017 04:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5018; q=dns/txt; s=iport; t=1513601796; x=1514811396; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/g1PjmJqCCxg21I6Qolyh6FM5LzfOQPt8a/4KCG3yyE=; b=OK/3thmi0iLybE76kEQqwJWZN8YL9jgL5JgJ4XvaT2tXxxR1fajpEBYW 8G2pvYcaa5GSAT2Jmx4JyLIFXvOzgimTiXwK3nX7EUy8wontCcFbCfwYN jVg8VnRS3DjC9NesYQflFE961Gl7vSRND4/ISCazPSbNlEI7eufyTAQAj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAAACujda/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N/iiGOVDSCAJchghUKGAuESU8CGoRrPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUkAQEEAQEhEToLEAIBCBgCAiYCAgIlCxUQAgQBDQWKKhCqEYInimcBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgl+CDoM/gyyCUF4BGIE2AQEeF4J+gmM?= =?us-ascii?q?FozwCh32NLYIWhhOLSopNgk6JMAIRGQGBOgEfOYFPbxU8gimEVngBh1uBJYEVA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.45,422,1508803200"; d="scan'208";a="45568014" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Dec 2017 12:56:35 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBICuZe6003813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Dec 2017 12:56:35 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; Mon, 18 Dec 2017 07:56:34 -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, 18 Dec 2017 07:56:34 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , Lou Berger , NetMod WG CC: NetMod WG Chairs Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-01 Thread-Index: AQHTdecPhSAo6kKOv0CHaR8SVGCwjKNHxIIAgAGYeAD//7ZngA== Date: Mon, 18 Dec 2017 12:56:34 +0000 Message-ID: References: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net> <44e5318a-4157-b825-b688-5185ab2458cb@labn.net> <8737482ppd.fsf@nic.cz> In-Reply-To: <8737482ppd.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: <8E7DF4F1A60DC14EA852044687542A29@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-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, 18 Dec 2017 12:56:38 -0000 SGkgTGFkYSwgDQoNCk9uIDEyLzE4LzE3LCA3OjE5IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhv dGthQG5pYy5jej4gd3JvdGU6DQoNCj5IaSBBY2VlLA0KPg0KPiJBY2VlIExpbmRlbSAoYWNlZSki IDxhY2VlQGNpc2NvLmNvbT4gd3JpdGVzOg0KPg0KPj4gSGkgTG91LCBldCBhbCwgDQo+Pg0KPj4g VGhlIG9ubHkgaXNzdWUgd2UgYXJlIHN0cnVnZ2xpbmcgd2l0aCBpcyB3aGV0aGVyIHdlIG5lZWQg dG8gc3BlY2lmeSB0aGUNCj4+IHZlcnNpb24gaW4gdGhlIGlldGYtaW50ZXJmYWNlcyBpbXBvcnQu IFdlIGhhdmUgbm90ZWQgdGhhdA0KPj4gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzI3N2Jpcy0wMS50 eHQgZG9lcyBub3QgaW1wb3J0IGJ5IHJldmlzaW9uLg0KPg0KPkkgd291bGQgc3VnZ2VzdCB0byBp bXBvcnQgKndpdGhvdXQqIHJldmlzaW9uIGJ1dCBhZGQgYSBkZXNjcmlwdGlvbg0KPmluZGljYXRp bmcgdGhhdCB0aGUgTk1EQS1jb21wYXRpYmxlIHJldmlzaW9ucyBhcmUgbmVlZGVkLg0KPg0KPklt cG9ydGluZyBieSByZXZpc2lvbiBpcyBjbGVhcmx5IHN1Ym9wdGltYWwuIEhvcGVmdWxseSBhIG5l dyBtZWNoYW5pc20NCj5zdWNoIGFzIHNlbWFudGljIHZlcnNpb25pbmcgd2lsbCBiZSBpbnRyb2R1 Y2VkIHNvb24gdG8gYWxsZXZpYXRlIHRoaXMNCj5pc3N1ZS4NCg0KSSBhZ3JlZSBhbmQgd2lsbCB1 cGRhdGUgdGhlIGRlc2NyaXB0aW9uLg0KPg0KPj4NCj4+IFdlIGFsc28gaGF2ZSBzbyBuaXRzOg0K Pj4NCj4+ICAgIDEuIEFkZCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgZm9yDQo+PiBbSS1ELmll dGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10uDQo+PiAgICAyLiBCYXNlZCBvbiBhIGNvbW1l bnQgZnJvbSBWbGFkaW1pciwgd2UgYWRkZWQgdGhlIHByZWZpeCBmb3INCj4+IGlldGYtcm91dGlu Zy55YW5nLCDigJxydDrigJ0sIHRvIHNldmVyYWwgcmVmZXJlbmNlcyB3aXRoaW4NCj4+aWV0Zi1y b3V0aW5nLnlhbmcuDQo+PiBXYXMgdGhpcyBuZWNlc3Nhcnk/IE9mIGNvdXJzZSwgdGhlIG1vZGVs IGNvbXBpbGVzIHdpdGggb3Igd2l0aG91dCB0aGUNCj4+IHByZWZpeC4NCj4NCj5SRkM2MDg3Ymlz IGhhcyBzb21lIHJ1bGVzIGluIHNlYy4gNC4yLCBhbmQgdGhlc2Ugc2hvdWxkIGJlIGZvbGxvd2Vk Lg0KDQpXaWxsIHJldmlldyB0aGVzZS4gDQo+DQo+QWxzbywgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNob3VsZCBJTU8gYmUgY2hhbmdlZCwgc2VlIG15IHJlY2VudA0KPm1lc3NhZ2U6DQo+ DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9t c2cxOTYxMC5odG1sDQo+DQo+T2YgY291cnNlLCB0aGUgTkVXIGZvcm11bGF0aW9uIG5lZWRuJ3Qg YmUgZXhhY3RseSBhcyBJIHN1Z2dlc3RlZCwgYnV0DQo+dGhlIHRleHQgIlRoZSBZQU5HIG1vZHVs ZSBbLi4uXSBpcyBkZXNpZ25lZCB0byBiZSBhY2Nlc3NlZCAuLi4iIGlzDQo+YXBwYXJlbnRseSB3 cm9uZyBhbmQgc2hvdWxkbid0IGJlIHVzZWQgYW55IG1vcmUuDQoNCk9rIC0gSSB3aWxsIGFsc28g cmV2aWV3IHRoZSDigJxTZWN1cml0eSBDb25zaWRlcmF0aW9uc+KAnSB0ZW1wbGF0ZS4NCg0KVGhh bmtzLA0KQWNlZSANCg0KPg0KPlRoYW5rcywgTGFkYQ0KPg0KPj4NCj4+IFRoYW5rcywNCj4+IEFj ZWUNCj4+DQo+PiBPbiAxMi8xNS8xNywgMzo1NSBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTG91 IEJlcmdlciINCj4+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGJlcmdl ckBsYWJuLm5ldD4gd3JvdGU6DQo+Pg0KPj4+QWxsLA0KPj4+CVRoaXMgbGFzdCBjYWxsIGlzIGNs b3NlZC4NCj4+Pg0KPj4+V2Ugbm90ZSB0aGF0IHRoZXJlIHdhcyBhbiB1cGRhdGUgZHVyaW5nIHRo ZSBMQyBhbmQgdGhhdCBubyBjb21tZW50cyB3ZXJlDQo+Pj5yZWNlaXZlZCBkdXJpbmcgdGhlIExD IHBlcmlvZC4gIEFzIHRoaXMgaXMgc2ltcGx5IGEgbWVjaGFuaWNhbCB1cGRhdGUNCj4+PnRoYXQg aGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBXRyB3ZSBwbGFuIHRvIHByb2NlZWQgd2l0aCB0aGUN Cj4+PnB1YmxpY2F0aW9uIHByb2Nlc3MuDQo+Pj4NCj4+PkF1dGhvcnMsDQo+Pj4JUGxlYXNlIGxl dC91cyB0aGUgV0cga25vdyB3aGVuIHlvdSBoYXZlIHB1Ymxpc2hlZCBhIHZlcnNpb24gcmVhZHkg Zm9yDQo+Pj5wdWJsaWNhdGlvbi4gIEFsc28gcGxlYXNlIGxldCB0aGUgV0cga25vdyB3aGF0IGhh cyBjaGFuZ2VkIGluIHRoZQ0KPj4+ZG9jdW1lbnQgc2luY2UgdGhlIHN0YXJ0IG9mIExDIChyZXYg LTAxKQ0KPj4+DQo+Pj5UaGFuayB5b3UsDQo+Pj5OZXRNb2QgQ2hhaXJzDQo+Pj4NCj4+Pg0KPj4+ DQo+Pj5PbiAxMS8yOS8yMDE3IDEyOjI2IFBNLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPj4+PiBBbGws DQo+Pj4+IA0KPj4+PiBUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIG9uDQo+Pj4+IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDEuDQo+Pj4+IA0KPj4+ PiBQbGVhc2UgcmVjYWxsIHRoYXQgdGhpcyB1cGRhdGUncyBpbnRlbnRpb24gaXMgdG8NCj4+Pj4g bW9kaWZ5IHRoZSBZQU5HIG1vZHVsZSB0byBiZSBpbiBsaW5lIHdpdGggdGhlIE5NREENCj4+Pj4g Z3VpZGVsaW5lcyBbMV0uICBSZXZpZXdpbmcgdGhlIGRpZmYgYmV0d2VlbiB0aGUgdHdvDQo+Pj4+ IGRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRoaXMuDQo+Pj4+IA0KPj4+PiBUaGUgd29y a2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBEZWNlbWJlciAxMy4NCj4+Pj4gUGxlYXNlIHNl bmQgeW91ciBjb21tZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCj4+Pj4gDQo+Pj4+ IFBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50DQo+ Pj4+IGFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21l IQ0KPj4+PiBUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4N Cj4+Pj4gDQo+Pj4+IFsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1u bWRhLWd1aWRlbGluZXMtMDENCj4+Pj4gWzJdIA0KPj4+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZ1cmwxPXJmYzgwMjIudHh0JnVybDI9DQo+Pj4+ZHIN Cj4+Pj5hZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0wMS50eHQNCj4+Pj4gDQo+Pj4+IFRoYW5r IHlvdSwNCj4+Pj4gTmV0bW9kIENoYWlycw0KPj4+PiANCj4+Pg0KPj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pm5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4+Pm5ldG1vZEBpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPi0tIA0K PkxhZGlzbGF2IExob3RrYQ0KPkhlYWQsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogMHhCOEY5 MkIwOEE5Rjc2QzY3DQoNCg== From nobody Mon Dec 18 06:43:23 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D303B1270AC for ; Mon, 18 Dec 2017 06:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.61 X-Spam-Level: X-Spam-Status: No, score=-12.61 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_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 Uu5ReQ3hTq8M for ; Mon, 18 Dec 2017 06:43:18 -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 BE62B124B17 for ; Mon, 18 Dec 2017 06:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5470; q=dns/txt; s=iport; t=1513608197; x=1514817797; h=from:subject:to:message-id:date:mime-version; bh=ukS97tR4MresKOyVqhZGlvzCJ7vOlpMZ9bpMJKqwwZ0=; b=AeQVYO7YxH+DYtxSTaS4/+8z+RYuGK0+4yfHEUfVzl26sJNruWAMPg4a p0m0oJnZCaaXpug4ezkxmeEV2dIinmaPYlW5YSFh125d7RoBIlsFzqUxB fBm125T4QnreXkklHQpFDQnO0Sy1PlLji74ebWY1LKvO6/pRahJMQ/QqO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAwCt0zda/xbLJq1cGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQkdCAHAYQFixWhZYVQFIIBCiOKYRYBAQEBAQEBAQFrKIVNBHE+Al8?= =?us-ascii?q?NBgIBAYomCQeZcJAVgW06JopCAQEBAQYBAQEBASODboNkghKGJgsBAYE1IoMrg?= =?us-ascii?q?mMFkhuRIYd/g3GJPIJ5iRyHXo0bf1qIBIE7Jg0lgU8yGggbFYJlCYROQDeKFgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.45,422,1508803200"; d="scan'208,217";a="940003" 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; 18 Dec 2017 14:43:15 +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 vBIEhF31005142 for ; Mon, 18 Dec 2017 14:43:15 GMT From: Benoit Claise To: NETMOD Working Group Message-ID: <4f4df77e-c88e-502d-56b0-5007e93a854f@cisco.com> Date: Mon, 18 Dec 2017 15:43:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------28F9884B56C0127D97AED2F2" Content-Language: en-US Archived-At: Subject: [netmod] AD review of draft-ietf-netmod-rfc7223bis-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, 18 Dec 2017 14:43:20 -0000 This is a multi-part message in MIME format. --------------28F9884B56C0127D97AED2F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, In order not to be the bottleneck in the process, here is my AD review of draft-ietf-netmod-rfc7223bis-01 Editorial: - An interface is identified by its name, which is unique within the server. This property is captured in the "interface-ref"_and_ typedef, which other YANG modules SHOULD use when they need to reference an interface. NEW: An interface is identified by its name, which is unique within the server. This property is captured in the "interface-ref" typedef, which other YANG modules SHOULD use when they need to reference an interface. - Note that NETCONF and SNMP may differ in the time granularity in which they provide access to the counters. I guess we want to remove the reference to NETCONF? Proposal: Note the server that implements the YANG module and the SNMP Agent may differ in the time granularity in which they provide access to the counters. - We want to mention that "or:" comes from "ietf-origin@2017-08-17.yang" in draft-ietf-netmod-revised-datastores eth0 ianaift:ethernetCsmacd false down down 2 00:01:02:03:04:05 2013-04-01T03:00:00+00:00 Regards, Benoit (as OPS AD) --------------28F9884B56C0127D97AED2F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

In order not to be the bottleneck in the process, here is my AD review of draft-ietf-netmod-rfc7223bis-01

Editorial:
- 
   An interface is identified by its name, which is unique within the
   server.  This property is captured in the "interface-ref" and
   typedef, which other YANG modules SHOULD use when they need to
   reference an interface.

NEW:
   An interface is identified by its name, which is unique within the
   server.  This property is captured in the "interface-ref"
   typedef, which other YANG modules SHOULD use when they need to
   reference an interface.

- 
   Note that NETCONF and SNMP may
   differ in the time granularity in which they provide access to the
   counters.  

I guess we want to remove the reference to NETCONF?
Proposal:
   Note the server that implements the YANG module and the SNMP Agent may
   differ in the time granularity in which they provide access to the
   counters.  
 
-
We want to mention that "or:" comes from "ietf-origin@2017-08-17.yang" in draft-ietf-netmod-revised-datastores   

<rpc-reply
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       message-id="101">
     <data>
       <interfaces
           xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
           xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
           xmlns:vlan="http://example.com/vlan"
           xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

         <interface or:origin="or:intended">
           <name>eth0</name>
           <type>ianaift:ethernetCsmacd</type>
           <enabled>false</enabled>
           <admin-status>down</admin-status>
           <oper-status>down</oper-status>
           <if-index>2</if-index>
           <phys-address>00:01:02:03:04:05</phys-address>
           <statistics>
             <discontinuity-time>
               2013-04-01T03:00:00+00:00
             </discontinuity-time>
             <!-- counters now shown here -->
           </statistics>
         </interface>

Regards, Benoit (as OPS AD)
--------------28F9884B56C0127D97AED2F2-- From nobody Mon Dec 18 06:48:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2BC124D85 for ; Mon, 18 Dec 2017 06:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.61 X-Spam-Level: X-Spam-Status: No, score=-12.61 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_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 GJqSvdo4KGEm for ; Mon, 18 Dec 2017 06:48:34 -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 DAAE1124B17 for ; Mon, 18 Dec 2017 06:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1211; q=dns/txt; s=iport; t=1513608514; x=1514818114; h=to:from:subject:message-id:date:mime-version; bh=/clV36Bt3nfReQ3AvngSZcsBTwi95kUaOQ28FQHLfgg=; b=h3N6yQ6HK/GpjFqrspO1Rn0oDH1ga46yQLSQYBv69ft3ee+e5v8ZhxXu aycaUkRSLgQFUDlKA70iyDj+x5VDbSAWB9GXwTrywBEgKDBoCdFJ5JH5M sevqHf4aNGFCJIacrfgP9+gxWD5p3Q1JgqA3INC7Mj+ht2nCJvv61MzKm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAQCo1Dda/xbLJq1cGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQkdIQtixWhZYVkggEKI4pjFAEBAQEBAQEBAWsohRozdAE+Al8NCAE?= =?us-ascii?q?BiiYQqgWCJyaKQgEBAQEGAQEBAQEeBYNug2SCEoYxAQGBNYNNgmMFozyHf4Nxi?= =?us-ascii?q?TyMFYdejRuBWYgEgTs2IoFPMhoIGxWCZoRWQIpNAQEB?= X-IronPort-AV: E=Sophos;i="5.45,422,1508803200"; d="scan'208,217";a="993663" 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; 18 Dec 2017 14:48:32 +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 vBIEmVZV032158 for ; Mon, 18 Dec 2017 14:48:32 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <7966764e-0dfb-c8ca-3a70-490144ed52a0@cisco.com> Date: Mon, 18 Dec 2017 15:48:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B647C3914A14F14943DD565C" Content-Language: en-US Archived-At: Subject: [netmod] AD review of draft-ietf-netmod-rfc7277bis-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, 18 Dec 2017 14:48:35 -0000 This is a multi-part message in MIME format. --------------B647C3914A14F14943DD565C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, In order not to be the bottleneck in the process, here is my AD review of draft-ietf-netmod-rfc7277bis-01 All looks good. Thank you. Martin already noticed the Security Considerations template Regards, Benoit (as OPS AD) --------------B647C3914A14F14943DD565C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

In order not to be the bottleneck in the process, here is my AD review of draft-ietf-netmod-rfc7277bis-01
All looks good. Thank you.

Martin already noticed the Security Considerations template

Regards, Benoit (as OPS AD)
--------------B647C3914A14F14943DD565C-- From nobody Mon Dec 18 06:57:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44D0124D85 for ; Mon, 18 Dec 2017 06:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[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 epueYocyH4pK for ; Mon, 18 Dec 2017 06:57: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 42B65124B17 for ; Mon, 18 Dec 2017 06:57:00 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CCFEB1AE0311; Mon, 18 Dec 2017 15:56:58 +0100 (CET) Date: Mon, 18 Dec 2017 15:55:39 +0100 (CET) Message-Id: <20171218.155539.2007718529213229529.mbj@tail-f.com> To: bclaise@cisco.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <4f4df77e-c88e-502d-56b0-5007e93a854f@cisco.com> References: <4f4df77e-c88e-502d-56b0-5007e93a854f@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] AD review of draft-ietf-netmod-rfc7223bis-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, 18 Dec 2017 14:57:02 -0000 Benoit Claise wrote: > Dear all, > > In order not to be the bottleneck in the process, here is my AD review > of draft-ietf-netmod-rfc7223bis-01 > > > Editorial: > > - > An interface is identified by its name, which is unique within the > server. This property is captured in the "interface-ref"_and_ > typedef, which other YANG modules SHOULD use when they need to > reference an interface. > > NEW: > An interface is identified by its name, which is unique within the > server. This property is captured in the "interface-ref" > typedef, which other YANG modules SHOULD use when they need to > reference an interface. Ok, now fixed. > > - > Note that NETCONF and SNMP may > differ in the time granularity in which they provide access to the > counters. > > I guess we want to remove the reference to NETCONF? > Proposal: > Note the server that implements the YANG module and the SNMP Agent may > differ in the time granularity in which they provide access to the > counters. Ok, fixed. > - > We want to mention that "or:" comes from "ietf-origin@2017-08-17.yang" > in draft-ietf-netmod-revised-datastores I added: This example uses the "origin" annotation, which is defined in the module "ietf-origin" [I-D.ietf-netmod-revised-datastores]. (I added this text to rfc7277bis as well). /martin > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > message-id="101"> > > xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" > xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" > xmlns:vlan="http://example.com/vlan" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> > > > eth0 > ianaift:ethernetCsmacd > false > down > down > 2 > 00:01:02:03:04:05 > > > 2013-04-01T03:00:00+00:00 > > > > > > Regards, Benoit (as OPS AD) > From nobody Mon Dec 18 07:21:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF152127369 for ; Mon, 18 Dec 2017 07:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[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 Kxpp50R8K0W3 for ; Mon, 18 Dec 2017 07:20:58 -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 4A12C1241F3 for ; Mon, 18 Dec 2017 07:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2699; q=dns/txt; s=iport; t=1513610458; x=1514820058; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=jBN1moYkPf1Z44VESJl9aUX00ekl6CbXMONnTg0zhL0=; b=iz3FVLIbA2AR7RuhTnr+hn4Hdn1/0ZYhf9fTO/N9C8rXzt7Z8r8N4c+0 27qVNAHQjndevvvFkMOvcWNtA5bc//WKdzriudsOL08weSWR5suxoNXNZ 6fsvPoSuUQ4Bh9291tOZ/1698aUgDO8ni9ze0zYwCyU2DhGm7oxDbtNuw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AwDN2zda/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCAHhAaLFY9vJpc1ggEKI4UYAoVJFQEBAQEBAQEBAWsohSQ?= =?us-ascii?q?BBSMEEUEQCw4KAgImAgJXBg0GAgEBiiYJB6l+gW06imgBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBH4EPgl+DZIISDIJ3gyMLAQGBNSKDK4JjBZIbkSGHf4NxiTyCeYkch16?= =?us-ascii?q?NG39aiASBOzUjgU8yGggbFYJlCYROQDeKFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,422,1508803200"; d="scan'208";a="941222" 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 Dec 2017 15:20:56 +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 vBIFKuwa019589; Mon, 18 Dec 2017 15:20:56 GMT To: Martin Bjorklund Cc: netmod@ietf.org References: <4f4df77e-c88e-502d-56b0-5007e93a854f@cisco.com> <20171218.155539.2007718529213229529.mbj@tail-f.com> From: Benoit Claise Message-ID: <42a03f3a-9211-7cc1-e7f6-eaf57ce08645@cisco.com> Date: Mon, 18 Dec 2017 16:20:56 +0100 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: <20171218.155539.2007718529213229529.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] AD review of draft-ietf-netmod-rfc7223bis-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, 18 Dec 2017 15:21:03 -0000 Perfect. Thank you. Regards, B. > Benoit Claise wrote: >> Dear all, >> >> In order not to be the bottleneck in the process, here is my AD review >> of draft-ietf-netmod-rfc7223bis-01 >> >> >> Editorial: >> >> - >> An interface is identified by its name, which is unique within the >> server. This property is captured in the "interface-ref"_and_ >> typedef, which other YANG modules SHOULD use when they need to >> reference an interface. >> >> NEW: >> An interface is identified by its name, which is unique within the >> server. This property is captured in the "interface-ref" >> typedef, which other YANG modules SHOULD use when they need to >> reference an interface. > Ok, now fixed. > > >> - >> Note that NETCONF and SNMP may >> differ in the time granularity in which they provide access to the >> counters. >> >> I guess we want to remove the reference to NETCONF? >> Proposal: >> Note the server that implements the YANG module and the SNMP Agent may >> differ in the time granularity in which they provide access to the >> counters. > Ok, fixed. > >> - >> We want to mention that "or:" comes from "ietf-origin@2017-08-17.yang" >> in draft-ietf-netmod-revised-datastores > I added: > > This example uses the "origin" annotation, which is defined in the > module "ietf-origin" [I-D.ietf-netmod-revised-datastores]. > > > (I added this text to rfc7277bis as well). > > > > /martin > > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" >> message-id="101"> >> >> > xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" >> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" >> xmlns:vlan="http://example.com/vlan" >> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> >> >> >> eth0 >> ianaift:ethernetCsmacd >> false >> down >> down >> 2 >> 00:01:02:03:04:05 >> >> >> 2013-04-01T03:00:00+00:00 >> >> >> >> >> >> Regards, Benoit (as OPS AD) >> > . > From nobody Mon Dec 18 12:01:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C993412D876 for ; Mon, 18 Dec 2017 12:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 C-7ie3L_1SIt for ; Mon, 18 Dec 2017 12:01:01 -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 BC83012D871 for ; Mon, 18 Dec 2017 12:00:53 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id DE30D1AB12C for ; Mon, 18 Dec 2017 13:00:31 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id nY0U1w0012SSUrH01Y0XFW; Mon, 18 Dec 2017 13:00:31 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=nMzjVutcYClMdDj_LigA: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:Cc: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=rNWwFY+jy4E4Y+snIkQSmYEJPtBIbKBys5kGzhvibCs=; b=guw2TkwdJn6lrHlaApp5BK04i2 Avsjg4NN/JqzSdDtFEe6cUFAbY1fRZoUgiv78Ipb3GUEJ1wdifoXYxjIoGlqJJRXdTNMR7nEGKftb cw1XF5CqZVWxkHaQLK3IJRbRg; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:48504 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eR1aN-003was-Rk; Mon, 18 Dec 2017 13:00:27 -0700 To: Martin Bjorklund , draft-ietf-netmod-entity@ietf.org References: <151358984141.28794.3169667694911973561@ietfa.amsl.com> <20171218.103903.1338730940312800102.mbj@tail-f.com> Cc: netmod@ietf.org From: Lou Berger Message-ID: Date: Mon, 18 Dec 2017 15:00:26 -0500 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: <20171218.103903.1338730940312800102.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 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: 1eR1aN-003was-Rk 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]:48504 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 20:01:04 -0000 Martin, Authors, is there a reason that the draft says:         Registrant Contact: The IESG. vs the typical:        Registrant Contact: The NETMOD WG of the IETF. Thanks, Lou On 12/18/2017 4:39 AM, Martin Bjorklund wrote: > Hi, > > This version addresses the WGLC comments received. Specifically, I > have added ietf-hardware-state, a config false version of > ietf-hardware for non-NMDA implementations, in an Appendix. Please > review the new text and the description statement in that module. > > I have also added a reference to the tree diagram draft and use the > latest security guidelines template text. > > > /martin > > 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 Hardware Management >> Authors : Andy Bierman >> Martin Bjorklund >> Jie Dong >> Dan Romascanu >> Filename : draft-ietf-netmod-entity-06.txt >> Pages : 54 >> Date : 2017-12-18 >> >> 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-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 > From nobody Mon Dec 18 12:06:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD24E12422F; Mon, 18 Dec 2017 12:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[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 Za3QZ0CAFcfc; Mon, 18 Dec 2017 12:06: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 1F1D91205D3; Mon, 18 Dec 2017 12:06:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E595B673; Mon, 18 Dec 2017 21:06: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 ZsMRF3ElPAMj; Mon, 18 Dec 2017 21:06:50 +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, 18 Dec 2017 21:06:52 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D119020130; Mon, 18 Dec 2017 21:06:52 +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 g7Z9zIXm156F; Mon, 18 Dec 2017 21:06:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A67F20073; Mon, 18 Dec 2017 21:06:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5CD4941F1635; Mon, 18 Dec 2017 21:06:50 +0100 (CET) Date: Mon, 18 Dec 2017 21:06:50 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, netmod@ietf.org Message-ID: <20171218200650.6bus7deydr3bxm2j@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <151358984141.28794.3169667694911973561@ietfa.amsl.com> <20171218.103903.1338730940312800102.mbj@tail-f.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: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 20:06:56 -0000 See RFC 3688 section 4. /js On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: > Martin, Authors, > > is there a reason that the draft says: > > Registrant Contact: The IESG. > > vs the typical: > > Registrant Contact: The NETMOD WG of the IETF. > > Thanks, > > Lou > > On 12/18/2017 4:39 AM, Martin Bjorklund wrote: > > Hi, > > > > This version addresses the WGLC comments received. Specifically, I > > have added ietf-hardware-state, a config false version of > > ietf-hardware for non-NMDA implementations, in an Appendix. Please > > review the new text and the description statement in that module. > > > > I have also added a reference to the tree diagram draft and use the > > latest security guidelines template text. > > > > > > /martin > > > > 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 Hardware Management > >> Authors : Andy Bierman > >> Martin Bjorklund > >> Jie Dong > >> Dan Romascanu > >> Filename : draft-ietf-netmod-entity-06.txt > >> Pages : 54 > >> Date : 2017-12-18 > >> > >> 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-06 > >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 -- 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 Dec 18 12:11:51 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF69012D853 for ; Mon, 18 Dec 2017 12:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.61 X-Spam-Level: X-Spam-Status: No, score=-12.61 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_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 c0mOne2Ykkox for ; Mon, 18 Dec 2017 12:11:37 -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 37AD71205D3 for ; Mon, 18 Dec 2017 12:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=117341; q=dns/txt; s=iport; t=1513627896; x=1514837496; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=VUtUIMf6YuVq6vkdkgX2Dkp0PQE31xH6qexMgJbSvUE=; b=hi88T2l/9dWKZdaHahQDc86tHXVvJsoB8ATyhscK4bOp6p1d7mzRkjDg o2GwkmuajNu0ckuCvrzOGaLbBXItLJ51oHRgVwVtCGbomVjVDWUpwj3YS 0fNHtsYTtmmK1b1y4s2bezvLJpl7AquVPl0O0MwLk60T3QIyG91yz5mF9 0=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.45,423,1508803200"; d="asc'?scan'208,217";a="946803" 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; 18 Dec 2017 20:11:34 +0000 Received: from [10.61.162.193] ([10.61.162.193]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBIKBXN8003804; Mon, 18 Dec 2017 20:11:34 GMT To: "Einar Nilsen-Nygaard (einarnn)" Cc: "netmod@ietf.org" , Kristian Larsson 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> From: Eliot Lear Message-ID: Date: Mon, 18 Dec 2017 21:11:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6esDfWvicnHRqXLpXq1O8ORjJaQJoJ0On" 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: Mon, 18 Dec 2017 20:11:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6esDfWvicnHRqXLpXq1O8ORjJaQJoJ0On Content-Type: multipart/mixed; boundary="4lvLdgh8haXWN8eVS2I4xcgpIwsIAiTIt"; protected-headers="v1" From: Eliot Lear To: "Einar Nilsen-Nygaard (einarnn)" Cc: "netmod@ietf.org" , Kristian Larsson 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> In-Reply-To: <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> --4lvLdgh8haXWN8eVS2I4xcgpIwsIAiTIt Content-Type: multipart/alternative; boundary="------------FD5CDCED02D54F156AA0E24F" Content-Language: en-US This is a multi-part message in MIME format. --------------FD5CDCED02D54F156AA0E24F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UHJlc3VtaW5nIHRoaXMgaXNzdWUgaXMgYmVoaW5kIHVzLCBhcmUgYWxsIFdHTEMgY29tbWVu dHMgYWRkcmVzc2VkP8KgIENhbgp3ZSBleHBlY3QgdG8gc2VlIGEgbmV3IGRyYWZ0IHNvb24/ CgpFbGlvdAoKCk9uIDE4LjEyLjE3IDEzOjMxLCBFbGlvdCBMZWFyIHdyb3RlOgo+Cj4gU28g bG9uZyBhcyBub2JvZHkgZXhwZWN0cyBhbiBpbnRlcmZhY2UgY29uc3RydWN0IGluIGEgTVVE IGZpbGUsIEknbSBoYXBweS4KPgo+Cj4gT24gMTcuMTIuMTcgMTU6MzQsIEVpbmFyIE5pbHNl bi1OeWdhYXJkIChlaW5hcm5uKSB3cm90ZToKPj4gRWxpb3QsCj4+Cj4+IE5vdGhpbmcgY2Fu IGZvcmNlIGFuIGltcGxlbWVudGF0aW9uIHRvIGhhdmUgdG8gaW1wbGVtZW50IGVpdGhlcgo+ PiB0aGXCoGlldGYtaW50ZXJmYWNlcyBtb2RlbCBvciB0aGUgYXVnbWVudGF0aW9uIGluIHRo ZQo+PiBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QgbW9kZWwuIEkgYXBwcmVjaWF0ZSB5b3Vy IGRlc2lyZSBmb3IKPj4gbW9kdWxhcml0eSBhbmQgY29oZXNpdmVuZXNzLCBidXQgSSB3b3Vs ZCByZXNpc3QgIzEsIGJlY2F1c2UgSSBmZWVsCj4+IHRoYXQgdGhlIG1ham9yaXR5IG9mIHVz ZXJzIHdpbGwgYmUgdGFyZ2V0aW5nIGludGVyZmFjZS1iYXNlZAo+PiBhdHRhY2htZW50IG92 ZXIgdGltZS4gSeKAmXZlIGFkZGUgYmFjayBpbiB1c2Ugb2YgdGhlCj4+IOKAnGludGVyZmFj ZS1hdHRhY2htZW504oCdIGZlYXR1cmUgKHdoaWNoIEkgdG9vayBvdXQgYXMgcGFydCBvZgo+ PiByZWZhY3RvcmluZyBpbnRlcmZhY2UgYXR0YWNobWVudCkuIFBhcnQgb2Y6Cj4+Cj4+ICAg ICBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL2FjbC1tb2RlbC9wdWxsLzIxCj4+Cj4+ Cj4+IFRoZSBhdWdtZW50cyBwYXJ0IG9mIHRoZSB0cmVlIG5vdyBsb29rcyBsaWtlOgo+Pgo+ PiDCoCBhdWdtZW50IC9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZToKPj4gwqAgwqAgKy0t cncgYWNscyAqe2ludGVyZmFjZS1hdHRhY2htZW50fSo/Cj4+IMKgIMKgIMKgIMKgKy0tcncg aW5ncmVzcwo+PiDCoCDCoCDCoCDCoHwgwqArLS1ydyBhY2wtc2V0cwo+PiDCoCDCoCDCoCDC oHwgwqAgwqAgKy0tcncgYWNsLXNldCogW25hbWVdCj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDC oCDCoCstLXJ3IG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAtPiAvYWNjZXNzLWxpc3RzL2Fj bC9uYW1lCj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKg IMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5cGUKPj4gwqAgwqAgwqAgwqB8IMKg IMKgIMKgIMKgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1lXSB7aW50ZXJmYWNlLXN0YXRz fT8KPj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAgwqAgwqAg wqAgwqAgwqAgwqAgLT4KPj4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+PiDC oCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbWF0Y2hlZC1wYWNrZXRzPyDCoCB5 YW5nOmNvdW50ZXI2NAo+PiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbWF0 Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPj4gwqAgwqAgwqAgwqArLS1ydyBl Z3Jlc3MKPj4gwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldHMKPj4gwqAgwqAgwqAgwqAg wqAgwqAgwqArLS1ydyBhY2wtc2V0KiBbbmFtZV0KPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKy0tcncgbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoC0+IC9hY2Nlc3MtbGlzdHMvYWNs L25hbWUKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgdHlwZT8gwqAgwqAgwqAg wqAgwqAgwqAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQo+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCArLS1ybyBhY2Utc3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9 Pwo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG5hbWUgwqAgwqAgwqAg wqAgwqAgwqAgwqAgLT4KPj4gL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG1hdGNoZWQtcGFja2V0cz8gwqAg eWFuZzpjb3VudGVyNjQKPj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBt YXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNvdW50ZXI2NAo+Pgo+PiBDaGVlcnMsCj4+Cj4+ IEVpbmFyCj4+Cj4+Cj4+PiBPbiAxNyBEZWMgMjAxNywgYXQgMTE6MjksIEVsaW90IExlYXIg PGxlYXJAY2lzY28uY29tCj4+PiA8bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6Cj4+ Pgo+Pj4gRWluYXIsCj4+Pgo+Pj4gSSB0aGluayB0aGlzIGNoYW5nZSBpcyBmaW5lLCB3aXRo IG9uZSBleGNlcHRpb24uwqAgSSB3b3VsZCByYXRoZXIgdGhlCj4+PiBhdWdtZW50IHRvIHRo ZSBpbnRlcmZhY2Ugbm90IGJlIHJlcXVpcmVkIGZvciBpbXBsZW1lbnRhdGlvbnMgdGhhdAo+ Pj4gZG9uJ3QgYWN0dWFsbHkgaGF2ZSBpbnRlcmZhY2VzLsKgIEkgdW5kZXJzdGFuZCB0aGF0 IHRoZXJlIG1heSBiZSB0d28KPj4+IHdheXMgdG8gZ28gYWJvdXQgdGhpczoKPj4+Cj4+PiAg MS4gU2VwYXJhdGUgb3V0IHRoZSBhdWdtZW50IGludG8gYSBzZXBhcmF0ZSBtb2R1bGUgKHNh bWUgZG9jIGlzCj4+PiAgICAgZmluZSk7IG9yCj4+PiAgMi4gU29tZWhvdyAiZmVhdHVyZS1p emUiIHRoZSBhdWdtZW50Lgo+Pj4KPj4+IEkgZG9uJ3Qga25vdyBob3cgdG8gZG8gKDIpIGJ1 dCBpZiB5b3UgZG8sIHRoYXQncyBva2F5IGJ5IG1lLgo+Pj4KPj4+IEVsaW90Cj4+Pgo+Pj4K Pj4+IE9uIDE2LjEyLjE3IDE0OjE5LCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikg d3JvdGU6Cj4+Pj4gQWxsLAo+Pj4+Cj4+Pj4gQWZ0ZXIgYSBzZXJpZXMgb2YgZGlzY3Vzc2lv bnMgb24tIGFuZCBvZmYtbGlzdCwgSSBoYXZlIGEgY2FuZGlkYXRlCj4+Pj4gUFIgdGhhdCBp bmNsdWRlcyB0aGUgY2hhbmdlcyBpbiB0aGUgUFIgTWFoZXNoIHNlbnQgb3V0IHBsdXMgc29t ZQo+Pj4+IG1vcmUgZWRpdHMuIFBsZWFzZSBzZWUgY29uc29saWRhdGVkIFBSIGhlcmU6Cj4+ Pj4KPj4+PiAgICAgaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVs bC8yMQo+Pj4+Cj4+Pj4KPj4+PiBNYWluIGNoYW5nZXMgaW4gYWRkaXRpb24gdG8gTWFoZXNo 4oCZcyBQUiBhcmU6Cj4+Pj4KPj4+PiAgICogTW92ZWQgaW50ZXJmYWNlIGF0dGFjaG1lbnQg dG8gYmUgdmlhIGFuIGludGVyZmFjZSBhdWdtZW50YXRpb24uCj4+Pj4gICAqIFJlc3RydWN0 dXJlZCBwb3J0IG1hdGNoZXMgc2xpZ2h0bHkgdW5kZXIgYm90aCBJUHY0IGFuZCBJUHY2Cj4+ Pj4gICAgIGNvbnRhaW5lcnMuCj4+Pj4gICAqIFJlbW92ZWQgdW5uZWNlc3NhcnkgaWRlbnRp dHkgJ2ludGVyZmFjZS1hY2wtYWdncmVnYXRl4oCZLgo+Pj4+ICAgKiBSZW1vdmVkIGFjdGlv biDigJhpY21wLW9mZuKAmSwgY2FuIGJlIGF1Z21lbnRlZCBsYXRlci4KPj4+Pgo+Pj4+Cj4+ Pj4gRm9yIHJlZmVyZW5jZSwgaGVyZSBpcyB0aGUgY3VycmVudCBZQU5HIHRyZWUgcGx1cyDi gJwtLWlldGbigJ0gbG9nczoKPj4+Pgo+Pj4+IDEzOjEyICQgcHlhbmcgLS1pZXRmIC0tbGlu dCAtZiB0cmVlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdC55YW5nCj4+Pj4gaWV0Zi1hY2Nl c3MtY29udHJvbC1saXN0Lnlhbmc6NTE6IGVycm9yOiBiYWQgdmFsdWUgIllZWVktTU0tREQi Cj4+Pj4gKHNob3VsZCBiZSBkYXRlKQo+Pj4+IG1vZHVsZTogaWV0Zi1hY2Nlc3MtY29udHJv bC1saXN0Cj4+Pj4gwqAgwqAgKy0tcncgYWNjZXNzLWxpc3RzCj4+Pj4gwqAgwqAgwqAgwqAr LS1ydyBhY2wqIFtuYW1lXQo+Pj4+IMKgIMKgIMKgIMKgIMKgICstLXJ3IG5hbWUgwqAgwqBz dHJpbmcKPj4+PiDCoCDCoCDCoCDCoCDCoCArLS1ydyB0eXBlPyDCoCBhY2wtdHlwZQo+Pj4+ IMKgIMKgIMKgIMKgIMKgICstLXJ3IGFjZXMKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCst LXJ3IGFjZSogW25hbWVdCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgbmFt ZSDCoCDCoCDCoCDCoCDCoHN0cmluZwo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICst LXJ3IG1hdGNoZXMKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgKy0tcncgKGwy KT8KPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLTooZXRoKQo+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgICstLXJ3IGV0aCB7bWF0Y2gt b24tZXRofT8KPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDC oCstLXJ3IGRlc3RpbmF0aW9uLW1hYy1hZGRyZXNzPyDCoCDCoCDCoAo+Pj4+IMKgeWFuZzpt YWMtYWRkcmVzcwo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKg IMKgKy0tcncgZGVzdGluYXRpb24tbWFjLWFkZHJlc3MtbWFzaz8gwqAKPj4+PiB5YW5nOm1h Yy1hZGRyZXNzCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAg wqArLS1ydyBzb3VyY2UtbWFjLWFkZHJlc3M/IMKgIMKgIMKgIMKgIMKgIMKgCj4+Pj4geWFu ZzptYWMtYWRkcmVzcwo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKg IMKgIMKgKy0tcncgc291cmNlLW1hYy1hZGRyZXNzLW1hc2s/IMKgIMKgIMKgCj4+Pj4gwqB5 YW5nOm1hYy1hZGRyZXNzCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAg wqAgwqAgwqArLS1ydyBldGhlcnR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Cj4+Pj4gwqBldGg6ZXRoZXJ0eXBlCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oCstLXJ3IChsMyk/Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqArLS06 KGlwdjQpCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgKy0tcncg aXB2NCB7bWF0Y2gtb24taXB2NH0/Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oHwgwqB8IMKgIMKgICstLXJ3IGRzY3A/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGluZXQ6ZHNjcAo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDC oCDCoCArLS1ydyBlY24/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdWlu dDgKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncg bGVuZ3RoPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1aW50MTYKPj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgdHRsPyDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVpbnQ4Cj4+Pj4gwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IHByb3RvY29sPyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB1aW50OAo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8 IMKgfCDCoCDCoCArLS1ydyAoc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPwo+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgKy0tOihyYW5n ZSkKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoHwg wqArLS1ydyBzb3VyY2UtcG9ydC1sb3dlciDCoCDCoCDCoCDCoCDCoAo+Pj4+IGluZXQ6cG9y dC1udW1iZXIKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAg fCDCoHwgwqArLS1ydyBzb3VyY2UtcG9ydC11cHBlciDCoCDCoCDCoCDCoCDCoAo+Pj4+IGlu ZXQ6cG9ydC1udW1iZXIKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwg wqAgwqAgfCDCoCstLToob3BlcmF0b3IpCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgIHwgwqAgwqAgKy0tcncgc291cmNlLW9wZXJhdG9yIMKgIMKgIMKg IMKgIMKgIMKgCj4+Pj4gb3BlcmF0b3IKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 IMKgfCDCoHwgwqAgwqAgfCDCoCDCoCArLS1ydyBzb3VyY2UtcG9ydCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoAo+Pj4+IGluZXQ6cG9ydC1udW1iZXIKPj4+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgKGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Ut b3Itb3BlcmF0b3IpPwo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDC oCDCoCB8IMKgKy0tOihyYW5nZSkKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoHwgwqAgwqAgfCDCoHwgwqArLS1ydyBkZXN0aW5hdGlvbi1wb3J0LWxvd2VyIMKgIMKg Cj4+Pj4gwqBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgIHwgwqB8IMKgKy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciDC oCDCoAo+Pj4+IMKgaW5ldDpwb3J0LW51bWJlcgo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHwgwqB8IMKgfCDCoCDCoCB8IMKgKy0tOihvcGVyYXRvcikKPj4+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoCDCoCArLS1ydyBkZXN0aW5hdGlv bi1vcGVyYXRvciDCoCDCoCDCoAo+Pj4+IMKgb3BlcmF0b3IKPj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgfCDCoCDCoCArLS1ydyBkZXN0aW5hdGlvbi1w b3J0IMKgIMKgIMKgIMKgIMKgCj4+Pj4gwqBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3IGlobD8gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50OAo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqB8IMKgfCDCoCDCoCArLS1ydyBmbGFncz8gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBiaXRzCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwg wqB8IMKgIMKgICstLXJ3IG9mZnNldD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg dWludDE2Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICst LXJ3IGlkZW50aWZpY2F0aW9uPyDCoCDCoCDCoCDCoCDCoCDCoCB1aW50MTYKPj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24t aXB2NC1uZXR3b3JrPyDCoAo+Pj4+IGluZXQ6aXB2NC1wcmVmaXgKPj4+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgc291cmNlLWlwdjQtbmV0d29y az8gwqAgwqAgwqAKPj4+PiDCoGluZXQ6aXB2NC1wcmVmaXgKPj4+PiDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgfCDCoCstLTooaXB2NikKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgfCDCoCDCoCArLS1ydyBpcHY2IHttYXRjaC1vbi1pcHY2fT8KPj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGRzY3A/IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluZXQ6ZHNjcAo+Pj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgZWNuPyDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVpbnQ4Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBsZW5ndGg/IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHVpbnQxNgo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKg IMKgIMKgIMKgKy0tcncgdHRsPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHVpbnQ4Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqAr LS1ydyBwcm90b2NvbD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWludDgKPj4+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoCstLXJ3IChzb3VyY2Ut cG9ydC1yYW5nZS1vci1vcGVyYXRvcik/Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqAgwqAgwqAgwqB8IMKgKy0tOihyYW5nZSkKPj4+PiDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDCoHwgwqB8IMKgKy0tcncgc291cmNlLXBvcnQtbG93 ZXIgwqAgwqAgwqAgwqAgwqAKPj4+PiBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKgfCDCoCstLXJ3IHNvdXJjZS1w b3J0LXVwcGVyIMKgIMKgIMKgIMKgIMKgCj4+Pj4gaW5ldDpwb3J0LW51bWJlcgo+Pj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoCstLToob3BlcmF0 b3IpCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKg IMKgICstLXJ3IHNvdXJjZS1vcGVyYXRvciDCoCDCoCDCoCDCoCDCoCDCoAo+Pj4+IG9wZXJh dG9yCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKg IMKgICstLXJ3IHNvdXJjZS1wb3J0IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgCj4+Pj4gaW5l dDpwb3J0LW51bWJlcgo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKg IMKgIMKgKy0tcncgKGRlc3RpbmF0aW9uLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPwo+Pj4+ IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKgIMKgIMKgfCDCoCstLToocmFu Z2UpCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqB8IMKg fCDCoCstLXJ3IGRlc3RpbmF0aW9uLXBvcnQtbG93ZXIgwqAgwqAKPj4+PiDCoGluZXQ6cG9y dC1udW1iZXIKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCDCoCDC oHwgwqB8IMKgKy0tcncgZGVzdGluYXRpb24tcG9ydC11cHBlciDCoCDCoAo+Pj4+IMKgaW5l dDpwb3J0LW51bWJlcgo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgIMKg IMKgIMKgfCDCoCstLToob3BlcmF0b3IpCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqAgwqAgwqAgwqB8IMKgIMKgICstLXJ3IGRlc3RpbmF0aW9uLW9wZXJhdG9yIMKg IMKgIMKgCj4+Pj4gwqBvcGVyYXRvcgo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqB8IMKgIMKgIMKgIMKgfCDCoCDCoCArLS1ydyBkZXN0aW5hdGlvbi1wb3J0IMKgIMKgIMKg IMKgIMKgCj4+Pj4gwqBpbmV0OnBvcnQtbnVtYmVyCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBkZXN0aW5hdGlvbi1pcHY2LW5ldHdvcms/ IMKgCj4+Pj4gaW5ldDppcHY2LXByZWZpeAo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHwgwqB8IMKgIMKgIMKgIMKgKy0tcncgc291cmNlLWlwdjYtbmV0d29yaz8gwqAgwqAgwqAK Pj4+PiDCoGluZXQ6aXB2Ni1wcmVmaXgKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 IMKgfCDCoCDCoCDCoCDCoCstLXJ3IGZsb3ctbGFiZWw/IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgCj4+Pj4gaW5ldDppcHY2LWZsb3ctbGFiZWwKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgKy0tcncgKGw0KT8KPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoCstLToodGNwKQo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDC oCstLXJ3IHRjcCB7bWF0Y2gtb24tdGNwfT8KPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgc2VxdWVuY2UtbnVtYmVyPyDCoCDCoCDCoCDCoCDC oHVpbnQzMgo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCDCoCAr LS1ydyBhY2tub3dsZWRnZW1lbnQtbnVtYmVyPyDCoCB1aW50MzIKPj4+PiDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgZGF0YS1vZmZzZXQ/IMKgIMKg IMKgIMKgIMKgIMKgIMKgdWludDgKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoHwgwqAgwqAgKy0tcncgcmVzZXJ2ZWQ/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVp bnQ4Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqB8IMKgIMKgICstLXJ3 IGZsYWdzPyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGJpdHMKPj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgd2luZG93LXNpemU/IMKg IMKgIMKgIMKgIMKgIMKgIMKgdWludDE2Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fCDCoHwgwqB8IMKgIMKgICstLXJ3IHVyZ2VudC1wb2ludGVyPyDCoCDCoCDCoCDCoCDCoCB1 aW50MTYKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0t cncgb3B0aW9ucz8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1aW50MzIKPj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLToodWRwKQo+Pj4+IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqB8IMKgfCDCoCstLXJ3IHVkcCB7bWF0Y2gtb24tdWRwfT8KPj4+ PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoHwgwqAgwqAgKy0tcncgbGVuZ3Ro PyDCoCB1aW50MTYKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCstLToo aWNtcCkKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgfCDCoCDCoCArLS1ydyBp Y21wIHttYXRjaC1vbi1pY21wfT8KPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg fCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4Cj4+Pj4g wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoHwgwqAgwqAgwqAgwqArLS1ydyBjb2RlPyDC oCDCoCDCoCDCoCDCoCDCoCB1aW50OAo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqB8IMKgIMKgIMKgIMKgKy0tcncgcmVzdC1vZi1oZWFkZXI/IMKgIHVpbnQzMgo+Pj4+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyBlZ3Jlc3MtaW50ZXJmYWNlPyDCoCDC oGlmOmludGVyZmFjZS1yZWYKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgKy0t cncgaW5ncmVzcy1pbnRlcmZhY2U/IMKgIGlmOmludGVyZmFjZS1yZWYKPj4+PiDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCArLS1ydyBhY3Rpb25zCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoCstLXJ3IGZvcndhcmRpbmcgwqAgwqBpZGVudGl0eXJlZgo+Pj4+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqArLS1ydyBsb2dnaW5nPyDCoCDCoCDCoGlkZW50aXR5 cmVmCj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gc3RhdGlzdGljcyB7YWNs LWFnZ3JlZ2F0ZS1zdGF0c30/Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAr LS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlhbmc6Y291bnRlcjY0Cj4+Pj4gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBtYXRjaGVkLW9jdGV0cz8gwqAgwqB5YW5nOmNv dW50ZXI2NAo+Pj4+Cj4+Pj4gwqAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRlcmZh Y2U6Cj4+Pj4gwqAgwqAgKy0tcncgYWNscwo+Pj4+IMKgIMKgIMKgIMKgKy0tcncgaW5ncmVz cwo+Pj4+IMKgIMKgIMKgIMKgfCDCoCstLXJ3IGFjbC1zZXRzCj4+Pj4gwqAgwqAgwqAgwqB8 IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4+IMKgIMKgIMKgIMKgfCDCoCDCoCDC oCDCoCstLXJ3IG5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAtPiAvYWNjZXNzLWxpc3RzL2Fj bC9uYW1lCj4+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgKy0tcncgdHlwZT8gwqAgwqAg wqAgwqAgwqAgwqAgLT4gL2FjY2Vzcy1saXN0cy9hY2wvdHlwZQo+Pj4+IMKgIMKgIMKgIMKg fCDCoCDCoCDCoCDCoCstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1z dGF0c30/Cj4+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAg wqAgwqAgwqAgwqAgwqAgwqAgLT4KPj4+PiAvYWNjZXNzLWxpc3RzL2FjbC9hY2VzL2FjZS9u YW1lCj4+Pj4gwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtcGFj a2V0cz8gwqAgeWFuZzpjb3VudGVyNjQKPj4+PiDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAg wqAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQKPj4+PiDCoCDC oCDCoCDCoCstLXJ3IGVncmVzcwo+Pj4+IMKgIMKgIMKgIMKgIMKgICstLXJ3IGFjbC1zZXRz Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ydyBhY2wtc2V0KiBbbmFtZV0KPj4+PiDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyBuYW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKg LT4gL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKgIMKgIC0+IC9hY2Nlc3MtbGlzdHMvYWNsL3R5 cGUKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBhY2Utc3RhdGlzdGljcyog W25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pwo+Pj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+Pj4+IC9hY2Nlc3Mt bGlzdHMvYWNsL2FjZXMvYWNlL25hbWUKPj4+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCstLXJvIG1hdGNoZWQtcGFja2V0cz8gwqAgeWFuZzpjb3VudGVyNjQKPj4+PiDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJvIG1hdGNoZWQtb2N0ZXRzPyDCoCDCoHlh bmc6Y291bnRlcjY0Cj4+Pj4KPj4+PiBDb21tZW50cyB3ZWxjb21lIQo+Pj4+Cj4+Pj4gQ2hl ZXJzLAo+Pj4+Cj4+Pj4gRWluYXIKPj4+Pgo+Pj4+Cj4+Pj4KPj4+Pj4gT24gMTQgRGVjIDIw MTcsIGF0IDE4OjUwLCBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikKPj4+Pj4gPGVp bmFybm5AY2lzY28uY29tIDxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+PiB3cm90ZToKPj4+ Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4+IE9uIDE0IERlYyAyMDE3LCBhdCAwODoyMSwgU29uYWwg QWdhcndhbCA8c2FnYXJ3YWwxMkBnbWFpbC5jb20KPj4+Pj4+IDxtYWlsdG86c2FnYXJ3YWwx MkBnbWFpbC5jb20+PiB3cm90ZToKPj4+Pj4+Cj4+Pj4+PiBIaSBFaW5hciwKPj4+Pj4+Cj4+ Pj4+PiBZb3UgaGFkIDMgcXVlc3Rpb25zIGZvciBtZSBvbiBhbGwgdGhlIHNldmVyYWwgZS1t YWlsIHRocmVhZHMuwqAKPj4+Pj4+IDEuIEdsb2JhbCBhdHRhY2htZW50IHBvaW50Cj4+Pj4+ PiAyLiBpY21wLW9mZgo+Pj4+Pj4gMy4gYWNsLWFnZ3JlZ2F0ZS1pbnRlcmZhY2Ugc3RhdHMu Cj4+Pj4+Pgo+Pj4+Pj4gRm9yICgxKSwgbXkgZmlyc3QgcHJlZmVyZW5jZSBpcyB0byBoYXZl IHRoZSBtb2RlbCBkZWZpbmUKPj4+Pj4+IGF0dGFjaG1lbnQgcG9pbnQgZm9yIGludGVyZmFj ZXMgb25seS4KPj4+Pj4KPj4+Pj4gZWluYXJubj4gSSBoYXZlIHNvbWUgZGlmZnMsIGxheWVy ZWQgb24gdG9wIG9mIE1haGVzaOKAmXMgUFIgdG8KPj4+Pj4gbmV0bW9kLXdnL2FjbC1tb2Rl bCB0aGF0IGRvIHRoaXMuIE5lYXJseSBsaWtlIHRoZSBhdWdtZW50YXRpb24gSQo+Pj4+PiBo YXZlIGJlbG93LiBGZWVsIGZyZWUgdG8gdGFrZSBhIGxvb2sgYXQ6Cj4+Pj4+Cj4+Pj4+ICAg ICBodHRwczovL2dpdGh1Yi5jb20vbWpldGhhbmFuZGFuaS9hY2wtbW9kZWwvcHVsbC8zCj4+ Pj4+Cj4+Pj4+Cj4+Pj4+PiBIb3dldmVyLCBLcmlzdGlhbiB3YW50cyB0aGUgZ2xvYmFsIGF0 dGFjaG1lbnQgcG9pbnQgYXMgd2VsbCBzbwo+Pj4+Pj4gdGhhdCBoZSBjYW4gYWRkIHRoZSBB Q0wgdG8gdGhlIGxpbnV4IHRhYmxlcy4KPj4+Pj4KPj4+Pj4gZWluYXJubj4gSSB0aGluayBL cmlzdGlhbiBkb2VzbuKAmXQgZmVlbCBhIGdsb2JhbCBhdHRhY2htZW50IHBvaW50Cj4+Pj4+ IG5lZWRzIHRvIGJlIGluIHRoaXMgZmlyc3QgcmV2aXNpb24uIEJ1dCBoZSBjYW4gY29uZmly bS4KPj4+Pj4KPj4+Pj4+IElmIGFuIEFDTCBpcyBhdHRhY2hlZCBnbG9iYWxseSwgZG9lcyB0 aGlzIG1lYW4gaXQgaXMgcGVyCj4+Pj4+PiBkaXJlY3Rpb24gb3IgZG9lcyBpdCBtZWFuIGl0 IGlzIGFjcm9zcyBkaXJlY3Rpb25zPwo+Pj4+Pgo+Pj4+PiBlaW5hcm5uPiBJIGRvbuKAmXQg a25vdyByaWdodCBub3cgOi0pCj4+Pj4+Cj4+Pj4+PiBUaGlzIGdsb2JhbCBBQ0wgbWF5IG5v dCBiZSBhcHBsaWNhYmxlIHRvIGFueSBvZiBDaXNjbydzIHNlcnZpY2UKPj4+Pj4+IHByb3Zp ZGVyIHJvdXRlcnMgYXMgSSBkb24ndCBzZWUgYW55IHBsYXRmb3JtIGFjdHVhbGx5IHJlcGxp Y2F0aW5nCj4+Pj4+PiB0aGUgQUNMIHRvIGFsbCBsaW5lIGNhcmRzIGFuZCBhdHRhY2hpbmcg aXQgaW4gaW5ncmVzcyBhbmQgZWdyZXNzCj4+Pj4+PiBkaXJlY3Rpb25zIGFjcm9zcyBhbGwg aW50ZXJmYWNlcy4KPj4+Pj4KPj4+Pj4gZWluYXJubj4gUGVyIG90aGVyIGVtYWlscywgSSBk b27igJl0IHRoaW5rIHdlIHVuZGVyc3RhbmQgdGhpcyBlbm91Z2gKPj4+Pj4geWV0IHRvIHNw ZWNpZnkgaXQsIHNvIEkgc3VnZ2VzdCB3ZSBqdXN0IGxlYXZlIGl0IG91dCBmb3Igbm93Lgo+ Pj4+PiBOb3RoaW5nIGluIHRoZSBtb2RlbCBwcmV2ZW50cyBhIOKAnGdsb2JhbCBhdHRhY2ht ZW50IHBvaW504oCdIGJlaW5nCj4+Pj4+IGFkZGVkIGxhdGVyIG9uY2Ugd2UgdW5kZXJzdGFu ZCB3aGF0IGl0IHJlYWxseSBtZWFucy4KPj4+Pj4KPj4+Pj4+IEZvciAoMiksIEkgYW0gb2sg d2l0aCByZW1vdmluZyBpY21wLW9mZi4KPj4+Pj4KPj4+Pj4gZWluYXJubj4gRG9uZSBpbiBt eSBQUiBhYm92ZS4KPj4+Pj4KPj4+Pj4+IEZvciAoMyksIHRoaXMgd291bGQgaGF2ZSB0byBi ZSBhIGNvbWJpbmF0aW9uIG9mIEFDTCBzdGF0cyBhY3Jvc3MKPj4+Pj4+IGFsbCBpbnRlcmZh Y2VzIGZvciBhbGwgQUNMJ3MuIFNvbWV0aGluZyBsaWtlIHRoaXMgaXMgcG9zc2libGUgb24K Pj4+Pj4+IGFuIFhSIGJveCB3aGVyZSBBQ0VTIGhhdmUgY291bnRlciBuYW1lcyBhc3NvY2lh dGVkIHdpdGggaXQuIExldCdzCj4+Pj4+PiBjaGF0IGFib3V0IHRoaXMgb2ZmbGluZSB0b21v cnJvdy4KPj4+Pj4KPj4+Pj4gZWluYXJubj4gSeKAmWxsIHBpbmcgeW91IHRvIGNsYXJpZnks IGFuZCB3ZSBjYW4gYnJpbmcgYW55IGNvbmNsdXNpb24KPj4+Pj4gYmFjayB0byB0aGUgbGlz dC4KPj4+Pj4KPj4+Pj4gQ2hlZXJzLAo+Pj4+Pgo+Pj4+PiBFaW5hcgo+Pj4+Pgo+Pj4+Pgo+ Pj4+Pgo+Pj4+Pj4gU29uYWwuCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+IE9uIFdlZCwgRGVjIDEz LCAyMDE3IGF0IDEyOjEwIFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pCj4+Pj4+PiA8bWpldGhh bmFuZGFuaUBnbWFpbC5jb20gPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdy b3RlOgo+Pj4+Pj4KPj4+Pj4+ICAgICBXZSB3YW50IHRvIHN1cHBvcnQg4oCcZ2xvYmFs4oCd IGF0dGFjaG1lbnQgcG9pbnQgZG93biB0aGUgbGluZSwKPj4+Pj4+ICAgICBhbmQgdGhhdCDi gJxnbG9iYWzigJ0gYXR0YWNobWVudCBwb2ludCB3aWxsIGJlIG9uZSBvZiB0aGUgY2hvaWNl cwo+Pj4+Pj4gICAgICh0aGUgb3RoZXIgYmVpbmcgdGhlIGludGVyZmFjZSksIHdoYXQgd291 bGQgdGhpcyBhdWdtZW50IGxvb2sKPj4+Pj4+ICAgICBsaWtlLiBOb3RlLCBhcyBmYXIgYXMg SSBrbm93LCB5b3UgY2Fubm90IGF1Z21lbnQgaW5zaWRlIGEKPj4+Pj4+ICAgICBjaG9pY2Ug bm9kZS4KPj4+Pj4+Cj4+Pj4+Pj4gICAgIE9uIERlYyAxMywgMjAxNywgYXQgNjo1NyBBTSwg RWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pCj4+Pj4+Pj4gICAgIDxlaW5hcm5uQGNp c2NvLmNvbSA8bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4gd3JvdGU6Cj4+Pj4+Pj4KPj4+ Pj4+PiAgICAgUGVyaGFwcyBsaWtlIHRoaXMsIGFzIGFuIGF1Z21lbnRhdGlvbiB0byB0aGUg aW50ZXJmYWNlOgo+Pj4+Pj4+Cj4+Pj4+Pj4gICAgICAgICDCoCBhdWdtZW50IC9pZjppbnRl cmZhY2VzL2lmOmludGVyZmFjZToKPj4+Pj4+PiAgICAgICAgIMKgIMKgICstLXJ3IGluZ3Jl c3MtYWNscwo+Pj4+Pj4+ICAgICAgICAgwqAgwqAgfCDCoCstLXJ3IGFjbC1zZXRzCj4+Pj4+ Pj4gICAgICAgICDCoCDCoCB8IMKgIMKgICstLXJ3IGFjbC1zZXQqIFtuYW1lXQo+Pj4+Pj4+ ICAgICAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCstLXJ3IG5hbWUgwqAgwqAgwqAgwqAgwqAg wqAgwqAtPgo+Pj4+Pj4+ICAgICAgICAgL2FjY2Vzcy1saXN0cy9hY2wvbmFtZQo+Pj4+Pj4+ ICAgICAgICAgwqAgwqAgfCDCoCDCoCDCoCDCoCstLXJ3IHR5cGU/IMKgIMKgIMKgIMKgIMKg IMKgIC0+Cj4+Pj4+Pj4gICAgICAgICAvYWNjZXNzLWxpc3RzL2FjbC90eXBlCj4+Pj4+Pj4g ICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgKy0tcm8gYWNlLXN0YXRpc3RpY3MqIFtuYW1l XSB7aW50ZXJmYWNlLXN0YXRzfT8KPj4+Pj4+PiAgICAgICAgIMKgIMKgIHwgwqAgwqAgwqAg wqAgwqAgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+Pj4+Pj4+ICAgICAg ICAgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+Pj4+Pj4+ICAgICAgICAgwqAg wqAgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlhbmc6Y291 bnRlcjY0Cj4+Pj4+Pj4gICAgICAgICDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1h dGNoZWQtb2N0ZXRzPyDCoCDCoHlhbmc6Y291bnRlcjY0Cj4+Pj4+Pj4gICAgICAgICDCoCDC oCArLS1ydyBlZ3Jlc3MtYWNscwo+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqArLS1ydyBh Y2wtc2V0cwo+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldCog W25hbWVdCj4+Pj4+Pj4gICAgICAgICDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLXJ3IG5hbWUg wqAgwqAgwqAgwqAgwqAgwqAgwqAtPgo+Pj4+Pj4+ICAgICAgICAgL2FjY2Vzcy1saXN0cy9h Y2wvbmFtZQo+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ydyB0eXBl PyDCoCDCoCDCoCDCoCDCoCDCoCAtPgo+Pj4+Pj4+ICAgICAgICAgL2FjY2Vzcy1saXN0cy9h Y2wvdHlwZQo+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqArLS1ybyBhY2Ut c3RhdGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pwo+Pj4+Pj4+ICAgICAgICAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDC oCAtPgo+Pj4+Pj4+ICAgICAgICAgL2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvbmFtZQo+ Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbWF0Y2hlZC1w YWNrZXRzPyDCoCB5YW5nOmNvdW50ZXI2NAo+Pj4+Pj4+ICAgICAgICAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKy0tcm8gbWF0Y2hlZC1vY3RldHM/IMKgIMKgeWFuZzpjb3VudGVyNjQK Pj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4gICAgIENvdWxkIGFsc28gcHV0IGFuIOKAnGFjZXPi gJ0gY29udGFpbmVyIGFib3ZlIGJvdGggdGhlc2UgJiByZW5hbWUKPj4+Pj4+PiAgICAg4oCc aW5ncmVzcy1hY2xzIiB0byDigJxpbmdyZXNz4oCdLCBldGMuIHRvIGdpdmUgYSBzaW5nbGUg cm9vdCBmb3IKPj4+Pj4+PiAgICAgdGhlIGF1Z21lbnRhdGlvbiBpZiBwcmVmZXJyZWQuCj4+ Pj4+Pj4KPj4+Pj4+PiAgICAgQ2hlZXJzLAo+Pj4+Pj4+Cj4+Pj4+Pj4gICAgIEVpbmFyCj4+ Pj4+Pj4KPj4+Pj4+Pgo+Pj4+Pj4+PiAgICAgT24gNiBEZWMgMjAxNywgYXQgMTk6NDMsIEVs aW90IExlYXIgPGxlYXJAY2lzY28uY29tCj4+Pj4+Pj4+ICAgICA8bWFpbHRvOmxlYXJAY2lz Y28uY29tPj4gd3JvdGU6Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+ICAg ICBPbiAxMi82LzE3IDc6MjMgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6Cj4+Pj4+ Pj4+PiAgICAgSG93IGRvZXMgb25lIG1vdmUgdGhlIGludGVyZmFjZSBhdHRhY2htZW50IHBv aW50LCBjdXJyZW50bHkgYW4KPj4+Pj4+Pj4+ICAgICAnaW50ZXJmYWNlLXJlZicsIHRvIGFu IGF1Z21lbnRhdGlvbiBvZiB0aGUKPj4+Pj4+Pj4+ICAgICBpZjppbnRlcmZhY2VzL2ludGVy ZmFjZSwKPj4+Pj4+Pj4+ICAgICBpbnNpZGUgb2YgdGhlIOKAmGFjbOKAmSDCoGNvbnRhaW5l cj8gRG93biB0aGUgbGluZSB3ZSBtaWdodAo+Pj4+Pj4+Pj4gICAgIG5lZWQgdG8gaGF2ZSBh bgo+Pj4+Pj4+Pj4gICAgIGNvbnRhaW5lciBmb3IgImF0dGFjaG1lbnQgcG9pbnRzIiB0byBh Y2NvbW1vZGF0ZSB0aGUKPj4+Pj4+Pj4+ICAgICBwb3NzaWJpbGl0eSBvZgo+Pj4+Pj4+Pj4g ICAgIGF0dGFjaGluZyBhbiBBQ0wgZWl0aGVyIHRvIGFuIGludGVyZmFjZSBvciDigJxnbG9i YWxseeKAnS4KPj4+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+ICAgICBLZWVwaW5nIGluIG1p bmQgdGhhdCBvbmUgdXNlIGlzIHRoYXQgYW4gQUNMIGRvZXNuJ3QgYXR0YWNoCj4+Pj4+Pj4+ ICAgICB0byBhbgo+Pj4+Pj4+PiAgICAgaW50ZXJmYWNlIGF0IGFsbC4KPj4+Pj4+Pj4KPj4+ Pj4+Pj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCj4+Pj4+Pj4+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+ICAgICBuZXRt b2RAaWV0Zi5vcmcgPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Cj4+Pj4+Pj4+ICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4+Pj4+PiAgICAg PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPgo+Pj4+Pj4+ Cj4+Pj4+Pgo+Pj4+Pj4gICAgIE1haGVzaCBKZXRoYW5hbmRhbmkKPj4+Pj4+ICAgICBtamV0 aGFuYW5kYW5pQGdtYWlsLmNvbSA8bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPgo+ Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPj4+Pj4+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+Pj4+ PiAgICAgbmV0bW9kQGlldGYub3JnIDxtYWlsdG86bmV0bW9kQGlldGYub3JnPgo+Pj4+Pj4g ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCj4+Pj4+ PiAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPgo+ Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPj4+Pj4gbmV0 bW9kQGlldGYub3JnIDxtYWlsdG86bmV0bW9kQGlldGYub3JnPgo+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Pj4+Cj4+Pj4KPj4+Pgo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4g bmV0bW9kIG1haWxpbmcgbGlzdAo+Pj4+IG5ldG1vZEBpZXRmLm9yZwo+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCj4+Pgo+Pgo+Cj4KPgo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9k IG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCgo= --------------FD5CDCED02D54F156AA0E24F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Presuming this issue is behind us, are all WGLC comments addressed?=C2=A0 Can we expect to see a new draft soon?

Eliot


On 18.12.17 13:31, 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=C2=A0ietf-interfaces model or the augmenta= tion 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 too= k out as part of refactoring interface attachment). Part of:

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

The augments part of the tree now looks like:

=C2=A0 augmen= t /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:<= /div>

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 th= at 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://git= hub.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
=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=A0= string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type? =C2=A0 acl-t= ype
=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 {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-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 {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)
=C2=A0 =C2=A0 =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)?<= /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+--:(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=A0in= 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 destination-port-upper =C2=A0 =C2=A0 =C2=A0in= 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 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= =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-pr= efix
=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)
=C2=A0 =C2=A0 =C2=A0 =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)?<= /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+--:(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=A0in= 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 destination-port-upper =C2=A0 =C2=A0 =C2=A0in= 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 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-pr= efix
=C2=A0 =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<= /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 +--rw data-offset? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint= 8
=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 uin= t8
=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=A0uint= 16
=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=A0uint= 32
=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 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 {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-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=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}?
=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 +--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
=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<= /div>
=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-s= et* [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<= /div>
=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<= /a>> 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 attachmen= t 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=99= s 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?<= /div>

einarnn> I don=E2=80=99= t 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 unders= tand 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 <mjet= hanandani@gmail.com> wrote:
We want to support= =E2=80=9Cglobal=E2=80=9D atta= chment point down the line, and that =E2=80=9Cglobal=E2=80=9D atta= chment 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:

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

=

Mahes= h Jethanandani
mjethanandani@gmail.com


______________________________<= wbr class=3D"">_________________<= br class=3D""> netmod mailing list
netm= od@ietf.org
http= s://www.ietf.org/mailman/listinfo/netmod<= /a>



_______________________________________________
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
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------FD5CDCED02D54F156AA0E24F-- --4lvLdgh8haXWN8eVS2I4xcgpIwsIAiTIt-- --6esDfWvicnHRqXLpXq1O8ORjJaQJoJ0On Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlo4IPUACgkQh7ZrRtnS ejNdgwf/QSmCrNoQn0v0qc8B8jrBVZBDad/UzvinYMNzMnjPkkPYNwPTFdKLL1ca 9jBuX4jBRbNgsStK+7q24NIPBV092y0/oKdol2XgSXG6jQybIGayU+IkJnynJnAd Pjz1pehU3emUfjlNmsThK+8ZEn6GhgxlazNcMGKPJP3XTP+Qsda9n249/GrlpTzm sStF9kqoUvURZHKyQce1/IRgssXaFRei6MhcIefcbDaZ+6JsNPUXwVnAbWYMzRrV a886hT9HHmSY85dBBOicBu3hfycGTDjSO2ex13Sy+5ewobOnErAKtcpKym80sN0A c52LUpNdqzM8oN1qknub2+8pEnoyPg== =UmgT -----END PGP SIGNATURE----- --6esDfWvicnHRqXLpXq1O8ORjJaQJoJ0On-- From nobody Mon Dec 18 12:15:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38056126D0C for ; Mon, 18 Dec 2017 12:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[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 hhl6KQK1qh62 for ; Mon, 18 Dec 2017 12:15:51 -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 9CFC9120046 for ; Mon, 18 Dec 2017 12:15:51 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 51E01175F9D for ; Mon, 18 Dec 2017 13:15:51 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id nYFn1w00g2SSUrH01YFqQg; Mon, 18 Dec 2017 13:15:51 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=T1rVWnlSwUYTjnjyFs8A: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: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=flwDQXFvr89eD604zyLJAR5IB0dOaJkxn2NuhqXOoxU=; b=rkZNHF4HuTYYPHWoiPQFl9l8gE CVD0ZCX0P4kRLAEVamvXJDtzR/voJ0UHjuLiCWNLUdb6ER6myhhMzMULuwoICnarf99+hvLlXindG srzSfwsg6ZJ2O28FQgpRHeAtP; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49474 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eR1pD-0043cc-7M; Mon, 18 Dec 2017 13:15:47 -0700 To: Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <151358984141.28794.3169667694911973561@ietfa.amsl.com> <20171218.103903.1338730940312800102.mbj@tail-f.com> <20171218200650.6bus7deydr3bxm2j@elstar.local> From: Lou Berger Message-ID: <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> Date: Mon, 18 Dec 2017 15:15:46 -0500 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: <20171218200650.6bus7deydr3bxm2j@elstar.local> Content-Type: text/plain; charset=utf-8 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: 1eR1pD-0043cc-7M 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]:49474 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 20:15:53 -0000 On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote: > See RFC 3688 section 4. cool, dueling BCPs. Is there a reason https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5 doesn't apply? Lou > /js > > On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: >> Martin, Authors, >> >> is there a reason that the draft says: >> >>         Registrant Contact: The IESG. >> >> vs the typical: >> >>        Registrant Contact: The NETMOD WG of the IETF. >> >> Thanks, >> >> Lou >> >> On 12/18/2017 4:39 AM, Martin Bjorklund wrote: >>> Hi, >>> >>> This version addresses the WGLC comments received. Specifically, I >>> have added ietf-hardware-state, a config false version of >>> ietf-hardware for non-NMDA implementations, in an Appendix. Please >>> review the new text and the description statement in that module. >>> >>> I have also added a reference to the tree diagram draft and use the >>> latest security guidelines template text. >>> >>> >>> /martin >>> >>> 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 Hardware Management >>>> Authors : Andy Bierman >>>> Martin Bjorklund >>>> Jie Dong >>>> Dan Romascanu >>>> Filename : draft-ietf-netmod-entity-06.txt >>>> Pages : 54 >>>> Date : 2017-12-18 >>>> >>>> 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-06 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 Dec 18 12:22:06 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131CC12D853; Mon, 18 Dec 2017 12:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[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 DdTqdOc2F2tV; Mon, 18 Dec 2017 12:22:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 586CF124239; Mon, 18 Dec 2017 12:22:02 -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 85BFE1AE0311; Mon, 18 Dec 2017 21:22:01 +0100 (CET) Date: Mon, 18 Dec 2017 21:22:01 +0100 (CET) Message-Id: <20171218.212201.175509717846279732.mbj@tail-f.com> To: lberger@labn.net Cc: draft-ietf-netmod-entity@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> References: <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@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] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 20:22:05 -0000 Lou Berger wrote: > = > = > On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote: > > See RFC 3688 section 4. > cool, dueling BCPs. cool indeed. > Is there a reason > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5= > doesn't apply? Should we follow 3688 or 6087bis? Interestingly, it seems the "Registrant Contact" is not stored in the IANA maintained registry... /martin > = > Lou > = > = > > /js > > > > On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: > >> Martin, Authors, > >> > >> is there a reason that the draft says: > >> > >> =A0=A0=A0=A0=A0=A0=A0 Registrant Contact: The IESG. > >> > >> vs the typical: > >> > >> =A0=A0=A0=A0=A0=A0 Registrant Contact: The NETMOD WG of the IETF. > >> > >> Thanks, > >> > >> Lou > >> > >> On 12/18/2017 4:39 AM, Martin Bjorklund wrote: > >>> Hi, > >>> > >>> This version addresses the WGLC comments received. Specifically,= I > >>> have added ietf-hardware-state, a config false version of > >>> ietf-hardware for non-NMDA implementations, in an Appendix. Plea= se > >>> review the new text and the description statement in that module.= > >>> > >>> I have also added a reference to the tree diagram draft and use t= he > >>> latest security guidelines template text. > >>> > >>> > >>> /martin > >>> > >>> internet-drafts@ietf.org wrote: > >>>> A New Internet-Draft is available from the on-line Internet-Draf= ts directories. > >>>> This draft is a work item of the Network Modeling WG of the IETF= .= > >>>> > >>>> Title : A YANG Data Model for Hardware Managem= ent > >>>> Authors : Andy Bierman > >>>> Martin Bjorklund > >>>> Jie Dong > >>>> Dan Romascanu > >>>> Filename : draft-ietf-netmod-entity-06.txt > >>>> Pages : 54 > >>>> Date : 2017-12-18 > >>>> > >>>> 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-06 > >>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-0= 6 > >>>> > >>>> A diff from the previous version is available at: > >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-entity-06 > >>>> > >>>> > >>>> Please note that it may take a couple of minutes from the time o= f 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 Dec 18 12:28:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8BA12D86B; Mon, 18 Dec 2017 12:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[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 Zsa3xA4bj9UB; Mon, 18 Dec 2017 12:28: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 1A9A312D853; Mon, 18 Dec 2017 12:28:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D752D673; Mon, 18 Dec 2017 21:28: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 ZIeUbfGKlc6E; Mon, 18 Dec 2017 21:28: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; Mon, 18 Dec 2017 21:28:41 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2F4520130; Mon, 18 Dec 2017 21:28: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 UJQD1nOR1brm; Mon, 18 Dec 2017 21:28:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51E1A20073; Mon, 18 Dec 2017 21:28:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 45C7341F17C3; Mon, 18 Dec 2017 21:28:41 +0100 (CET) Date: Mon, 18 Dec 2017 21:28:41 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, netmod@ietf.org Message-ID: <20171218202841.76tz74ijt5jz6lv4@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <151358984141.28794.3169667694911973561@ietfa.amsl.com> <20171218.103903.1338730940312800102.mbj@tail-f.com> <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 20:28:45 -0000 On Mon, Dec 18, 2017 at 03:15:46PM -0500, Lou Berger wrote: > > > On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote: > > See RFC 3688 section 4. > cool, dueling BCPs. > > Is there a reason > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5 > doesn't apply? > Searching through a number of RFCs containing YANG modules, I must say that we are consistently inconsistent. I would give RFC 3688 section 4 authority here since RFC 3688 defined the registry. (Note also that WGs come and go, the IESG may have a longer lifetime. That said, I assume that the responsibility for the registration falls into the hands of the IESG anyway when a WG ceases to exist.) /js PS: The IANA registry seems to maintain a pointer to the RFC, there is not really a registrant column. ;-) -- 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 Dec 18 12:30:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06F412D871 for ; Mon, 18 Dec 2017 12:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[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 39-JkXJFE6Rs for ; Mon, 18 Dec 2017 12:30:15 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 26A1612D876 for ; Mon, 18 Dec 2017 12:30:15 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id DD0341404A3 for ; Mon, 18 Dec 2017 13:30:14 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id nYWB1w0042SSUrH01YWEeV; Mon, 18 Dec 2017 13:30:14 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=Kf0pTAewjCEAPpiRrB0A: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: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=Cwykp/M0RlSIN7xzanrVxHAAwck8BT6G8J9bh0lLaB4=; b=jL4kw1GjuacQgKhO9J5r06SHJj 372aQxfIw9JJj78nQh+0MqEmYwcOw+WkrAncX/wTYAz0m2sEWnmihz2Kph9dj2/WKpwgX2H5xqpUE MJ762RaES/29iQfZlPuEH72WP; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:50176 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eR238-004Asg-R9 for netmod@ietf.org; Mon, 18 Dec 2017 13:30:11 -0700 To: NETMOD WG References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> From: Lou Berger Message-ID: <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> Date: Mon, 18 Dec 2017 15:30:08 -0500 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: <87zi6kay8b.fsf@nic.cz> Content-Type: text/plain; charset=utf-8 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: 1eR238-004Asg-R9 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]:50176 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: Mon, 18 Dec 2017 20:30:17 -0000 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? > 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. 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 From nobody Mon Dec 18 12:36:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED99C12D851 for ; Mon, 18 Dec 2017 12:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[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=unavailable 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 MilC_saKLovQ for ; Mon, 18 Dec 2017 12:36:01 -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 4255612D87E for ; Mon, 18 Dec 2017 12:36:01 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id E2A1A1E066B for ; Mon, 18 Dec 2017 13:36:00 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id nYbx1w00u2SSUrH01Yc0eA; Mon, 18 Dec 2017 13:36:00 -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=ocR9PWop10UA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=A-6qdGstqoOG-3Y-_IIA:9 a=QEXdDO2ut3YA: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=lNAINOJn1/++QNTdJ3e53X+ujGZkg047wTIJgKhn7jw=; b=H61F4arq3OiiLqx8/G7PgOEj+S O9weQTrJlnE7HDHBWom//ReRtn2qNVjl5eQ1+74SFlkKzXVdTPlt1PXDKlr03FNLeuYnF0BzW1nuq 6PnMiLHn9pcmWKIbc6JJ6h05b; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:50402 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eR28j-004EQG-BF; Mon, 18 Dec 2017 13:35:57 -0700 To: Martin Bjorklund Cc: draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> <20171218.212201.175509717846279732.mbj@tail-f.com> From: Lou Berger Message-ID: Date: Mon, 18 Dec 2017 15:35:55 -0500 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: <20171218.212201.175509717846279732.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 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: 1eR28j-004EQG-BF 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]:50402 X-Source-Auth: lberger@labn.net X-Email-Count: 15 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 20:36:04 -0000 On 12/18/2017 3:22 PM, Martin Bjorklund wrote: > Lou Berger wrote: >> >> On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote: >>> See RFC 3688 section 4. >> cool, dueling BCPs. > cool indeed. > >> Is there a reason >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5 >> doesn't apply? > Should we follow 3688 or 6087bis? Given the context (YANG module, and this WG), I think it should be 6087bis (which is the same as 6087 in this respect). I'll put in the publication request as soon as this update is made. > Interestingly, it seems the "Registrant Contact" is not stored in the > IANA maintained registry... > true. Thanks, Lou > /martin > > >> Lou >> >> >>> /js >>> >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: >>>> Martin, Authors, >>>> >>>> is there a reason that the draft says: >>>> >>>>         Registrant Contact: The IESG. >>>> >>>> vs the typical: >>>> >>>>        Registrant Contact: The NETMOD WG of the IETF. >>>> >>>> Thanks, >>>> >>>> Lou >>>> >>>> On 12/18/2017 4:39 AM, Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> This version addresses the WGLC comments received. Specifically, I >>>>> have added ietf-hardware-state, a config false version of >>>>> ietf-hardware for non-NMDA implementations, in an Appendix. Please >>>>> review the new text and the description statement in that module. >>>>> >>>>> I have also added a reference to the tree diagram draft and use the >>>>> latest security guidelines template text. >>>>> >>>>> >>>>> /martin >>>>> >>>>> 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 Hardware Management >>>>>> Authors : Andy Bierman >>>>>> Martin Bjorklund >>>>>> Jie Dong >>>>>> Dan Romascanu >>>>>> Filename : draft-ietf-netmod-entity-06.txt >>>>>> Pages : 54 >>>>>> Date : 2017-12-18 >>>>>> >>>>>> 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-06 >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 Dec 18 12:56:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615C7120713; Mon, 18 Dec 2017 12:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[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 y7abQbXyWoWd; Mon, 18 Dec 2017 12:56:47 -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 621E11200FC; Mon, 18 Dec 2017 12:56:47 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2A7F5673; Mon, 18 Dec 2017 21:56:46 +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 49-Urrws1e1H; Mon, 18 Dec 2017 21:56: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; Mon, 18 Dec 2017 21:56:46 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15D9420073; Mon, 18 Dec 2017 21:56:46 +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 ERyju4_NSPtT; Mon, 18 Dec 2017 21:56:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6182420130; Mon, 18 Dec 2017 21:56:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 22BED41F1901; Mon, 18 Dec 2017 21:56:44 +0100 (CET) Date: Mon, 18 Dec 2017 21:56:44 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, netmod@ietf.org Message-ID: <20171218205644.zp27kn6qm5rqhr77@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, netmod@ietf.org References: <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> <20171218.212201.175509717846279732.mbj@tail-f.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: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 20:56:49 -0000 On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote: > > Given the context (YANG module, and this WG), I think it should be > 6087bis (which is the same as 6087 in this respect). Does RFC 6087 formally update RFC 3688? Registrant Contact The individual/organization that is the registration contact for the component being registered. Ideally, this will be the name and pertinent physical and network contact information. In the case of IETF developed standards, the Registrant will be the IESG. /js > I'll put in the publication request as soon as this update is made. > > > Interestingly, it seems the "Registrant Contact" is not stored in the > > IANA maintained registry... > > > > true. > > Thanks, > Lou > > > /martin > > > > > >> Lou > >> > >> > >>> /js > >>> > >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: > >>>> Martin, Authors, > >>>> > >>>> is there a reason that the draft says: > >>>> > >>>> Registrant Contact: The IESG. > >>>> > >>>> vs the typical: > >>>> > >>>> Registrant Contact: The NETMOD WG of the IETF. > >>>> > >>>> Thanks, > >>>> > >>>> Lou > >>>> > >>>> On 12/18/2017 4:39 AM, Martin Bjorklund wrote: > >>>>> Hi, > >>>>> > >>>>> This version addresses the WGLC comments received. Specifically, I > >>>>> have added ietf-hardware-state, a config false version of > >>>>> ietf-hardware for non-NMDA implementations, in an Appendix. Please > >>>>> review the new text and the description statement in that module. > >>>>> > >>>>> I have also added a reference to the tree diagram draft and use the > >>>>> latest security guidelines template text. > >>>>> > >>>>> > >>>>> /martin > >>>>> > >>>>> 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 Hardware Management > >>>>>> Authors : Andy Bierman > >>>>>> Martin Bjorklund > >>>>>> Jie Dong > >>>>>> Dan Romascanu > >>>>>> Filename : draft-ietf-netmod-entity-06.txt > >>>>>> Pages : 54 > >>>>>> Date : 2017-12-18 > >>>>>> > >>>>>> 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-06 > >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 > >>>>>> > >>>>>> A diff from the previous version is available at: > >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 > > _______________________________________________ > 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 Dec 18 13:02:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE0512D886 for ; Mon, 18 Dec 2017 13:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UsiJa_TpBEes for ; Mon, 18 Dec 2017 13:01:57 -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 9949F120713 for ; Mon, 18 Dec 2017 13:01:56 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id y78so13635488lfd.1 for ; Mon, 18 Dec 2017 13:01:56 -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=h258b27sYVdKpi1Zyj3eMvYqKMIhW6+dXhDUNjagtQE=; b=wn33747nBtElePKum1BnWu+U2H7jUESub/36WDv8gQotWgOd8nwU1nGrDhCwWEQG7F cdTAw7yI68ujoQt+LD/M4tAKpUcUXEKMbtwlirgzNoCuWbLUWmD4gWsm/CM1TjdfA5Aj REd0pAcREa7tVRrUp0UllJXFe4yFb5MllCL0fB/R3mH4rQKEwoxA8CYoVixFnmK/njJo KhPAZR06kuz/hazy/ryz8f0QK2+Ots2DuuEr/PyxDQmFsDzVxlnPZ7pUgClM5vXmHFDn XfPxOUtFVfH8jgN718YIZX6DtZeRY0U1J9u10hLRXi94+Twmm1Ov/n1mG9KknWoJkvVK JcuQ== 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=h258b27sYVdKpi1Zyj3eMvYqKMIhW6+dXhDUNjagtQE=; b=im66oFYzdbnZr7SYNjs/EeP07uh8TForEFVAScMzT15sBD4xQcYWd+Wm2YKjkL4xcm 0hCqcLrXdBLCvU86id8+k6LFqMr9rX8PETG4T1Wh1sfwsz95+ogyvZGaJgVawgvMy9GM oPGo6F4WIpH3UHcWCmMPZgPvj3HCLoCwcuAiIzvnXZhCgMdJVd2x8kBJkTvhmD7+O3Xx /kBb17x/bD9VtSh0teeFgBhgMJenZKBjsVejKMxFJcb4gK+1omvfF4rmUasUdqcaPPXQ QgNKOD1VaUuAFj8o37UOEEQonQKMAQvIloEnK1CDmuYBTtBUyCeQ8wE7UTia/lbATS/g 4ioA== X-Gm-Message-State: AKGB3mJllOXtYfnnkO1mFhjbAkLXh7vD8yEhls26gVrNu+hyiaOp7xfX pLhx25JoVb7MHdfU0kxoN7Q/+RV9PCiCwdNI6QOMig== X-Google-Smtp-Source: ACJfBouGxp30JdGX1hVeIpJm4y1Og4RKcCL28sI+n02+TVi98JQv33dMIzmNrigrrUh4wmaX8bNMn5glLO2k2/TgoXY= X-Received: by 10.25.15.217 with SMTP id 86mr769879lfp.67.1513630913900; Mon, 18 Dec 2017 13:01:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Mon, 18 Dec 2017 13:01:52 -0800 (PST) In-Reply-To: <20171218205644.zp27kn6qm5rqhr77@elstar.local> References: <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> <20171218.212201.175509717846279732.mbj@tail-f.com> <20171218205644.zp27kn6qm5rqhr77@elstar.local> From: Andy Bierman Date: Mon, 18 Dec 2017 13:01:52 -0800 Message-ID: To: Juergen Schoenwaelder , Lou Berger , Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, NetMod WG Content-Type: multipart/alternative; boundary="001a113f323af1c6240560a3a8ee" Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 21:01:59 -0000 --001a113f323af1c6240560a3a8ee Content-Type: text/plain; charset="UTF-8" On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote: > > > > Given the context (YANG module, and this WG), I think it should be > > 6087bis (which is the same as 6087 in this respect). > > Does RFC 6087 formally update RFC 3688? > > Not intentionally. The 3688 text should probably be used instead of 6087bis. Andy Registrant Contact > The individual/organization that is the registration contact for > the component being registered. Ideally, this will be the name > and pertinent physical and network contact information. In the > case of IETF developed standards, the Registrant will be the IESG. > > /js > > > I'll put in the publication request as soon as this update is made. > > > > > Interestingly, it seems the "Registrant Contact" is not stored in the > > > IANA maintained registry... > > > > > > > true. > > > > Thanks, > > Lou > > > > > /martin > > > > > > > > >> Lou > > >> > > >> > > >>> /js > > >>> > > >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: > > >>>> Martin, Authors, > > >>>> > > >>>> is there a reason that the draft says: > > >>>> > > >>>> Registrant Contact: The IESG. > > >>>> > > >>>> vs the typical: > > >>>> > > >>>> Registrant Contact: The NETMOD WG of the IETF. > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Lou > > >>>> > > >>>> On 12/18/2017 4:39 AM, Martin Bjorklund wrote: > > >>>>> Hi, > > >>>>> > > >>>>> This version addresses the WGLC comments received. Specifically, I > > >>>>> have added ietf-hardware-state, a config false version of > > >>>>> ietf-hardware for non-NMDA implementations, in an Appendix. Please > > >>>>> review the new text and the description statement in that module. > > >>>>> > > >>>>> I have also added a reference to the tree diagram draft and use the > > >>>>> latest security guidelines template text. > > >>>>> > > >>>>> > > >>>>> /martin > > >>>>> > > >>>>> 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 Hardware > Management > > >>>>>> Authors : Andy Bierman > > >>>>>> Martin Bjorklund > > >>>>>> Jie Dong > > >>>>>> Dan Romascanu > > >>>>>> Filename : draft-ietf-netmod-entity-06.txt > > >>>>>> Pages : 54 > > >>>>>> Date : 2017-12-18 > > >>>>>> > > >>>>>> 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-06 > > >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 > > >>>>>> > > >>>>>> A diff from the previous version is available at: > > >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 > > > > _______________________________________________ > > 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 > --001a113f323af1c6240560a3a8ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berge= r wrote:
>
> Given the context (YANG module, and this WG), I think it should be
> 6087bis (which is the same as 6087 in this respect).

Does RFC 6087 formally update RFC 3688?


Not intentionally.
The 3688 = text =C2=A0should probably be used instead of 6087bis.

=

Andy



=
=C2=A0 =C2=A0Registrant Contact
=C2=A0 =C2=A0 =C2=A0 The individual/organization that is the registration c= ontact for
=C2=A0 =C2=A0 =C2=A0 the component being registered.=C2=A0 Ideally, this wi= ll be the name
=C2=A0 =C2=A0 =C2=A0 and pertinent physical and network contact information= .=C2=A0 In the
=C2=A0 =C2=A0 =C2=A0 case of IETF developed standards, the Registrant will = be the IESG.

/js

> I'll put in the publication request as soon as this update is made= .
>
> > Interestingly, it seems the "Registrant Contact" is not= stored in the
> > IANA maintained registry...
> >
>
> true.
>
> Thanks,
> Lou
>
> > /martin
> >
> >
> >> Lou
> >>
> >>
> >>> /js
> >>>
> >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrot= e:
> >>>> Martin, Authors,
> >>>>
> >>>> is there a reason that the draft says:
> >>>>
> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Registrant= Contact: The IESG.
> >>>>
> >>>> vs the typical:
> >>>>
> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Registrant Conta= ct: The NETMOD WG of the IETF.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Lou
> >>>>
> >>>> On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> >>>>> Hi,
> >>>>>
> >>>>> This version addresses the WGLC comments received= .=C2=A0 Specifically, I
> >>>>> have added ietf-hardware-state, a config false ve= rsion of
> >>>>> ietf-hardware for non-NMDA implementations, in an= Appendix.=C2=A0 Please
> >>>>> review the new text and the description statement= in that module.
> >>>>>
> >>>>> I have also added a reference to the tree diagram= draft and use the
> >>>>> latest security guidelines template text.
> >>>>>
> >>>>>
> >>>>> /martin
> >>>>>
> >>>>> inter= net-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 Mode= ling WG of the IETF.
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A YANG Data Model for Hardware Manageme= nt
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andy Bierman
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Martin Bjorklund
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jie Dong
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dan Romascanu
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2= =A0 =C2=A0 =C2=A0 : draft-ietf-netmod-entity-06.txt
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: 54
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2017-12-18
> >>>>>>
> >>>>>> Abstract:
> >>>>>>=C2=A0 =C2=A0 This document defines a YANG dat= a model for the management of
> >>>>>>=C2=A0 =C2=A0 hardware on a single server.
> >>>>>>
> >>>>>>
> >>>>>> The IETF datatracker status page for this dra= ft is:
> >>>>>> https://data= tracker.ietf.org/doc/draft-ietf-netmod-entity/
> >>>>>>
> >>>>>> There are also htmlized versions available at= :
> >>>>>> https://tools.i= etf.org/html/draft-ietf-netmod-entity-06
> >>>>>> https= ://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06<= br> > >>>>>>
> >>>>>> A diff from the previous version is available= at:
> >>>>>> https:= //www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-entity-06
> >>>>>>
> >>>>>>
> >>>>>> Please note that it may take a couple of minu= tes from the time of submission
> >>>>>> until the htmlized version and diff are avail= able at tools.ietf.org.
> >>>>>>
> >>>>>> Internet-Drafts are also available by anonymo= us FTP at:
> >>>>>> ftp://ftp.ietf.org/internet-dr= afts/
> >>>>>>
> >>>>>> ________________________________________= _______
> >>>>>> netmod mailing list
> >>>>>> netmod@iet= f.org
> >>>>>> https://www.ietf.org/mailm= an/listinfo/netmod
> >>>>>>
> >>>>> ____________________________________________= ___
> >>>>> netmod mailing list
> >>>>> netmod@ietf.or= g
> >>>>> https://www.ietf.org/mailman/<= wbr>listinfo/netmod
> >>>>>
> >>>> _______________________________________________<= br> > >>>> 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=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<http://www.jacobs-university.de/>

--001a113f323af1c6240560a3a8ee-- From nobody Mon Dec 18 13:04:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD795120713 for ; Mon, 18 Dec 2017 13:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[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 jl294CvpqcEw for ; Mon, 18 Dec 2017 13:03:58 -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 94D2A12D940 for ; Mon, 18 Dec 2017 13:03:58 -0800 (PST) Received: from cmgw3 (cmgw4 [10.0.90.84]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id F3B8D175A86 for ; Mon, 18 Dec 2017 14:03:57 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id nZ3u1w00S2SSUrH01Z3xvh; Mon, 18 Dec 2017 14:03:57 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=RtAJW_OcX2L0fN8HqfYA:9 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=9ZYBcOd_X9kS2t7VFny2: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: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=noY4ZKGLi3Wge6wLrUBehv0Qm2rbynTO5SxR6rqDH9M=; b=NwG3mTGSzVwXRj+17mI2R+SxN4 WX4kJvMPLMUqdoUcvk0LO7SK85mD7qOzIxlhjGmc2qt2tvVAUxSoERxxpQVsaqtda1/Ot8ARN+cwH ZhMobaAry1jxMRtdBxFiqJ4JK; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:51646 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 1eR2Zm-0001x3-0r; Mon, 18 Dec 2017 14:03:54 -0700 To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, NetMod WG References: <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> <20171218.212201.175509717846279732.mbj@tail-f.com> <20171218205644.zp27kn6qm5rqhr77@elstar.local> From: Lou Berger Message-ID: Date: Mon, 18 Dec 2017 16:03:52 -0500 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 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: 1eR2Zm-0001x3-0r 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]:51646 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 21:04:01 -0000 On 12/18/2017 04:01 PM, Andy Bierman wrote: > > > On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder > > wrote: > > On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote: > > > > Given the context (YANG module, and this WG), I think it should be > > 6087bis (which is the same as 6087 in this respect). > > Does RFC 6087 formally update RFC 3688? > > > Not intentionally. > The 3688 text  should probably be used instead of 6087bis. > yikes. really? so you think rfc6087 and the netmod RFCs were wrong? Thanks, Lou > > Andy > > > >    Registrant Contact >       The individual/organization that is the registration contact for >       the component being registered.  Ideally, this will be the name >       and pertinent physical and network contact information.  In the >       case of IETF developed standards, the Registrant will be the IESG. > > /js > > > I'll put in the publication request as soon as this update is made. > > > > > Interestingly, it seems the "Registrant Contact" is not stored > in the > > > IANA maintained registry... > > > > > > > true. > > > > Thanks, > > Lou > > > > > /martin > > > > > > > > >> Lou > > >> > > >> > > >>> /js > > >>> > > >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: > > >>>> Martin, Authors, > > >>>> > > >>>> is there a reason that the draft says: > > >>>> > > >>>>         Registrant Contact: The IESG. > > >>>> > > >>>> vs the typical: > > >>>> > > >>>>        Registrant Contact: The NETMOD WG of the IETF. > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Lou > > >>>> > > >>>> On 12/18/2017 4:39 AM, Martin Bjorklund wrote: > > >>>>> Hi, > > >>>>> > > >>>>> This version addresses the WGLC comments received.  > Specifically, I > > >>>>> have added ietf-hardware-state, a config false version of > > >>>>> ietf-hardware for non-NMDA implementations, in an Appendix.  > Please > > >>>>> review the new text and the description statement in that > module. > > >>>>> > > >>>>> I have also added a reference to the tree diagram draft and > use the > > >>>>> latest security guidelines template text. > > >>>>> > > >>>>> > > >>>>> /martin > > >>>>> > > >>>>> 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 Hardware > Management > > >>>>>>         Authors         : Andy Bierman > > >>>>>>                           Martin Bjorklund > > >>>>>>                           Jie Dong > > >>>>>>                           Dan Romascanu > > >>>>>>        Filename        : draft-ietf-netmod-entity-06.txt > > >>>>>>        Pages           : 54 > > >>>>>>        Date            : 2017-12-18 > > >>>>>> > > >>>>>> 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-06 > > > >>>>>> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 > > > >>>>>> > > >>>>>> A diff from the previous version is available at: > > >>>>>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 > > > > > _______________________________________________ > > 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 Dec 18 13:11:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8312D890 for ; Mon, 18 Dec 2017 13:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sLcgykuXLc6M for ; Mon, 18 Dec 2017 13:11:11 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 B589112D88A for ; Mon, 18 Dec 2017 13:11:10 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id f13so19294346lff.12 for ; Mon, 18 Dec 2017 13:11:10 -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=WH5S2oVL+rQ+drZiQf0n58HPz4rW5vFYZHkg3VuJntQ=; b=u+4XkrmXkK611Nue3NNfy95UMBEwaVxhlat3dWLV7CYr31NBWcqCgPDiVANxLVvmds pLBptSBY88C0yrKTwVWIsHb4t6JiwRLY3/IvG7mmpHclC6vJtTsx+cj1NbStHsphC5cj cx/o53XC7vcYP7g/s6brY384ZW5qDHejESNP7HuO+ypo2+55puLwQHg8g189vU1fmJgy 0mH7e2k5Qi81JN4VD0KpcPU8igTu7umw8QfSI+Ph5OK1Vg8+yZzQwXRKemrZ/IbbMkYm oJY2cDeB3SenUUJ5Em8/Mvzg0hIi9qfcghZgJN7VY9g9Kf5gQjcFtxoANay6w08KVd3R uTDQ== 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=WH5S2oVL+rQ+drZiQf0n58HPz4rW5vFYZHkg3VuJntQ=; b=DaYsrN/Bl6DWP6F8B530nUe233bEazUGqJtC0WYOrkdHJTu3p0lBGIoOsqueQj+zpd jp4rJIZFPLDHEmCTkVd6B/kisKU+oJXVho7CNen3+k77BTJVeyVQrkQwVrWTfOyDTUV/ E/6N5dhZSeL5memMtKkYUm+ciIw9wNzMXJc+vZJiv+sCzreOusdZ60a+Ge0Inhb7gl3r IypgYWjkRYQohH+REOJLtAyuUI5DobbR188TbsETgBBp0rBeiB9zVvSZmsMSl3/R+oD1 Cj2cLpJbsYOxYhP0YhKrdQ0UkgR2JYRiFIthHPh9idr4QipM9UevZ2K7SHnZMuDvNTc5 OTTg== X-Gm-Message-State: AKGB3mImIjRPmX5suqrbpkeWfq+rOgmc0og/ZLgOYNvRmV0ZYpSCoAPT mjpXohreKJDnwGtk5MjQjXXxWEk/HsGVOwKJuhEw6Q== X-Google-Smtp-Source: ACJfBotgiwMUicb/e49HnTpSg2qEypPmfcQ/n0n7Obidnr52qCoBqEczrkwJAAB8qkGG8cXmdQlK24pnF0RXNOmUj1Q= X-Received: by 10.46.93.27 with SMTP id r27mr838687ljb.96.1513631468888; Mon, 18 Dec 2017 13:11:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Mon, 18 Dec 2017 13:11:07 -0800 (PST) In-Reply-To: References: <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> <20171218.212201.175509717846279732.mbj@tail-f.com> <20171218205644.zp27kn6qm5rqhr77@elstar.local> From: Andy Bierman Date: Mon, 18 Dec 2017 13:11:07 -0800 Message-ID: To: Lou Berger Cc: Juergen Schoenwaelder , Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, NetMod WG Content-Type: multipart/alternative; boundary="001a114d60420638170560a3ca4d" Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 21:11:13 -0000 --001a114d60420638170560a3ca4d Content-Type: text/plain; charset="UTF-8" On Mon, Dec 18, 2017 at 1:03 PM, Lou Berger wrote: > On 12/18/2017 04:01 PM, Andy Bierman wrote: > > > > > > On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder > > > > wrote: > > > > On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote: > > > > > > Given the context (YANG module, and this WG), I think it should be > > > 6087bis (which is the same as 6087 in this respect). > > > > Does RFC 6087 formally update RFC 3688? > > > > > > Not intentionally. > > The 3688 text should probably be used instead of 6087bis. > > > yikes. really? so you think rfc6087 and the netmod RFCs were wrong? > > Not wrong, but the more generic text applies to all WGs, not just NETMOD WG. The YANG module contact info has the WG details. Since the NETMOD WG is long-lived, it may be better to list NETMOD WG. It doesn't seem to matter since this info is not in the registry anyway. > Thanks, > Lou > Andy > > > > > Andy > > > > > > > > Registrant Contact > > The individual/organization that is the registration contact > for > > the component being registered. Ideally, this will be the name > > and pertinent physical and network contact information. In the > > case of IETF developed standards, the Registrant will be the > IESG. > > > > /js > > > > > I'll put in the publication request as soon as this update is made. > > > > > > > Interestingly, it seems the "Registrant Contact" is not stored > > in the > > > > IANA maintained registry... > > > > > > > > > > true. > > > > > > Thanks, > > > Lou > > > > > > > /martin > > > > > > > > > > > >> Lou > > > >> > > > >> > > > >>> /js > > > >>> > > > >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote: > > > >>>> Martin, Authors, > > > >>>> > > > >>>> is there a reason that the draft says: > > > >>>> > > > >>>> Registrant Contact: The IESG. > > > >>>> > > > >>>> vs the typical: > > > >>>> > > > >>>> Registrant Contact: The NETMOD WG of the IETF. > > > >>>> > > > >>>> Thanks, > > > >>>> > > > >>>> Lou > > > >>>> > > > >>>> On 12/18/2017 4:39 AM, Martin Bjorklund wrote: > > > >>>>> Hi, > > > >>>>> > > > >>>>> This version addresses the WGLC comments received. > > Specifically, I > > > >>>>> have added ietf-hardware-state, a config false version of > > > >>>>> ietf-hardware for non-NMDA implementations, in an Appendix. > > Please > > > >>>>> review the new text and the description statement in that > > module. > > > >>>>> > > > >>>>> I have also added a reference to the tree diagram draft and > > use the > > > >>>>> latest security guidelines template text. > > > >>>>> > > > >>>>> > > > >>>>> /martin > > > >>>>> > > > >>>>> 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 Hardware > > Management > > > >>>>>> Authors : Andy Bierman > > > >>>>>> Martin Bjorklund > > > >>>>>> Jie Dong > > > >>>>>> Dan Romascanu > > > >>>>>> Filename : draft-ietf-netmod-entity-06.txt > > > >>>>>> Pages : 54 > > > >>>>>> Date : 2017-12-18 > > > >>>>>> > > > >>>>>> 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-06 > > > > > >>>>>> > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06 > > > > > >>>>>> > > > >>>>>> A diff from the previous version is available at: > > > >>>>>> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 > > > > > > > > _______________________________________________ > > > 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 > > > > > > > > --001a114d60420638170560a3ca4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 18, 2017 at 1:03 PM, Lou Berger <lberger@labn.net> wrote:
On 12/18/2017 04:01 PM, Andy= Bierman wrote:
>
>
> On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder
> <j.schoenwa= elder@jacobs-university.de
> <mailto:j.s= choenwaelder@jacobs-university.de>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berge= r wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Given the context (YANG module, and this WG), = I think it should be
>=C2=A0 =C2=A0 =C2=A0> 6087bis (which is the same as 6087 in this res= pect).
>
>=C2=A0 =C2=A0 =C2=A0Does RFC 6087 formally update RFC 3688?
>
>
> Not intentionally.
> The 3688 text =C2=A0should probably be used instead of 6087bis.
>
yikes.=C2=A0 really? so you think rfc6087 and the netmod RFCs were wrong?

Not wrong, but the more generic text a= pplies to all WGs,
not just NETMOD WG.=C2=A0 The YANG module cont= act info
has the WG details. Since the NETMOD WG is long-lived,
it may be better to list NETMOD WG.=C2=A0 It doesn't seem to m= atter
since this info is not in the registry anyway.

=C2=A0
Thanks,
Lou


Andy
=C2= =A0

>
> Andy
>
>
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Registrant Contact
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 The individual/organization th= at is the registration contact for
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 the component being registered= .=C2=A0 Ideally, this will be the name
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 and pertinent physical and net= work contact information.=C2=A0 In the
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 case of IETF developed standar= ds, the Registrant will be the IESG.
>
>=C2=A0 =C2=A0 =C2=A0/js
>
>=C2=A0 =C2=A0 =C2=A0> I'll put in the publication request as soo= n as this update is made.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> > Interestingly, it seems the "Registr= ant Contact" is not stored
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0> > IANA maintained registry...
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> true.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks,
>=C2=A0 =C2=A0 =C2=A0> Lou
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> > /martin
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> >> Lou
>=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> >>> On Mon, Dec 18, 2017 at 03:00:26P= M -0500, Lou Berger wrote:
>=C2=A0 =C2=A0 =C2=A0> >>>> Martin, Authors,
>=C2=A0 =C2=A0 =C2=A0> >>>>
>=C2=A0 =C2=A0 =C2=A0> >>>> is there a reason that the dr= aft says:
>=C2=A0 =C2=A0 =C2=A0> >>>>
>=C2=A0 =C2=A0 =C2=A0> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Registrant Contact: The IESG.
>=C2=A0 =C2=A0 =C2=A0> >>>>
>=C2=A0 =C2=A0 =C2=A0> >>>> vs the typical:
>=C2=A0 =C2=A0 =C2=A0> >>>>
>=C2=A0 =C2=A0 =C2=A0> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Registrant Contact: The NETMOD WG of the IETF.
>=C2=A0 =C2=A0 =C2=A0> >>>>
>=C2=A0 =C2=A0 =C2=A0> >>>> Thanks,
>=C2=A0 =C2=A0 =C2=A0> >>>>
>=C2=A0 =C2=A0 =C2=A0> >>>> Lou
>=C2=A0 =C2=A0 =C2=A0> >>>>
>=C2=A0 =C2=A0 =C2=A0> >>>> On 12/18/2017 4:39 AM, Martin= Bjorklund wrote:
>=C2=A0 =C2=A0 =C2=A0> >>>>> Hi,
>=C2=A0 =C2=A0 =C2=A0> >>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>> This version addresses th= e WGLC comments received.=C2=A0
>=C2=A0 =C2=A0 =C2=A0Specifically, I
>=C2=A0 =C2=A0 =C2=A0> >>>>> have added ietf-hardware-= state, a config false version of
>=C2=A0 =C2=A0 =C2=A0> >>>>> ietf-hardware for non-NMD= A implementations, in an Appendix.=C2=A0
>=C2=A0 =C2=A0 =C2=A0Please
>=C2=A0 =C2=A0 =C2=A0> >>>>> review the new text and t= he description statement in that
>=C2=A0 =C2=A0 =C2=A0module.
>=C2=A0 =C2=A0 =C2=A0> >>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>> I have also added a refer= ence to the tree diagram draft and
>=C2=A0 =C2=A0 =C2=A0use the
>=C2=A0 =C2=A0 =C2=A0> >>>>> latest security guideline= s template text.
>=C2=A0 =C2=A0 =C2=A0> >>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>> /martin
>=C2=A0 =C2=A0 =C2=A0> >>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>> internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>=C2=A0 =C2=A0 =C2=A0wrote:
>=C2=A0 =C2=A0 =C2=A0> >>>>>> A New Internet-Draft = is available from the on-line
>=C2=A0 =C2=A0 =C2=A0Internet-Drafts directories.
>=C2=A0 =C2=A0 =C2=A0> >>>>>> This draft is a work = item of the Network Modeling WG of the
>=C2=A0 =C2=A0 =C2=A0IETF.
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A YANG Data Mo= del for Hardware
>=C2=A0 =C2=A0 =C2=A0Management
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andy Bierman
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Martin Bjorklund
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jie Dong
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Dan Romascanu
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-netmod-entity-06.txt
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 54
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2017-12-18
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>> Abstract:
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 This doc= ument defines a YANG data model for the
>=C2=A0 =C2=A0 =C2=A0management of
>=C2=A0 =C2=A0 =C2=A0> >>>>>>=C2=A0 =C2=A0 hardware= on a single server.
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>> The IETF datatracker = status page for this draft is:
>=C2=A0 =C2=A0 =C2=A0> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/=
>=C2=A0 =C2=A0 =C2=A0<https://datatr= acker.ietf.org/doc/draft-ietf-netmod-entity/>
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>> There are also htmliz= ed versions available at:
>=C2=A0 =C2=A0 =C2=A0> >>>>>> https://tools.ietf.org/html/draft-ietf-netmod-entity-06 >=C2=A0 =C2=A0 =C2=A0<https://tools.iet= f.org/html/draft-ietf-netmod-entity-06>
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
>=C2=A0 =C2=A0 =C2=A0<https:/= /datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06>= ;
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>> A diff from the previ= ous version is available at:
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0https://www.i= etf.org/rfcdiff?url2=3Ddraft-ietf-netmod-entity-06
>=C2=A0 =C2=A0 =C2=A0<https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-entity-06> >=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>> Please note that it m= ay take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0> >>>>>> until the htmlized ve= rsion and diff are available at
>=C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://tools.ietf.org>.
>=C2=A0 =C2=A0 =C2=A0> >>>>>>
>=C2=A0 =C2=A0 =C2=A0> >>>>>> Internet-Drafts are a= lso available by anonymous FTP at:
>=C2=A0 =C2=A0 =C2=A0> >>>>>> ftp://ftp.i= etf.org/internet-drafts/
>=C2=A0 =C2=A0 =C2=A0<ftp://ftp.ietf.org/internet-draf= ts/>
>=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> >>>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> >>>>>> ht= tps://www.ietf.org/mailman/listinfo/netmod
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/netmod>
>=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> >>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> >>>>> https:= //www.ietf.org/mailman/listinfo/netmod
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/netmod>
>=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> >>>> netmod@ietf.org <mailto:net= mod@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> >>>> https://ww= w.ietf.org/mailman/listinfo/netmod
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/netmod>
>=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> netmod@ietf= .org <mailto:netmod@ietf.org&= gt;
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailma= n/listinfo/netmod
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/netmod>
>
>=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<http://www.jacobs-university.de/
>=C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>>
>
>


--001a114d60420638170560a3ca4d-- From nobody Mon Dec 18 13:17:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101F312D947 for ; Mon, 18 Dec 2017 13:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[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 XbybKq1gqsYh for ; Mon, 18 Dec 2017 13:17:09 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 E57EF12D945 for ; Mon, 18 Dec 2017 13:17:08 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 9E7C6140641 for ; Mon, 18 Dec 2017 14:17:08 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id nZH41w0142SSUrH01ZH7yi; Mon, 18 Dec 2017 14:17:08 -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=ocR9PWop10UA:10 a=wU2YTnxGAAAA:8 a=WYlzy6alETi8PX4RoTkA:9 a=QEXdDO2ut3YA:10 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: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=Hrh29MeFr4nADfVccKBs+1zzUqt1tN9LzDUqfBdxqbA=; b=lbdP+p6QZYbPlaBTXdT3Wz5LyV DMnle72kUquX8C95pfnNDnfFEE76yQ4s8MEbsv0pt04UdwS7of+ExJAuxEjZpJ27xInsnn+YvQg4q amATWmHbsQS6kuEHwcH5rNBPh; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:52404 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eR2mW-0007lq-OP; Mon, 18 Dec 2017 14:17:04 -0700 To: Andy Bierman Cc: Juergen Schoenwaelder , Martin Bjorklund , draft-ietf-netmod-entity@ietf.org, NetMod WG References: <20171218200650.6bus7deydr3bxm2j@elstar.local> <34fba949-d502-38a0-00cb-49d1bba1d193@labn.net> <20171218.212201.175509717846279732.mbj@tail-f.com> <20171218205644.zp27kn6qm5rqhr77@elstar.local> From: Lou Berger Message-ID: Date: Mon, 18 Dec 2017 16:17:03 -0500 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 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: 1eR2mW-0007lq-OP 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]:52404 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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, 18 Dec 2017 21:17:10 -0000 On 12/18/2017 4:11 PM, Andy Bierman wrote: > > > On Mon, Dec 18, 2017 at 1:03 PM, Lou Berger > wrote: > > On 12/18/2017 04:01 PM, Andy Bierman wrote: > > > > > > On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder > > > > >> wrote: > > > >     On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote: > >     > > >     > Given the context (YANG module, and this WG), I think it > should be > >     > 6087bis (which is the same as 6087 in this respect). > > > >     Does RFC 6087 formally update RFC 3688? > > > > > > Not intentionally. > > The 3688 text  should probably be used instead of 6087bis. > > > yikes.  really? so you think rfc6087 and the netmod RFCs were wrong? > > > Not wrong, but the more generic text applies to all WGs, > not just NETMOD WG.  The YANG module contact info > has the WG details. Since the NETMOD WG is long-lived, > it may be better to list NETMOD WG.  It doesn't seem to matter > since this info is not in the registry anyway. > Sigh.  Sounds like a useless line.  I guess the most important thing on this inconsequential point is that we be consistent.  So, I guess this means another update to 6087bis, I know you have one in the works in any case.  How about publishing this change and other's that have been discussed on the list so that we can all see the current state.  I'll push submit on entity and we can always update it during IESG processing if needed... Thanks, Lou ... From nobody Mon Dec 18 13:19:03 2017 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 2A86212D951; Mon, 18 Dec 2017 13:18:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lou Berger To: X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, lberger@labn.net, iesg-secretary@ietf.org, netmod@ietf.org, Lou Berger Message-ID: <151363193816.13221.6807936254978583047.idtracker@ietfa.amsl.com> Date: Mon, 18 Dec 2017 13:18:58 -0800 Archived-At: Subject: [netmod] Publication has been requested for draft-ietf-netmod-entity-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: Mon, 18 Dec 2017 21:18:58 -0000 Lou Berger has requested publication of draft-ietf-netmod-entity-06 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ From nobody Mon Dec 18 18:32:52 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1211241FC for ; Mon, 18 Dec 2017 18:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 N8OPwP9R3gYZ for ; Mon, 18 Dec 2017 18:32:49 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 1003E124205 for ; Mon, 18 Dec 2017 18:32:48 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.58.28; From: "Susan Hares" To: "'Benoit Claise'" , "'NETMOD Working Group'" References: In-Reply-To: Date: Mon, 18 Dec 2017 21:32:42 -0500 Message-ID: <035b01d37871$a611d360$f2357a20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGgCDNaVhFeVYjvu0A7YA9MZi5oKLjp7PQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] Joel Jaeggli as a third NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 02:32:50 -0000 Joel: Thank you for helping out the netmod group! =20 Terry -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Friday, December 15, 2017 12:21 PM To: NETMOD Working Group Cc: Joel jaeggli Subject: [netmod] Joel Jaeggli as a third NETMOD co-chair Dear all, A lot is happening these days in the world of data modeling-driven = management at the IETF: NMDA architecture, NETCONF, RESTCONF NMDA-compliant YANG modules: some RFC bis modules but also new ones Guidelines: RFC6087bis and the tree diagram The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, = telemetry The interaction with routing, where many YANG modules come from. etc. There are a lot of dependencies between all these tasks, which must take = place in parallel, and, obviously, be completed ASAP. Kent and Lou have a lot on their shoulders these days. To help with the situation and proactively progress documents, I'm happy = to announce that Joel Jaeggli accepted to serve as a third NETMOD = co-chair. Thank you Joel. Please welcome Joel. Regards, Benoit _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Dec 18 19:46:28 2017 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 B2E9F124E15; Mon, 18 Dec 2017 19:46: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.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151365518668.7352.12068549749612249938@ietfa.amsl.com> Date: Mon, 18 Dec 2017 19:46:26 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-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: Tue, 19 Dec 2017 03:46:26 -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-15.txt Pages : 70 Date : 2017-12-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-15 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-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 Mon Dec 18 22:12:08 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3C4126D46 for ; Mon, 18 Dec 2017 22:12:07 -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 3S46_9q1sygh for ; Mon, 18 Dec 2017 22:12:04 -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 A67111205F0 for ; Mon, 18 Dec 2017 22:12:03 -0800 (PST) Received: from birdie2 (cst-prg-75-230.cust.vodafone.cz [46.135.75.230]) by mail.nic.cz (Postfix) with ESMTPSA id B849863AF3; Tue, 19 Dec 2017 07:12:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513663921; bh=So4Dlt6wLL84vURqx8ldGIJsjmA2etqK7nGdgGwTL2k=; h=From:To:Date; b=Epq7TW+867d6k9ZTDpaqOLs882IvA6gfeNeTIKihXg6DKktquPhm2nUKW2aOk6SXV w7OGZU9+Z9s96HsCMvYndtCs/pC/oOq+R/0+bAJ7ShS+cHyHs4amoWBOvmFJr6G7HD TQFi8ekoqNV9vKrGV/hT+pV8RIoDT78JcrmO/Vec= Message-ID: <1513663919.478.7.camel@nic.cz> From: Ladislav Lhotka To: Lou Berger , NETMOD WG Date: Tue, 19 Dec 2017 07:11:59 +0100 In-Reply-To: <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] 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, 19 Dec 2017 06:12:07 -0000 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. > > > 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 Dec 19 01:05:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA5C1205F0 for ; Tue, 19 Dec 2017 01:05:52 -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 2ac9Q99chNMH for ; Tue, 19 Dec 2017 01:05: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 60F691201F2 for ; Tue, 19 Dec 2017 01:05: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 348A969; Tue, 19 Dec 2017 10:05:44 +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 EifoZqaKku6p; Tue, 19 Dec 2017 10:05:41 +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, 19 Dec 2017 10:05:44 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2206020073; Tue, 19 Dec 2017 10:05:44 +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 u0wN7KBxdjdV; Tue, 19 Dec 2017 10:05:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB36020130; Tue, 19 Dec 2017 10:05:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F44741F20D6; Tue, 19 Dec 2017 10:05:43 +0100 (CET) Date: Tue, 19 Dec 2017 10:05:43 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: NETMOD WG Message-ID: <20171219090543.klkffqbdnfifznmt@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1513663919.478.7.camel@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: Tue, 19 Dec 2017 09:05:52 -0000 On Tue, Dec 19, 2017 at 07:11:59AM +0100, 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. > Lada, probably a stupid question (since I am not really familiar with the details of the mount work): What speaks against augmenting the yang library with a list of mount points and then mount point list elements can refer to the schema used at the mount point? /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 Dec 19 02:25:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5D51276AF for ; Tue, 19 Dec 2017 02:25: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 CyYozbq7oY2d for ; Tue, 19 Dec 2017 02:25: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 6D6FE126B71 for ; Tue, 19 Dec 2017 02:25:40 -0800 (PST) Received: from birdie2 (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id A862363D1A; Tue, 19 Dec 2017 11:25:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513679138; bh=9O38C9r9suoSSYxLQjDNGoZzykKEja1SSnthh0aw4X4=; h=From:To:Date; b=FNe1H6CkJWDlYd8vaiLXdOrMhFcpdkDDPle3UVEUIt4I7VOKf7aK8oy3Kj8iTOqwq 84P8GImc7lHyYpvmh+U03/sT2fJuEzcjc4qav4Pw2TLagGBYdMzddtwX150yPAX8EM JfqM2v6T9zfnoXo44Yu7tzHrpsgyG06pFC2h8YzQ= Message-ID: <1513679138.2479.12.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder Cc: NETMOD WG Date: Tue, 19 Dec 2017 11:25:38 +0100 In-Reply-To: <20171219090543.klkffqbdnfifznmt@elstar.local> References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <20171219090543.klkffqbdnfifznmt@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] 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, 19 Dec 2017 10:25:43 -0000 On Tue, 2017-12-19 at 10:05 +0100, Juergen Schoenwaelder wrote: > On Tue, Dec 19, 2017 at 07:11:59AM +0100, 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. > > > > Lada, > > probably a stupid question (since I am not really familiar with the > details of the mount work): What speaks against augmenting the yang > library with a list of mount points and then mount point list elements > can refer to the schema used at the mount point? Absolutely, that's exactly what IMO needs to be done. All schemas, both top- level and mounted, would then be contained in the YANG library's schema list. I think the most sensible approach is to first agree on the new schema of YANG library, and then define additional schema mount data as an augment. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 19 03:20:49 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3603112DA44 for ; Tue, 19 Dec 2017 03:20:47 -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 GWiTBDlR10GU for ; Tue, 19 Dec 2017 03:20:45 -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 34A2B127909 for ; Tue, 19 Dec 2017 03:20:45 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id B75CB1E0ADA for ; Tue, 19 Dec 2017 04:20:44 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id nnLg1w00i2SSUrH01nLjQT; Tue, 19 Dec 2017 04:20:44 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=WgAxfh4z8XSioJ7dM80A: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: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=bvB2LBVOXfPZ+wr1an2njFr0sAxu5zIYIKaskNizJiI=; b=RunIkSUcBvFOUpMUca5M/uCba8 zy0/YiGuYQsqKaPRpoeK9BU7GnxTRGzg4VZBkm8VQoHZcwpaa9vyEZYzT3aBPtGzB5T8TsqprBxX5 Kv6Jigm9mHMtwIkknKK2kTzLs; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:41811 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 1eRFwu-001QFT-KQ; Tue, 19 Dec 2017 04:20:40 -0700 From: Lou Berger To: Ladislav Lhotka , NETMOD WG Date: Tue, 19 Dec 2017 06:20:38 -0500 Message-ID: <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <1513663919.478.7.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> User-Agent: AquaMail/1.12.0-651 (build: 101200001) 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: 1eRFwu-001QFT-KQ 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]:41811 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, 19 Dec 2017 11:20:47 -0000 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. 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 Dec 19 03:23:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C31C12DA4D for ; Tue, 19 Dec 2017 03:23:17 -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 DGGUnR9IDKkl for ; Tue, 19 Dec 2017 03:23: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 0406A127909 for ; Tue, 19 Dec 2017 03:23:14 -0800 (PST) Received: from birdie2 (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 6CDFC63DF1; Tue, 19 Dec 2017 12:23:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513682591; bh=1cd8/GQ0NUhYPwNB56DYw6Ia0Rh5zNWHaKOAcB2P2ck=; h=From:To:Date; b=DoOXdU13oy7yl1VJCDt77vETf8ZsJv/Y0wxVeXpFXBitzmFu0F1hq48G7OE/A/DDM yau12L5sLJkvm1TzhfQvmPdGwBKqDjsOAyNk4yFI0v14XW8jKxuyiKJRUlSJmHmJic EYM68W8n+cJUWIfivf4RtMlYsuycviJi7jydKAvY= Message-ID: <1513682591.2479.20.camel@nic.cz> From: Ladislav Lhotka To: Lou Berger , NETMOD WG Date: Tue, 19 Dec 2017 12:23:11 +0100 In-Reply-To: <1606e810770.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> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] 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, 19 Dec 2017 11:23:17 -0000 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. 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 Dec 19 03:24:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A89127909 for ; Tue, 19 Dec 2017 03:24: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 (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 HdLdo11R9c2T for ; Tue, 19 Dec 2017 03:24:01 -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 5861612D95E for ; Tue, 19 Dec 2017 03:24:01 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 8A0B51407F7 for ; Tue, 19 Dec 2017 04:23:58 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id nnPv1w00K2SSUrH01nPyy9; Tue, 19 Dec 2017 04:23:58 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=ocR9PWop10UA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=NohVe43JZ_Yzo_tYT5MA:9 a=CjuIK1q_8ugA: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: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=BHYzn1jUvpEZgUMxrFnyMGAMcP/LgVxdfOPVquaTCtw=; b=XR/gfDTPXsvXEPpFxZXj6A6Mvt AsV6zbS/kUdMJHjmuO+F7i5UzmQByqEI5siUAr9Sgz7xQ+hoOXkSTCuHNAPZpiBIZMlz5wq/+xLh2 6kwqpYpMAEJxn30pEyJmRL5rI; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:41816 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 1eRG03-001Rhy-Au; Tue, 19 Dec 2017 04:23:55 -0700 From: Lou Berger To: Ladislav Lhotka , NETMOD WG Date: Tue, 19 Dec 2017 06:23:52 -0500 Message-ID: <1606e83fd40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <1606e810770.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> User-Agent: AquaMail/1.12.0-651 (build: 101200001) 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: 1eRG03-001Rhy-Au 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]:41816 X-Source-Auth: lberger@labn.net X-Email-Count: 8 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, 19 Dec 2017 11:24:03 -0000 Woops that should be rw... On December 19, 2017 6:21:22 AM 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. > > 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 >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Dec 19 03:44:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587A1127137 for ; Tue, 19 Dec 2017 03:44:06 -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 pllum4LNULD3 for ; Tue, 19 Dec 2017 03:44:04 -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 9515F12DA68 for ; Tue, 19 Dec 2017 03:44:04 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id EFD651E0747 for ; Tue, 19 Dec 2017 04:44:03 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id nnk01w00y2SSUrH01nk3mV; Tue, 19 Dec 2017 04:44:03 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=x8ps-i-sVOE9ehqSqU0A: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: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=wCi+/etyD6ugmNTZ9Fq1zeWpmBEZG9XGpWh5491gZUU=; b=pdiLHfJBy8WB48WAcDqqsAoF/K 6wWDlnnfVnx8I2vbUDt6smypH2FFGqBIkWV7hGyQjE7avMSGiSaTkbxUobQ1mmjZ5yLmiFuLalkd/ CaXAFY9gwQiiaqMsJBf4Dp2Y8; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:36086 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eRGJU-001b66-NL; Tue, 19 Dec 2017 04:44:00 -0700 To: Ladislav Lhotka , 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> From: Lou Berger Message-ID: Date: Tue, 19 Dec 2017 06:43:59 -0500 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: <1513682591.2479.20.camel@nic.cz> Content-Type: text/plain; charset=utf-8 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: 1eRGJU-001b66-NL 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]:36086 X-Source-Auth: lberger@labn.net X-Email-Count: 11 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, 19 Dec 2017 11:44:06 -0000 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,   the information in these modules should be retrieved by   clients from operational data stores using the appropriate   protocol operations. 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. 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 Dec 19 04:36:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271DB12778E for ; Tue, 19 Dec 2017 04:36:44 -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 5rDhxxMJjj6w for ; Tue, 19 Dec 2017 04:36:40 -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 6C533126CD6 for ; Tue, 19 Dec 2017 04:36:39 -0800 (PST) Received: from birdie2 (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id B6D6E63F11; Tue, 19 Dec 2017 13:36:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513686995; bh=spxePCIak9Sh1GvYoDa1DYkDFi2KmLZrFIDD8i7KKvE=; h=From:To:Date; b=qf5xUfxfPDyHFHp+T+XL4sXixWxlUGjFUIndtUae8zULoKNv3anc0e6pjvGiK0KbV r8fYZK3Bpm79zeOeQkxQTyjqMCra3W9kAfrGpROy45kHnzbmcGGfJmFVIxRMo8RrX+ vTBj4up1VaAYmttQx5DlVyibTySDPZFipQykQm9M= Message-ID: <1513686995.2479.41.camel@nic.cz> From: Ladislav Lhotka To: Lou Berger , NETMOD WG Date: Tue, 19 Dec 2017 13:36:35 +0100 In-Reply-To: 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> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] 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, 19 Dec 2017 12:36:44 -0000 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. 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. > 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. > > 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. 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 Dec 19 04:49:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03C012778E for ; Tue, 19 Dec 2017 04:49: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, 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 PE1tWRZPFd0c for ; Tue, 19 Dec 2017 04:49:15 -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 E8211126CD6 for ; Tue, 19 Dec 2017 04:49:14 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 569551E06F3 for ; Tue, 19 Dec 2017 05:49:14 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id nopA1w00P2SSUrH01opDb7; Tue, 19 Dec 2017 05:49:14 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=W96Dgh_eZOHAMPlv3xAA: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: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=RcY+YW69ba8nmUz6hbEo8o9YjDUg4MeA5RTjMujuU7g=; b=u+9/U3V4Jp3+EGky0xF8gY8O1C jNI6fuqTtLK31YFJnY0hSMpIyKFEi+E+xC2gDJLVgkyjmETiauQprXfv9uod5FUEcDmZiva4vojV9 yt0pRVpE5FQT8FcVPQxCQQ53c; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:39732 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eRHKY-0023Ot-M3; Tue, 19 Dec 2017 05:49:10 -0700 To: Ladislav Lhotka , 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> From: Lou Berger Message-ID: <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> Date: Tue, 19 Dec 2017 07:49:08 -0500 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: <1513686995.2479.41.camel@nic.cz> Content-Type: text/plain; charset=utf-8 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: 1eRHKY-0023Ot-M3 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]:39732 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, 19 Dec 2017 12:49:17 -0000 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/ - > > 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. > >> 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. > >> 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 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? 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 Dec 19 05:26:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4814A12AF84 for ; Tue, 19 Dec 2017 05:26: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 09m7GAaPaZkt for ; Tue, 19 Dec 2017 05:26: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 0CBF4129511 for ; Tue, 19 Dec 2017 05:26:50 -0800 (PST) Received: from birdie2 (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 3E93F63FD7; Tue, 19 Dec 2017 14:26:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513690008; bh=rFu5+SQU+h1VSqMsLim3yjXhxrQxzkkte+azX7Q5ipw=; h=From:To:Date; b=btAlAgtkKSilPr455XsccLcUKUGkZ3PeMOmG0KEmVMqlLglgelimX+oZH8H4fmZA1 GaTzUyt4339P60h4Cadr/Wg2zhnKYfwGTg8XOCmYuRHZT91R1jeRymkuV1ep5kuVnU TQ1G9IRNBKrCERfM5jTaadlCQsGiVY9qrD2hugXM= Message-ID: <1513690008.2479.70.camel@nic.cz> From: Ladislav Lhotka To: Lou Berger , NETMOD WG Date: Tue, 19 Dec 2017 14:26:48 +0100 In-Reply-To: <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@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> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] 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, 19 Dec 2017 13:26:53 -0000 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 Dec 19 06:32:34 2017 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 D9BD1126C25; Tue, 19 Dec 2017 06:32:32 -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.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151369395285.7379.11856961445178815340@ietfa.amsl.com> Date: Tue, 19 Dec 2017 06:32:32 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-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: Tue, 19 Dec 2017 14:32:33 -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-03.txt Pages : 12 Date : 2017-12-19 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-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 Tue Dec 19 06:36:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F549126CF6 for ; Tue, 19 Dec 2017 06:35: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 IDBb9ZETfe2t for ; Tue, 19 Dec 2017 06:35:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E811E1205F0 for ; Tue, 19 Dec 2017 06:35:57 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 08C861AE0351 for ; Tue, 19 Dec 2017 15:35:56 +0100 (CET) Date: Tue, 19 Dec 2017 15:34:38 +0100 (CET) Message-Id: <20171219.153438.411083654073015751.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151369395285.7379.11856961445178815340@ietfa.amsl.com> References: <151369395285.7379.11856961445178815340@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] I-D Action: draft-ietf-netmod-yang-tree-diagrams-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: Tue, 19 Dec 2017 14:35:59 -0000 Hi, This version changes the intended status to BCP, and adds the "-u" notation for non-expanded uses statements. We believe this draft is now ready for WGLC. [FYI - I have added an option --tree-no-expand-uses to pyang, which uses this new notation.] /martin 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 : YANG Tree Diagrams > Authors : Martin Bjorklund > Lou Berger > Filename : draft-ietf-netmod-yang-tree-diagrams-03.txt > Pages : 12 > Date : 2017-12-19 > > 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-03 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-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/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Dec 19 08:45:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6769812D838 for ; Tue, 19 Dec 2017 08:45:09 -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 JkRum2auO0Ys for ; Tue, 19 Dec 2017 08:45:07 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 AD97C12D82C for ; Tue, 19 Dec 2017 08:45:07 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id x7so5873160qkb.0 for ; Tue, 19 Dec 2017 08:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mVb1QwHI3Iv96wHcg02XJDO3vcrh+5Sa9nSyF+0Bn8Y=; b=ZQ15HB3klzN3jF35FJcd7xFucn9IOo19AqEiUNM+fXVu5JpCTsYdntOTMvrekykC0F cRyBWOiEB9koMQNvV1UPyu0tNjTBv4sKx5rNqKbz+bzJVTU6nKtM/gkTZdbwYGtKbXgW oi+P0A08VtsKy3hd9LuGQAC1MhNbPGvN/CMBAqzUVhQkJiiC9I5mQqWn8R6zT74Ro0wf Q/hGViqNm9or3bBOJe2du0wF5R4PZF9ZFPE8+ODA/57WtTXUJiR8KcAtys2ROFC9YhRS k4yR3k6jDOHjnI6YUL90Bv83sDjVZ4EiIhEr2lImnQDD/YRowheaYDH7Pr3uEyC2ZLJj 6KiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mVb1QwHI3Iv96wHcg02XJDO3vcrh+5Sa9nSyF+0Bn8Y=; b=ZZTiCWJlK9TAX28C5uGgmLfNeX3tdwjbMHXVMn8v2Y92nQUhyjQ7tnn4Eq6kBNaWhf dqFV0ASH5B6mPGTKnDxhgOG8usJL+hwdNYgSUTZGl+hbO1RDDaO2nb/3ZcuTYqTfXSYd Yg4YmZhnRr1fV8au1eF7OdIwCs1iigxc1hzzccAV/7QZhoYbPnKPccTroSr/oev5yBTM ZwWPv009Fn3MBAUDB6FcbNHhC4ABjzgnXIz01j1na8addcrtqkSU4RmBEfMs7kwmQQsF e+5rx38Q6nga4Ld4La8bY0oFUVrTm1Ere/po8+FxPneoPO/3LQwvZ2GhzpGR/zQC/ePD KQLA== X-Gm-Message-State: AKGB3mJlWAAvK1PeD8yz/O4EunkHiOpO4PLzlPkk2dEPlN/0b97AJcrH Hzj0Lbo/VS3i4KKfsVLZfcLK74HyLjom7Is7vZF5svoS X-Google-Smtp-Source: ACJfBoughzOLA53GhycBvBlf7qbH4C87oDAbzs7wlsxnhZ3wy/qs+kEcoUP2CvK7m23V1LnUxuqZ6Ktx6uTmm5V8JNo= X-Received: by 10.55.190.5 with SMTP id o5mr5881657qkf.241.1513701906529; Tue, 19 Dec 2017 08:45:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.4.27 with HTTP; Tue, 19 Dec 2017 08:45:06 -0800 (PST) From: Xufeng Liu Date: Tue, 19 Dec 2017 11:45:06 -0500 Message-ID: To: NETMOD WG Content-Type: multipart/alternative; boundary="94eb2c0430466f43490560b43074" Archived-At: Subject: [netmod] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 16:45:09 -0000 --94eb2c0430466f43490560b43074 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable During the discussions of TE tunnel and topology models, we have found that it is desirable to have the capability of augmenting a grouping. In our case, there are multiple technology specific models augmenting a base generic model. In the base model, some groupings are used multiple times, and each augmentation model needs to add more schema nodes to the grouping structure. For now, we have to specify an =E2=80=9Caugment=E2=80= =9D statement for each location where the grouping is used. Such an =E2=80=9Caugment=E2=80=9D= statement is repeated many times. It would be convenient and cleaner if we could augment the grouping. We=E2=80=99d like to hear opinions on the feasibility of such a capability. Thanks, - Xufeng --94eb2c0430466f43490560b43074 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

During the discussions of TE tunnel and topolo= gy models, we have found that it is desirable to have the capability of augmenting a grouping.

In our case, there are multiple technology spe= cific models augmenting a base generic model. In the base model, some groupings are used multiple times, and each augmentation model needs to add more schema nodes = to the grouping structure. For now, we have to specify an =E2=80=9Caugment=E2= =80=9D statement for each location where the grouping is used. Such an =E2=80=9Caugment=E2=80=9D= statement is repeated many times. It would be convenient and cleaner if we could augment= the grouping.

We=E2=80=99d like to hear opinions on the feas= ibility of such a capability.

Thanks,

- Xufeng


--94eb2c0430466f43490560b43074-- From nobody Tue Dec 19 09:04:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE6112D82C for ; Tue, 19 Dec 2017 09:04:53 -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 OIB28PYrRvdF for ; Tue, 19 Dec 2017 09:04:52 -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 01CF01241FC for ; Tue, 19 Dec 2017 09:04:52 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id C4A011E11C3 for ; Tue, 19 Dec 2017 09:34:41 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id nsad1w00T2SSUrH01sagaP; Tue, 19 Dec 2017 09:34:41 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=cN1bC_m4_iVUFw_kYoAA: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:Cc: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=4Yn1rMaU0l6rcnZ6NjNa85rmoRwH8F4n7UFIyJjuWJ0=; b=nXYEizQWPPBogmfGb69GF/OUb1 OMCW+unetCvSli1BVOcxmCzA+aL2JqMZ1cxsptAAElTX4CkxBVWJ2wJCNsMVgfWUNKo0EJ9dkXgis ji893VwnxwHiS2CjWt/FlYKzM; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47968 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eRKqj-003fbI-OD; Tue, 19 Dec 2017 09:34:37 -0700 To: netmod@ietf.org References: <151369395285.7379.11856961445178815340@ietfa.amsl.com> <20171219.153438.411083654073015751.mbj@tail-f.com> From: Lou Berger Message-ID: <28c0afd3-31c8-a428-5334-e7320bd61e00@labn.net> Date: Tue, 19 Dec 2017 11:34:34 -0500 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: <20171219.153438.411083654073015751.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: 1eRKqj-003fbI-OD 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]:47968 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-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: Tue, 19 Dec 2017 17:04:53 -0000 FYI - note this version does not include a reference to a wiki, as discussed at IETF100, based on the on-list discussion. Lou (as co-author) On 12/19/2017 9:34 AM, Martin Bjorklund wrote: > Hi, > > This version changes the intended status to BCP, and adds the "-u" > notation for non-expanded uses statements. > > We believe this draft is now ready for WGLC. > > [FYI - I have added an option --tree-no-expand-uses to pyang, which > uses this new notation.] > > > /martin > > > 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 : YANG Tree Diagrams >> Authors : Martin Bjorklund >> Lou Berger >> Filename : draft-ietf-netmod-yang-tree-diagrams-03.txt >> Pages : 12 >> Date : 2017-12-19 >> >> 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-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-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/ >> >> _______________________________________________ >> 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 Dec 19 10:07:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920C612D7F9 for ; Tue, 19 Dec 2017 10:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, 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 XyiW86YZLB8S for ; Tue, 19 Dec 2017 10:07:17 -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 2FC8812D7F8 for ; Tue, 19 Dec 2017 10:07:17 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id a90so11461074pfk.1 for ; Tue, 19 Dec 2017 10:07:17 -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=mnou3HD3gEhbANxpcTPDKq0gDrShw3sAK0I2xe6AFCQ=; b=FseJ6FIciwvh0tgbPkSS927lRshkCA94fSBIz6EIukoIgzokbL3NXkd8khxrS9bt5j bHPSXHN52gN4kgyY8dZJhW4Fdw9Q5PfHur48jjZZdrtBbWyvYrHFGZIcciG4vN+++NEk mBdrhOHxB3eonGVEaJZEFTUcgdTmjwZclwSKOy7Zdxoa3dAEGbbM3XcDwSDCHjBmB6OH UAgBDpnLG821FczXfbkSuri5trTexO/n8Si0lfSy7WblHy2pu1YJrdbTIk1wTvKJmq8N SbbCEH45c1CHR+IpxQPzeY1WhqCdFdZkHYFI+pYPDOvS/XDb+j4KvG8OroHkwxZ8NOZW XhCA== 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=mnou3HD3gEhbANxpcTPDKq0gDrShw3sAK0I2xe6AFCQ=; b=Dan7gP8jZPRNSS6HM2FNpHUd5PWyiuJftSOKIUvwVMZfXZzORyd/ueKGFavde9ZYJ2 XtR9kNv+frPwhAMbUIF/niBA8kNkMVRHW3MaYR0B5rcG8Y3Qn6qemW1FnKbC1UkGm5y4 0bsXN/dGi/AYZITuOQjBaF7MyXtEraJg35Z8pNQPOWyDwh6LvPGlG/cquq2qmGj5hQhW Cf1tDelzM2kZ7yAvIDg324g7S2rBzGRoKihjimOazmn0Uvrm2KU6cWT1xhI2pqTLm+0v 62c88+xtwpWR2vV1siclNXjwRZ/X4wAowskdNwtzA9KEIuBh59K3AaySzSDHM2yyp06b mN7g== X-Gm-Message-State: AKGB3mLyaEnzXvN/UHf+DwfIhUTMvdBDJqeJmRhU8dcSW++9s6EOqFEt f1XtEduS/ys2AXHssNrR5mvDEPYw X-Google-Smtp-Source: ACJfBouFpa+8cX1MSQJvhHsN1xUyX50BNNnrC1PGS59MxUirvMxbCK4oivO99zAzf95U8ieG5pV/bQ== X-Received: by 10.99.127.84 with SMTP id p20mr3789288pgn.208.1513706836558; Tue, 19 Dec 2017 10:07:16 -0800 (PST) Received: from [192.168.1.2] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id f79sm33095300pfd.45.2017.12.19.10.07.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 10:07:16 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-3A87BCA4-4791-4885-84F1-0D97F3C34FA9 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Tue, 19 Dec 2017 10:07:15 -0800 Cc: NETMOD WG Content-Transfer-Encoding: 7bit Message-Id: <9C5B716B-3590-4392-AE8F-47875F7FF1C2@gmail.com> References: To: Xufeng Liu Archived-At: Subject: Re: [netmod] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 18:07:18 -0000 --Apple-Mail-3A87BCA4-4791-4885-84F1-0D97F3C34FA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Very much needed capability=20 Regards, Jeff > On Dec 19, 2017, at 08:45, Xufeng Liu wrote: >=20 > During the discussions of TE tunnel and topology models, we have found tha= t it is desirable to have the capability of augmenting a grouping. >=20 > In our case, there are multiple technology specific models augmenting a ba= se generic model. In the base model, some groupings are used multiple times,= and each augmentation model needs to add more schema nodes to the grouping s= tructure. For now, we have to specify an =E2=80=9Caugment=E2=80=9D statement= for each location where the grouping is used. Such an =E2=80=9Caugment=E2=80= =9D statement is repeated many times. It would be convenient and cleaner if w= e could augment the grouping. >=20 > We=E2=80=99d like to hear opinions on the feasibility of such a capability= . >=20 > Thanks, >=20 > - Xufeng >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail-3A87BCA4-4791-4885-84F1-0D97F3C34FA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1
Very much needed capability 
Regards,
Jeff

During the discussions of TE tunnel and topolog= y models, we have found that it is desirable to have the capability of augmenting a grouping.

In our case, there are multiple technology spec= ific models augmenting a base generic model. In the base model, some groupings are used multiple times, and each augmentation model needs to add more schema nodes t= o the grouping structure. For now, we have to specify an =E2=80=9Caugment=E2=80= =9D statement for each location where the grouping is used. Such an =E2=80=9Caugment=E2=80=9D s= tatement is repeated many times. It would be convenient and cleaner if we could augment t= he grouping.

We=E2=80=99d like to hear opinions on the feasi= bility of such a capability.

Thanks,

- Xufeng


____________________= ___________________________
netmod mailing list
netmod@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org= /mailman/listinfo/netmod
= --Apple-Mail-3A87BCA4-4791-4885-84F1-0D97F3C34FA9-- From nobody Tue Dec 19 10:11:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEAD12D7E7 for ; Tue, 19 Dec 2017 10:11:00 -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 rpRBwUHzsJzx for ; Tue, 19 Dec 2017 10:10:58 -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 9F5E31243F3 for ; Tue, 19 Dec 2017 10:10:58 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4A450FF459C73 for ; Tue, 19 Dec 2017 18:10:55 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Dec 2017 18:10:56 +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, 19 Dec 2017 10:10:51 -0800 From: Alexander Clemm To: Xufeng Liu , NETMOD WG Thread-Topic: [netmod] Augmentation to Groupings Thread-Index: AQHTeOjLL9QEs1S4ZUun5Og6EQeTeKNK9tLA Date: Tue, 19 Dec 2017 18:10:50 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4C84@sjceml521-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.216.247] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4C84sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 18:11:00 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4C84sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBzdWNoIGEgY2FwYWJpbGl0eSBhcyB3ZWxsLiAgQXMg bWVudGlvbmVkLCBzcGVjaWZpY2FsbHkgd2hlbiBncm91cGluZ3MgYXJlIHVzZWQgaW4gbXVsdGlw bGUgcGxhY2VzLCBhdWdtZW50YXRpb24gYmVjb21lcyByZWFsbHkgdW53aWVsZHkgd2l0aG91dCBh biBvcHRpb24gdG8gc2ltcGx5IGF1Z21lbnQgdGhlIGdyb3VwaW5nIGluc3RlYWQuICBJdCBhbHNv IGdldHMgaGFyZGVyIHRvIHJlYWQ7IHRvIHNvbWUgZGVncmVlIGl0IG5lZ2F0ZXMgdGhlIGJlbmVm aXRzIGZyb20gbnRyb2R1Y2luZyBncm91cGluZ3MgaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQotLS0g QWxleA0KDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFh1ZmVuZyBMaXUNClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE5LCAyMDE3IDg6 NDUgQU0NClRvOiBORVRNT0QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFtuZXRtb2Rd IEF1Z21lbnRhdGlvbiB0byBHcm91cGluZ3MNCg0KDQpEdXJpbmcgdGhlIGRpc2N1c3Npb25zIG9m IFRFIHR1bm5lbCBhbmQgdG9wb2xvZ3kgbW9kZWxzLCB3ZSBoYXZlIGZvdW5kIHRoYXQgaXQgaXMg ZGVzaXJhYmxlIHRvIGhhdmUgdGhlIGNhcGFiaWxpdHkgb2YgYXVnbWVudGluZyBhIGdyb3VwaW5n Lg0KDQpJbiBvdXIgY2FzZSwgdGhlcmUgYXJlIG11bHRpcGxlIHRlY2hub2xvZ3kgc3BlY2lmaWMg bW9kZWxzIGF1Z21lbnRpbmcgYSBiYXNlIGdlbmVyaWMgbW9kZWwuIEluIHRoZSBiYXNlIG1vZGVs LCBzb21lIGdyb3VwaW5ncyBhcmUgdXNlZCBtdWx0aXBsZSB0aW1lcywgYW5kIGVhY2ggYXVnbWVu dGF0aW9uIG1vZGVsIG5lZWRzIHRvIGFkZCBtb3JlIHNjaGVtYSBub2RlcyB0byB0aGUgZ3JvdXBp bmcgc3RydWN0dXJlLiBGb3Igbm93LCB3ZSBoYXZlIHRvIHNwZWNpZnkgYW4g4oCcYXVnbWVudOKA nSBzdGF0ZW1lbnQgZm9yIGVhY2ggbG9jYXRpb24gd2hlcmUgdGhlIGdyb3VwaW5nIGlzIHVzZWQu IFN1Y2ggYW4g4oCcYXVnbWVudOKAnSBzdGF0ZW1lbnQgaXMgcmVwZWF0ZWQgbWFueSB0aW1lcy4g SXQgd291bGQgYmUgY29udmVuaWVudCBhbmQgY2xlYW5lciBpZiB3ZSBjb3VsZCBhdWdtZW50IHRo ZSBncm91cGluZy4NCg0KV2XigJlkIGxpa2UgdG8gaGVhciBvcGluaW9ucyBvbiB0aGUgZmVhc2li aWxpdHkgb2Ygc3VjaCBhIGNhcGFiaWxpdHkuDQoNClRoYW5rcywNCg0KLSBYdWZlbmcNCg0KDQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4C84sjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5nbWFpbC1tc29ub3Jt YWwsIGxpLmdtYWlsLW1zb25vcm1hbCwgZGl2LmdtYWlsLW1zb25vcm1hbA0KCXttc28tc3R5bGUt bmFtZTpnbWFpbC1tc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mIzQzOzENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SSB3b3VsZCBsaWtlIHRvIHNlZSBzdWNoIGEgY2FwYWJpbGl0eSBhcyB3ZWxsLiZuYnNwOyBBcyBt ZW50aW9uZWQsIHNwZWNpZmljYWxseSB3aGVuIGdyb3VwaW5ncyBhcmUgdXNlZCBpbiBtdWx0aXBs ZSBwbGFjZXMsIGF1Z21lbnRhdGlvbiBiZWNvbWVzIHJlYWxseSB1bndpZWxkeSB3aXRob3V0DQog YW4gb3B0aW9uIHRvIHNpbXBseSBhdWdtZW50IHRoZSBncm91cGluZyBpbnN0ZWFkLiZuYnNwOyBJ dCBhbHNvIGdldHMgaGFyZGVyIHRvIHJlYWQ7IHRvIHNvbWUgZGVncmVlIGl0IG5lZ2F0ZXMgdGhl IGJlbmVmaXRzIGZyb20gbnRyb2R1Y2luZyBncm91cGluZ3MgaW4gdGhlIGZpcnN0IHBsYWNlLiZu YnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxl eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5YdWZlbmcgTGl1PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERl Y2VtYmVyIDE5LCAyMDE3IDg6NDUgQU08YnI+DQo8Yj5Ubzo8L2I+IE5FVE1PRCBXRyAmbHQ7bmV0 bW9kQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbmV0bW9kXSBBdWdtZW50YXRp b24gdG8gR3JvdXBpbmdzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJnbWFpbC1tc29ub3JtYWwiPkR1cmluZyB0aGUgZGlzY3Vzc2lvbnMgb2YgVEUgdHVubmVsIGFu ZCB0b3BvbG9neSBtb2RlbHMsIHdlIGhhdmUgZm91bmQgdGhhdCBpdCBpcyBkZXNpcmFibGUgdG8g aGF2ZSB0aGUgY2FwYWJpbGl0eSBvZiBhdWdtZW50aW5nIGEgZ3JvdXBpbmcuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tc29ub3JtYWwiPkluIG91ciBjYXNlLCB0aGVyZSBhcmUg bXVsdGlwbGUgdGVjaG5vbG9neSBzcGVjaWZpYyBtb2RlbHMgYXVnbWVudGluZyBhIGJhc2UgZ2Vu ZXJpYyBtb2RlbC4gSW4gdGhlIGJhc2UgbW9kZWwsIHNvbWUgZ3JvdXBpbmdzIGFyZSB1c2VkIG11 bHRpcGxlIHRpbWVzLCBhbmQgZWFjaCBhdWdtZW50YXRpb24gbW9kZWwgbmVlZHMgdG8gYWRkIG1v cmUgc2NoZW1hIG5vZGVzIHRvIHRoZSBncm91cGluZyBzdHJ1Y3R1cmUuDQogRm9yIG5vdywgd2Ug aGF2ZSB0byBzcGVjaWZ5IGFuIOKAnGF1Z21lbnTigJ0gc3RhdGVtZW50IGZvciBlYWNoIGxvY2F0 aW9uIHdoZXJlIHRoZSBncm91cGluZyBpcyB1c2VkLiBTdWNoIGFuIOKAnGF1Z21lbnTigJ0gc3Rh dGVtZW50IGlzIHJlcGVhdGVkIG1hbnkgdGltZXMuIEl0IHdvdWxkIGJlIGNvbnZlbmllbnQgYW5k IGNsZWFuZXIgaWYgd2UgY291bGQgYXVnbWVudCB0aGUgZ3JvdXBpbmcuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iZ21haWwtbXNvbm9ybWFsIj5XZeKAmWQgbGlrZSB0byBoZWFyIG9waW5pb25z IG9uIHRoZSBmZWFzaWJpbGl0eSBvZiBzdWNoIGEgY2FwYWJpbGl0eS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tc29ub3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1tc29ub3JtYWwiPi0gWHVmZW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i Z21haWwtbXNvbm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4C84sjceml521mbxchi_-- From nobody Tue Dec 19 10:39:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC13126CBF; Tue, 19 Dec 2017 10:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.802 X-Spam-Level: X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, 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 vJ3VEJg0Ewt3; Tue, 19 Dec 2017 10:39:53 -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 3883D1200F1; Tue, 19 Dec 2017 10:39:50 -0800 (PST) Received: from mbp-4.local (c-73-96-132-59.hsd1.or.comcast.net [73.96.132.59]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vBJIdnK3003101 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 19 Dec 2017 18:39:49 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-96-132-59.hsd1.or.comcast.net [73.96.132.59] claimed to be mbp-4.local To: draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org From: joel jaeggli Message-ID: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com> Date: Tue, 19 Dec 2017 10:39:43 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g0pA33j53cuFjgbIBK4FxRoTURksD31lS" Archived-At: Subject: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 18:39:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g0pA33j53cuFjgbIBK4FxRoTURksD31lS Content-Type: multipart/mixed; boundary="KMooGcgAPiaUt2VfPao1OAsQxvhoX5rKN"; protected-headers="v1" From: joel jaeggli To: draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org Message-ID: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com> Subject: draft-ietf-netmod-yang-tree-diagrams - IPR verfication request --KMooGcgAPiaUt2VfPao1OAsQxvhoX5rKN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Authors, Contributors, WG, As part of the preparation for WG Last Call: 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. --KMooGcgAPiaUt2VfPao1OAsQxvhoX5rKN-- --g0pA33j53cuFjgbIBK4FxRoTURksD31lS 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 iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCWjlc7wAKCRDwADWrtn9W sqZZAJ9yVF+56QD4LUSmVi1ktXcDS9KtMwCfbKjLht87t0wqFJNcIQeZ3t3ech8= =NZI8 -----END PGP SIGNATURE----- --g0pA33j53cuFjgbIBK4FxRoTURksD31lS-- From nobody Tue Dec 19 11:15:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2D31200F1 for ; Tue, 19 Dec 2017 11:15:33 -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 yNd1nWE7gxuv for ; Tue, 19 Dec 2017 11:15: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 84FC4126DED for ; Tue, 19 Dec 2017 11:15: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 5694169; Tue, 19 Dec 2017 20:15: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 YVtN79A_WAU7; Tue, 19 Dec 2017 20:15:27 +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, 19 Dec 2017 20:15:30 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E5F220130; Tue, 19 Dec 2017 20:15: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 QzOcZAaymu0F; Tue, 19 Dec 2017 20:15:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 489E520073; Tue, 19 Dec 2017 20:15:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 150C941F395D; Tue, 19 Dec 2017 20:15:28 +0100 (CET) Date: Tue, 19 Dec 2017 20:15:28 +0100 From: Juergen Schoenwaelder To: Xufeng Liu Cc: NETMOD WG Message-ID: <20171219191528.2snk3ahnipxcojtb@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Xufeng Liu , NETMOD WG 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] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 19:15:34 -0000 The current approach may be verbose but it protects users of groupings from unwanted and uncontrolled side effects. Augmenting a grouping as suggested affects _all_ uses of a grouping; this can be tricky in situations where groupings are widely used. /js On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu wrote: > During the discussions of TE tunnel and topology models, we have found that > it is desirable to have the capability of augmenting a grouping. > > In our case, there are multiple technology specific models augmenting a > base generic model. In the base model, some groupings are used multiple > times, and each augmentation model needs to add more schema nodes to the > grouping structure. For now, we have to specify an “augment” statement for > each location where the grouping is used. Such an “augment” statement is > repeated many times. It would be convenient and cleaner if we could augment > the grouping. > > We’d like to hear opinions on the feasibility of such a capability. > > Thanks, > > - Xufeng > _______________________________________________ > 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 Tue Dec 19 11:51:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807B512D7FB for ; Tue, 19 Dec 2017 11:51:12 -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 s8GJQL_xfcyt for ; Tue, 19 Dec 2017 11:51:10 -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 B58731200F1 for ; Tue, 19 Dec 2017 11:51:10 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 24E46BC5070D7; Tue, 19 Dec 2017 19:51:06 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Dec 2017 19:51:08 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML703-CHM.china.huawei.com ([169.254.5.4]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 11:51:06 -0800 From: Alexander Clemm To: Juergen Schoenwaelder , Xufeng Liu CC: NETMOD WG Thread-Topic: [netmod] Augmentation to Groupings Thread-Index: AQHTeOjLL9QEs1S4ZUun5Og6EQeTeKNLj8AA//+BZlA= Date: Tue, 19 Dec 2017 19:51:05 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4D37@sjceml521-mbx.china.huawei.com> References: <20171219191528.2snk3ahnipxcojtb@elstar.local> In-Reply-To: <20171219191528.2snk3ahnipxcojtb@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.216.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 19:51:12 -0000 SU1ITyBpdCB3b3VsZCBiZSB3b3J0aCBhIHRyeS4gIElmIHlvdSB3YW50ZWQgdG8gb25seSBhdWdt ZW50IF9zb21lXyB1c2VzIG9mIGEgZ3JvdXBpbmcsIHlvdSBjb3VsZCBzdGlsbCBkbyB0aGUgc2Ft ZSBhcyB0b2RheS4gIEFsc28sIEkgd291bGQgZXhwZWN0IGF1Z21lbnRhdGlvbnMgdG8gb25seSBh ZmZlY3Qgc2VydmVycyB0aGF0IHN1cHBvcnQgdGhlIG1vZHVsZSBkZWZpbmluZyB0aGUgYXVnbWVu dGF0aW9uLiAgSWYgdmVyYm9zaXR5IHdlcmUgbm90IGFuIGlzc3VlLCB3aHkgd2VyZSBncm91cGlu Z3MgaW50cm9kdWNlZCBpbiB0aGUgZmlyc3QgcGxhY2U/DQotLS0gQWxleA0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVlcmdlbg0KPiBTY2hvZW53YWVsZGVyDQo+IFNlbnQ6 IFR1ZXNkYXksIERlY2VtYmVyIDE5LCAyMDE3IDExOjE1IEFNDQo+IFRvOiBYdWZlbmcgTGl1IDx4 dWZlbmcubGl1LmlldGZAZ21haWwuY29tPg0KPiBDYzogTkVUTU9EIFdHIDxuZXRtb2RAaWV0Zi5v cmc+DQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBBdWdtZW50YXRpb24gdG8gR3JvdXBpbmdzDQo+ IA0KPiBUaGUgY3VycmVudCBhcHByb2FjaCBtYXkgYmUgdmVyYm9zZSBidXQgaXQgcHJvdGVjdHMg dXNlcnMgb2YgZ3JvdXBpbmdzIGZyb20NCj4gdW53YW50ZWQgYW5kIHVuY29udHJvbGxlZCBzaWRl IGVmZmVjdHMuIEF1Z21lbnRpbmcgYSBncm91cGluZyBhcw0KPiBzdWdnZXN0ZWQgYWZmZWN0cyBf YWxsXyB1c2VzIG9mIGEgZ3JvdXBpbmc7IHRoaXMgY2FuIGJlIHRyaWNreSBpbiBzaXR1YXRpb25z DQo+IHdoZXJlIGdyb3VwaW5ncyBhcmUgd2lkZWx5IHVzZWQuDQo+IA0KPiAvanMNCj4gDQo+IE9u IFR1ZSwgRGVjIDE5LCAyMDE3IGF0IDExOjQ1OjA2QU0gLTA1MDAsIFh1ZmVuZyBMaXUgd3JvdGU6 DQo+ID4gRHVyaW5nIHRoZSBkaXNjdXNzaW9ucyBvZiBURSB0dW5uZWwgYW5kIHRvcG9sb2d5IG1v ZGVscywgd2UgaGF2ZSBmb3VuZA0KPiA+IHRoYXQgaXQgaXMgZGVzaXJhYmxlIHRvIGhhdmUgdGhl IGNhcGFiaWxpdHkgb2YgYXVnbWVudGluZyBhIGdyb3VwaW5nLg0KPiA+DQo+ID4gSW4gb3VyIGNh c2UsIHRoZXJlIGFyZSBtdWx0aXBsZSB0ZWNobm9sb2d5IHNwZWNpZmljIG1vZGVscyBhdWdtZW50 aW5nDQo+ID4gYSBiYXNlIGdlbmVyaWMgbW9kZWwuIEluIHRoZSBiYXNlIG1vZGVsLCBzb21lIGdy b3VwaW5ncyBhcmUgdXNlZA0KPiA+IG11bHRpcGxlIHRpbWVzLCBhbmQgZWFjaCBhdWdtZW50YXRp b24gbW9kZWwgbmVlZHMgdG8gYWRkIG1vcmUgc2NoZW1hDQo+ID4gbm9kZXMgdG8gdGhlIGdyb3Vw aW5nIHN0cnVjdHVyZS4gRm9yIG5vdywgd2UgaGF2ZSB0byBzcGVjaWZ5IGFuDQo+ID4g4oCcYXVn bWVudOKAnSBzdGF0ZW1lbnQgZm9yIGVhY2ggbG9jYXRpb24gd2hlcmUgdGhlIGdyb3VwaW5nIGlz IHVzZWQuIFN1Y2gNCj4gPiBhbiDigJxhdWdtZW504oCdIHN0YXRlbWVudCBpcyByZXBlYXRlZCBt YW55IHRpbWVzLiBJdCB3b3VsZCBiZSBjb252ZW5pZW50DQo+ID4gYW5kIGNsZWFuZXIgaWYgd2Ug Y291bGQgYXVnbWVudCB0aGUgZ3JvdXBpbmcuDQo+ID4NCj4gPiBXZeKAmWQgbGlrZSB0byBoZWFy IG9waW5pb25zIG9uIHRoZSBmZWFzaWJpbGl0eSBvZiBzdWNoIGEgY2FwYWJpbGl0eS4NCj4gPg0K PiA+IFRoYW5rcywNCj4gPg0KPiA+IC0gWHVmZW5nDQo+IA0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0K PiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kDQo+IA0KPiANCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAg ICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAw IDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBG YXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJz aXR5LmRlLz4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Dec 19 12:00:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35D912E8A3 for ; Tue, 19 Dec 2017 12:00:38 -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 3d5VLFKN6oPy for ; Tue, 19 Dec 2017 12:00:37 -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 DA1AF12E87F for ; Tue, 19 Dec 2017 12:00:32 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id w196so3574875lff.5 for ; Tue, 19 Dec 2017 12:00: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 :cc; bh=w0u48oxMSzZUcgoGnJFWh6muaele0cdXy+sYUWpPYgE=; b=SvcHuI1iDVApjGbX49DI1WC7N13KnUVco7nRkhMuJ+vS6VCTYcXRAsDSerc6yKaFvz EVC4vwP9pnJx29hh16uxxLhYARUNDtK5fnI0I/d2O0P8ZUBgWSVmhgOt8n10JzM9h5zt b7aSiMrldBH4ij9P7fKW/LlGvQnWDHKuNQXUIJ+vGTT1hhBGgPiG1eHxtbwu5uSvbrjI Usdq/bjQzNXZsy2N11t4bsS0sb0SWY9bEnIHNHEtcsTNRqzmUPQyl8Np44xjy2yd5qus IYVofgewvsZLPV8aPcZH4WABvp48teoCDocxFmoo5CX6wdqrQxh16QW8VvdDamNLN6jY 2+xA== 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=w0u48oxMSzZUcgoGnJFWh6muaele0cdXy+sYUWpPYgE=; b=LzvQjQMR9yYLTCR3NRDjB0DsV6ycS+Wl94sWt5xdU+8KncGumrAI2Bm/zbaOKvGCSa SVHeSOzgzEousn7yJRwkVr5pzYgDK5QM9p7Pr/wVXxx9/YfdNAvcngyRm9vwEVNz6Vqq 3+bXIFaGesu4DeoeCR0PkZud9+fKRQLT0H/ePUNQN5KXQrg9T30Di5SpZn2y5kuIGKMY jPZM5SI5kWOk33hnJqTic3T8oYP88vknDBov9m0Fdakv0Sq0gsofQC0/+2PcyX0U1Sgn 9615vftRGfCwt3/HKaMcq0XA9o5zYEsPvJgFnkEBcto+XeCMocnFi7gUuHNjd8JHW2iJ L5Lg== X-Gm-Message-State: AKGB3mJxzjDQyNqdVdwturKfXc46jaKmmcqC97hKmstDreX2ui1b70A1 SD8n33zYjac+4CoEbSsDM+TYVOGYBXgsUlpKyn6mEg== X-Google-Smtp-Source: ACJfBouW/yat0OWpeSlfymtPTVnGMSEdiR7BOKC5qu8jpRzYzsD8TO54yrbRaNbvKBlHOWuNGYrgr0QnVKpCkuSp0iQ= X-Received: by 10.46.99.131 with SMTP id s3mr2806141lje.143.1513713631058; Tue, 19 Dec 2017 12:00:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Tue, 19 Dec 2017 12:00:30 -0800 (PST) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4D37@sjceml521-mbx.china.huawei.com> References: <20171219191528.2snk3ahnipxcojtb@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4D37@sjceml521-mbx.china.huawei.com> From: Andy Bierman Date: Tue, 19 Dec 2017 12:00:30 -0800 Message-ID: To: Alexander Clemm Cc: Juergen Schoenwaelder , Xufeng Liu , NETMOD WG Content-Type: multipart/alternative; boundary="94eb2c0734364571350560b6eb2d" Archived-At: Subject: Re: [netmod] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 20:00:39 -0000 --94eb2c0734364571350560b6eb2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I do not want YANG to have augment for groupings because there is no way to control all possible uses-stmts and make sure the augmentation is only used where intended. This seems no different than OO code. A new class name is required for the derived class. In YANG a new grouping is required and specific uses-stmts have to be updated to use the new grouping. Andy On Tue, Dec 19, 2017 at 11:51 AM, Alexander Clemm < alexander.clemm@huawei.com> wrote: > IMHO it would be worth a try. If you wanted to only augment _some_ uses > of a grouping, you could still do the same as today. Also, I would expec= t > augmentations to only affect servers that support the module defining the > augmentation. If verbosity were not an issue, why were groupings > introduced in the first place? > --- Alex > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, December 19, 2017 11:15 AM > > To: Xufeng Liu > > Cc: NETMOD WG > > Subject: Re: [netmod] Augmentation to Groupings > > > > The current approach may be verbose but it protects users of groupings > from > > unwanted and uncontrolled side effects. Augmenting a grouping as > > suggested affects _all_ uses of a grouping; this can be tricky in > situations > > where groupings are widely used. > > > > /js > > > > On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu wrote: > > > During the discussions of TE tunnel and topology models, we have foun= d > > > that it is desirable to have the capability of augmenting a grouping. > > > > > > In our case, there are multiple technology specific models augmenting > > > a base generic model. In the base model, some groupings are used > > > multiple times, and each augmentation model needs to add more schema > > > nodes to the grouping structure. For now, we have to specify an > > > =E2=80=9Caugment=E2=80=9D statement for each location where the group= ing is used. Such > > > an =E2=80=9Caugment=E2=80=9D statement is repeated many times. It wou= ld be convenient > > > and cleaner if we could augment the grouping. > > > > > > We=E2=80=99d like to hear opinions on the feasibility of such a capab= ility. > > > > > > Thanks, > > > > > > - Xufeng > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 > --94eb2c0734364571350560b6eb2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I do not want YANG to have augment = for groupings because there is
no way to control all possible use= s-stmts and make sure the augmentation
is only used where intende= d.=C2=A0 This seems no different than OO code.
A new class name i= s required for the derived class. In YANG a new grouping
is requi= red and specific uses-stmts have to be updated to use the new grouping.


Andy


On Tue, Dec 19, 2017 at 11:51 AM, Al= exander Clemm <alexander.clemm@huawei.com> wrote:
IMHO it would be worth a try.=C2=A0 If you= wanted to only augment _some_ uses of a grouping, you could still do the s= ame as today.=C2=A0 Also, I would expect augmentations to only affect serve= rs that support the module defining the augmentation.=C2=A0 If verbosity we= re not an issue, why were groupings introduced in the first place?
--- Alex

> -----Original Message-----
> From: netmod [mailto:netmod= -bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, December 19, 2017 11:15 AM
> To: Xufeng Liu <xufeng= .liu.ietf@gmail.com>
> Cc: NETMOD WG <netmod@ietf.org>
> Subject: Re: [netmod] Augmentation to Groupings
>
> The current approach may be verbose but it protects users of groupings= from
> unwanted and uncontrolled side effects. Augmenting a grouping as
> suggested affects _all_ uses of a grouping; this can be tricky in situ= ations
> where groupings are widely used.
>
> /js
>
> On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu wrote:
> > During the discussions of TE tunnel and topology models, we have = found
> > that it is desirable to have the capability of augmenting a group= ing.
> >
> > In our case, there are multiple technology specific models augmen= ting
> > a base generic model. In the base model, some groupings are used<= br> > > multiple times, and each augmentation model needs to add more sch= ema
> > nodes to the grouping structure. For now, we have to specify an > > =E2=80=9Caugment=E2=80=9D statement for each location where the g= rouping is used. Such
> > an =E2=80=9Caugment=E2=80=9D statement is repeated many times. It= would be convenient
> > and cleaner if we could augment the grouping.
> >
> > We=E2=80=99d like to hear opinions on the feasibility of such a c= apability.
> >
> > Thanks,
> >
> > - Xufeng
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
>
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus 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/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--94eb2c0734364571350560b6eb2d-- From nobody Tue Dec 19 12:12:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912C2128954; Tue, 19 Dec 2017 12:12: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 M0tlUdOJd6R6; Tue, 19 Dec 2017 12:12: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 32F1B126BF6; Tue, 19 Dec 2017 12:12:55 -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 0D2511AE0351; Tue, 19 Dec 2017 21:12:54 +0100 (CET) Date: Tue, 19 Dec 2017 21:12:53 +0100 (CET) Message-Id: <20171219.211253.1296903692364332567.mbj@tail-f.com> To: joelja@bogus.com Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com> References: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@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=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request, draft-ietf-netmod-yang-tree-diagrams - IPR verfication request X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 20:12:56 -0000 joel jaeggli wrote: > Authors, Contributors, WG, > > As part of the preparation for WG Last Call: > > 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 > > 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 Tue Dec 19 12:16:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CA61201F2 for ; Tue, 19 Dec 2017 12:16:52 -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 pC2kYHOnJPto for ; Tue, 19 Dec 2017 12:16: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 5FB7D1270A0 for ; Tue, 19 Dec 2017 12:16:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2D307673; Tue, 19 Dec 2017 21:16: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 CHW0A3kYxmsa; Tue, 19 Dec 2017 21:16:46 +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, 19 Dec 2017 21:16:48 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E057020131; Tue, 19 Dec 2017 21:16:48 +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 yQfqSaMMJsqf; Tue, 19 Dec 2017 21:16:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DF8E20130; Tue, 19 Dec 2017 21:16:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9306341F3BAF; Tue, 19 Dec 2017 21:16:47 +0100 (CET) Date: Tue, 19 Dec 2017 21:16:47 +0100 From: Juergen Schoenwaelder To: Alexander Clemm Cc: Xufeng Liu , NETMOD WG Message-ID: <20171219201647.pgywfiws5avnyaul@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alexander Clemm , Xufeng Liu , NETMOD WG References: <20171219191528.2snk3ahnipxcojtb@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4D37@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: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4D37@sjceml521-mbx.china.huawei.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Dec 2017 20:16:52 -0000 The question is not why we have groupings, the question is why augmentations are restricted to schema node identifiers. I provided an answer for the later, namely explicit control of augmentation effects. It is of course OK to disagree with the design. I am just trying to explain that this was an explicit design decision when YANG was designed. /js On Tue, Dec 19, 2017 at 07:51:05PM +0000, Alexander Clemm wrote: > IMHO it would be worth a try. If you wanted to only augment _some_ uses of a grouping, you could still do the same as today. Also, I would expect augmentations to only affect servers that support the module defining the augmentation. If verbosity were not an issue, why were groupings introduced in the first place? > --- Alex > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, December 19, 2017 11:15 AM > > To: Xufeng Liu > > Cc: NETMOD WG > > Subject: Re: [netmod] Augmentation to Groupings > > > > The current approach may be verbose but it protects users of groupings from > > unwanted and uncontrolled side effects. Augmenting a grouping as > > suggested affects _all_ uses of a grouping; this can be tricky in situations > > where groupings are widely used. > > > > /js > > > > On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu wrote: > > > During the discussions of TE tunnel and topology models, we have found > > > that it is desirable to have the capability of augmenting a grouping. > > > > > > In our case, there are multiple technology specific models augmenting > > > a base generic model. In the base model, some groupings are used > > > multiple times, and each augmentation model needs to add more schema > > > nodes to the grouping structure. For now, we have to specify an > > > “augment” statement for each location where the grouping is used. Such > > > an “augment” statement is repeated many times. It would be convenient > > > and cleaner if we could augment the grouping. > > > > > > We’d like to hear opinions on the feasibility of such a capability. > > > > > > Thanks, > > > > > > - Xufeng > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 Tue Dec 19 12:25:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97155126BF6; Tue, 19 Dec 2017 12:25:17 -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 mbfspLCarjUj; Tue, 19 Dec 2017 12:25: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 C8DF01201F2; Tue, 19 Dec 2017 12:25: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 6C9011AE0351; Tue, 19 Dec 2017 21:25:14 +0100 (CET) Date: Tue, 19 Dec 2017 21:25:14 +0100 (CET) Message-Id: <20171219.212514.769253397796153677.mbj@tail-f.com> To: andy@yumaworks.com Cc: lberger@labn.net, netmod-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <80a900b3-716a-b11f-3472-7cae57662ba4@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] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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, 19 Dec 2017 20:25:17 -0000 Hi Andy, Andy Bierman wrote: > Hi, > > I have reviewed draft-07 and my previous comments about NMDA have been > addressed. > > This might be the most important sentence in the draft: > > sec. 5.3 > > The datastore schema for MUST be a superset of the > combined datastore schema used in all configuration datastores except > that YANG nodes supported in a configuration datastore MAY be omitted > from if a server is not able to accurately report them. > > The MUST implies that there is no need to design a YANG library that can > support > an implementation that violates this MUST (i.e., 1 schema tree for the > super-set) > > The MAY is troublesome because it completely contradicts the conformance > expressed > in each YANG module supported by the server. Any data node without any > if-feature-stmts is mandatory to implement. This is required for transition purposes; a server that wants to implement should not have to implement all modules at once (as applied config). > What about config=false subtrees within a config=true subtree? > Can they be omitted from as well, or does the draft just > intend to > omit the operational value of config=true nodes? Should be specific. The text says "nodes supported in a configuration datastore MAY be omitted from ". So it is implicit that it only applies to config true nodes (since config false cannot be supported in a config ds). How about: OLD: The datastore schema for MUST be a superset of the combined datastore schema used in all configuration datastores except that YANG nodes supported in a configuration datastore MAY be omitted from if a server is not able to accurately report them. NEW: The datastore schema for MUST be a superset of the combined datastore schema used in all configuration datastores except that YANG "config true" nodes supported in a configuration datastore MAY be omitted from if a server is not able to accurately report them. > Perhaps this draft does not need the MAY half of the sentence at all. > The YANG library can specify that it is for conformance-reporting, not > conformance-defining. I think we should keep the MAY, since the YANG library has to be designed to support this case. /martin > > > > > Andy > > > On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger wrote: > > > All, > > > > This starts a second working group last call on > > draft-ietf-netmod-revised-datastores. > > > > As this is a 2nd LC that is focused on changes since the last LC, it > > closes in *one* week. The working group last call ends on December 11. > > Please send your comments to the netmod mailing list. > > > > At this point, we're most interested in verifying that previous comments > > are addressed since the last call on the -04 rev of the draft was held. > > > > A summary of changes can be found at > > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4 > > > > A diff can be found at > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod- > > revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt > > > > Comments along the of: I have reviewed this version of the document and it > > addresses my previous comments would be particularly helpful. > > > > Thank you, > > Netmod Chairs > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Tue Dec 19 12:31:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CEB12D837; Tue, 19 Dec 2017 12:31:03 -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 X9q84_ow3ATv; Tue, 19 Dec 2017 12:31:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DD0EC1277BB; Tue, 19 Dec 2017 12:31:01 -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 257331AE0351; Tue, 19 Dec 2017 21:31:01 +0100 (CET) Date: Tue, 19 Dec 2017 21:31:01 +0100 (CET) Message-Id: <20171219.213101.692193824403742919.mbj@tail-f.com> To: lberger@labn.net Cc: draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org, netmod-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@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] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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, 19 Dec 2017 20:31:04 -0000 Hi Lou, Lou Berger wrote: > Hi, > These comments are based on my Shepherd review of this document and > should be addressed as part of addressing any LC comments: > > 1) Considering the recent discussion on Library made me consider the > general case of a module that is composed entirely of operational state. > I think this case is subject to interpretation and therefore needs to > be explicitly covered. For example section 5.3 states: > > The datastore schema for MUST be a superset of the > combined datastore schema used in all configuration datastores except > that YANG nodes supported in a configuration datastore MAY be omitted > from if a server is not able to accurately report them. > > This could be read that a module that an operational state MUST be > present (but presumably empty>?) in some other DS to be present in > operational. I don't believe this is your intent, but it should be > explicitly covered for the benefit of future readers. Ok. How about we add to the paragraph above a sentence: If a module does not contain any configuration data then it MAY be omitted from the schema for the configuration datastores. > I suspect that > this also should translate to an explicit case in section 6.1 as well. I don't understand why that would be neeed. > 2) The abstract needs to mention that it updates RFC7950 (per idnits) Ok. > 3) A minor point, the document uses the terms boot and reboot. I > suspect that these terms are intended to cover any full or partial, > e.g., protocol, restart operation supported on a system - which may not > include a full boot. I think the document needs to be clear on this > point. Perhaps just add a definition, or note that full and partial > restart operations are included when the document refers to boot and reboot. RFC 6241 uses the same terms, so using them is at least consistent with that document. I'm not sure I think they need to be defined in this document. /martin > > Thank you, > Lou > (As Shepherd) > > On 12/04/2017 09:35 AM, Lou Berger wrote: > > All, > > > > This starts a second working group last call on > > draft-ietf-netmod-revised-datastores. > > > > As this is a 2nd LC that is focused on changes since the last LC, it closes in *one* week. The working group last call ends on December 11. Please send your comments to the netmod mailing list. > > > > At this point, we're most interested in verifying that previous comments are addressed since the last call on the -04 rev of the draft was held. > > > > A summary of changes can be found at > > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4 > > > > A diff can be found at > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt > > > > Comments along the of: I have reviewed this version of the document and it addresses my previous comments would be particularly helpful. > > > > Thank you, > > Netmod Chairs > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > From nobody Tue Dec 19 12:41:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3FA12D854 for ; Tue, 19 Dec 2017 12:41:34 -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 k6ycutI8GvjU for ; Tue, 19 Dec 2017 12:41:32 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 A522E12D84B for ; Tue, 19 Dec 2017 12:41:31 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id g80so17168832lfg.0 for ; Tue, 19 Dec 2017 12:41:31 -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=mS5B4NAivJ6AhZ/rS0gUSMBbAUir9mz9AZQQPIGc+A4=; b=pc8+X9ShOHp9TKkk2iv0z52v8v4MKBzM8AbtpdLyOh20zcgAKpDGPv1NajSEcDZ1BH AUjRSVgMOCC/o05v6xO5shxkGVciNeJxXePVioyqkC0oDmq0rXbmGqyzyVEGzS6tr/tA 57n/L6OFOu1nr3RuMBvwnXvOhLzWFbvBoTM4pnA/1F32XaW0H5Jtnoi8S51GaZK4gGPe q7ozweXIDUTCrFXidNBWt4iXekMcGI5Q96urVeMtQZoB7qORV5zHeMDQtk0MsqfKFJb3 nC/5CghSZbCFfIldh0ukCQH/iEUD/FCvIg5pHQjAnrkpPf7+TxFLNfsHUcULPccEJai+ SRGw== 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=mS5B4NAivJ6AhZ/rS0gUSMBbAUir9mz9AZQQPIGc+A4=; b=e1u4Wr0zwznq8dOkHSwzKYYNGXyC+TROPz/zi9sFpFSFDUpcf03mEmYxYh3NU794sX 9wdkZGQ95CLRpbOlQ4w6bQxVTC1D4thdGsFNsta4ULWtHrwSXVR47so1cKntlaPzs+Y7 kTTVsrV0V2No/mlLsTk5b6BJ2OdQ50RactHiufZwv6bJ4KosgaWE9DbENJvfeo4wwGHJ SZatfOd14gCBddKTI5SrTGcQwgfXPLoXCyJIt06KGQPguznNij9HL8TGicdJkEunXoTp LpNytA+bEJO/4GK41NH4lJnH0abVsvnIoDtSZ9QvMg+qjkpBt+If+vkxZ1vdrC/hUgGH WxKw== X-Gm-Message-State: AKGB3mKl52QdOMgbjLpIBZYk4BVho6QXsfCoW8MfqVxYN2q4dII6QQDb UKbfxrV2t7bueM/MC7uQns0hpgaj5gGCnd+BqvnmQQ== X-Google-Smtp-Source: ACJfBosoyOd3/A3lwB86LvmhajjXfj/DPKzCp0e9/m7CHrMxNGMDyiiZ8cuKK/X4bhyPq8SSFCZMjYDfgI9KTlai9Ks= X-Received: by 10.25.242.65 with SMTP id d1mr3144910lfk.18.1513716089829; Tue, 19 Dec 2017 12:41:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Tue, 19 Dec 2017 12:41:28 -0800 (PST) In-Reply-To: <20171219.213101.692193824403742919.mbj@tail-f.com> References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> <20171219.213101.692193824403742919.mbj@tail-f.com> From: Andy Bierman Date: Tue, 19 Dec 2017 12:41:28 -0800 Message-ID: To: Martin Bjorklund Cc: Berger Lou , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org, NetMod WG Content-Type: multipart/alternative; boundary="94eb2c1cc12ed3788b0560b77db6" Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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, 19 Dec 2017 20:41:34 -0000 --94eb2c1cc12ed3788b0560b77db6 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund wrote: > Hi Lou, > > Lou Berger wrote: > > Hi, > > These comments are based on my Shepherd review of this document and > > should be addressed as part of addressing any LC comments: > > > > 1) Considering the recent discussion on Library made me consider the > > general case of a module that is composed entirely of operational state. > > I think this case is subject to interpretation and therefore needs to > > be explicitly covered. For example section 5.3 states: > > > > The datastore schema for MUST be a superset of the > > combined datastore schema used in all configuration datastores except > > that YANG nodes supported in a configuration datastore MAY be omitted > > from if a server is not able to accurately report them. > > > > This could be read that a module that an operational state MUST be > > present (but presumably empty>?) in some other DS to be present in > > operational. I don't believe this is your intent, but it should be > > explicitly covered for the benefit of future readers. > > Ok. How about we add to the paragraph above a sentence: > > If a module does not contain any configuration data then it MAY be > omitted from the schema for the configuration datastores. > > I liked the old YANG library better. It allows a client to create of a list of all the modules/revisions/features/deviations that will be needed to match the schema tree used by the server. The compiler does not care if it is looking for a typedef vs. a data node. The YANG library details help the compiler find the correct definitions. Consider iana-crypt-hash that has only typedefs and features. Leaving this module out of the library can cause problems for a client. > I suspect that > > this also should translate to an explicit case in section 6.1 as well. > > I don't understand why that would be neeed. > > > 2) The abstract needs to mention that it updates RFC7950 (per idnits) > > Ok. > > > 3) A minor point, the document uses the terms boot and reboot. I > > suspect that these terms are intended to cover any full or partial, > > e.g., protocol, restart operation supported on a system - which may not > > include a full boot. I think the document needs to be clear on this > > point. Perhaps just add a definition, or note that full and partial > > restart operations are included when the document refers to boot and > reboot. > > RFC 6241 uses the same terms, so using them is at least consistent > with that document. I'm not sure I think they need to be defined in > this document. > > > /martin > > > > Andy > > > > > Thank you, > > Lou > > (As Shepherd) > > > > On 12/04/2017 09:35 AM, Lou Berger wrote: > > > All, > > > > > > This starts a second working group last call on > > > draft-ietf-netmod-revised-datastores. > > > > > > As this is a 2nd LC that is focused on changes since the last LC, it > closes in *one* week. The working group last call ends on December 11. > Please send your comments to the netmod mailing list. > > > > > > At this point, we're most interested in verifying that previous > comments are addressed since the last call on the -04 rev of the draft was > held. > > > > > > A summary of changes can be found at > > > https://mailarchive.ietf.org/arch/msg/netmod/ > DWtD12bGkBZabEygRfiwZfcnUU4 > > > > > > A diff can be found at > > > https://tools.ietf.org/rfcdiff?difftype=--hwdiff& > url1=draft-ietf-netmod-revised-datastores-04.txt&url2=draft-ietf-netmod- > revised-datastores-07.txt > > > > > > Comments along the of: I have reviewed this version of the document > and it addresses my previous comments would be particularly helpful. > > > > > > Thank you, > > > Netmod 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 > --94eb2c1cc12ed3788b0560b77db6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Hi Lou,

Lou Berger <lberger@labn.net>= wrote:
> Hi,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0These comments are based on my Shepherd revi= ew of this document and
> should be addressed as part of addressing any LC comments:
>
> 1) Considering the recent discussion on Library made me consider the > general case of a module that is composed entirely of operational stat= e.
>=C2=A0 I think this case is subject to interpretation and therefore nee= ds to
> be explicitly covered.=C2=A0 For example section 5.3 states:
>
>=C2=A0 =C2=A0 The datastore schema for <operational> MUST be a su= perset of the
>=C2=A0 =C2=A0 combined datastore schema used in all configuration datas= tores except
>=C2=A0 =C2=A0 that YANG nodes supported in a configuration datastore MA= Y be omitted
>=C2=A0 =C2=A0 from <operational> if a server is not able to accur= ately report them.
>
> This could be read that a module that an operational state MUST be
> present (but presumably empty>?) in some other DS to be present in<= br> > operational.=C2=A0 I don't believe this is your intent, but it sho= uld be
> explicitly covered for the benefit of future readers.

Ok.=C2=A0 How about we add to the paragraph above a sentence:

=C2=A0 =C2=A0 If a module does not contain any configuration data then it M= AY be
=C2=A0 =C2=A0 omitted from the schema for the configuration datastores.



I liked the old YANG li= brary better.
It allows a client to create of a list of all the m= odules/revisions/features/deviations
that will be needed to match= the schema tree used by the server.
The compiler does not care i= f it is looking for a typedef vs. a data node.
The YANG library d= etails help the compiler find the correct definitions.

Consider iana-crypt-hash that has only typedefs and features.
Leaving this module out of the library can cause problems for a clien= t.



> I suspect that
> this also should translate to an explicit case in section 6.1 as well.=

I don't understand why that would be neeed.

> 2) The abstract needs to mention that it updates RFC7950 (per idnits)<= br>
Ok.

> 3) A minor point, the document uses the terms boot and reboot.=C2=A0 I=
> suspect that these terms are intended to cover any full or partial, > e.g., protocol, restart operation supported on a system - which may no= t
> include a full boot.=C2=A0 I think the document needs to be clear on t= his
> point.=C2=A0 Perhaps just add a definition, or note that full and part= ial
> restart operations are included when the document refers to boot and r= eboot.

RFC 6241 uses the same terms, so using them is at least consistent
with that document.=C2=A0 I'm not sure I think they need to be defined = in
this document.


/martin





Andy
=C2=A0

>
> Thank you,
> Lou
> (As Shepherd)
>
> On 12/04/2017 09:35 AM, Lou Berger wrote:
> > All,
> >
> > This starts a second working group last call on
> > draft-ietf-netmod-revised-datastores.
> >
> > As this is a 2nd LC that is focused on changes since the last LC,= it closes in *one* week. The working group last call ends on December 11. = Please send your comments to the netmod mailing list.
> >
> > At this point, we're most interested in verifying that previo= us comments are addressed since the last call on the -04 rev of the draft w= as held.
> >
> > A summary of changes can be found at
> > https://mailarchiv= e.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4
> >
> > A diff can be found at
> > https= ://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url1=3Ddraft-ie= tf-netmod-revised-datastores-04.txt&url2=3Ddraft-ietf-netmod-= revised-datastores-07.txt
> >
> > Comments along the of: I have reviewed this version of the docume= nt and it addresses my previous comments would be particularly helpful.
> >
> > Thank you,
> > Netmod Chairs
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
> >
>

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

--94eb2c1cc12ed3788b0560b77db6-- From nobody Tue Dec 19 12:54:29 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE071270A0; Tue, 19 Dec 2017 12:54:27 -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 j7rmpkyHAqcz; Tue, 19 Dec 2017 12:54: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 5EA6E1205D3; Tue, 19 Dec 2017 12:54: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 25C35673; Tue, 19 Dec 2017 21:54: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 O8aBte0mGbwX; Tue, 19 Dec 2017 21:54: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; Tue, 19 Dec 2017 21:54:23 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF89720130; Tue, 19 Dec 2017 21:54: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 lcNYMCgrqnHU; Tue, 19 Dec 2017 21:54:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3CCE420073; Tue, 19 Dec 2017 21:54:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 157F441F3C8F; Tue, 19 Dec 2017 21:54:22 +0100 (CET) Date: Tue, 19 Dec 2017 21:54:22 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , Berger Lou , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org, NetMod WG Message-ID: <20171219205422.okuxkyj7egpoqo6t@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Martin Bjorklund , Berger Lou , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org, NetMod WG References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> <20171219.213101.692193824403742919.mbj@tail-f.com> 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] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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, 19 Dec 2017 20:54:28 -0000 On Tue, Dec 19, 2017 at 12:41:28PM -0800, Andy Bierman wrote: > On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund wrote: > > > Hi Lou, > > > > Lou Berger wrote: > > > Hi, > > > These comments are based on my Shepherd review of this document and > > > should be addressed as part of addressing any LC comments: > > > > > > 1) Considering the recent discussion on Library made me consider the > > > general case of a module that is composed entirely of operational state. > > > I think this case is subject to interpretation and therefore needs to > > > be explicitly covered. For example section 5.3 states: > > > > > > The datastore schema for MUST be a superset of the > > > combined datastore schema used in all configuration datastores except > > > that YANG nodes supported in a configuration datastore MAY be omitted > > > from if a server is not able to accurately report them. > > > > > > This could be read that a module that an operational state MUST be > > > present (but presumably empty>?) in some other DS to be present in > > > operational. I don't believe this is your intent, but it should be > > > explicitly covered for the benefit of future readers. > > > > Ok. How about we add to the paragraph above a sentence: > > > > If a module does not contain any configuration data then it MAY be > > omitted from the schema for the configuration datastores. > > I liked the old YANG library better. > It allows a client to create of a list of all the > modules/revisions/features/deviations > that will be needed to match the schema tree used by the server. > The compiler does not care if it is looking for a typedef vs. a data node. > The YANG library details help the compiler find the correct definitions. > > Consider iana-crypt-hash that has only typedefs and features. > Leaving this module out of the library can cause problems for a client. > I think this is not the intention. If a module is needed to satisfy imports, it has to be listed as part of the schema. So perhaps this is better? If a module does not contain any configuration data and it is not needed to satisfy any imports, then it MAY be omitted from the schema for the configuration datastores. /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 Dec 19 14:41:10 2017 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 9DDED1242F5; Tue, 19 Dec 2017 14:41:08 -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.68.0 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, joelja@bogus.com, Joel Jaeggli , iesg-secretary@ietf.org, netmod@ietf.org Message-ID: <151372326863.2601.9239617995535444828.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 14:41:08 -0800 Archived-At: Subject: [netmod] Publication has been requested for 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: Tue, 19 Dec 2017 22:41:09 -0000 Joel Jaeggli has requested publication of draft-ietf-netmod-rfc7223bis-01 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ From nobody Tue Dec 19 14:41:42 2017 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 A67AC1242F5; Tue, 19 Dec 2017 14:41:41 -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.68.0 Auto-Submitted: auto-generated Precedence: bulk Cc: netmod-chairs@ietf.org, joelja@bogus.com, Joel Jaeggli , iesg-secretary@ietf.org, netmod@ietf.org Message-ID: <151372330167.2661.14503720405097136651.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 14:41:41 -0800 Archived-At: Subject: [netmod] Publication has been requested for 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, 19 Dec 2017 22:41:42 -0000 Joel Jaeggli has requested publication of draft-ietf-netmod-rfc7277bis-01 as Proposed Standard on behalf of the NETMOD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ From nobody Tue Dec 19 15:03:01 2017 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 EE2DA12D77C; Tue, 19 Dec 2017 15:02:58 -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.0 Auto-Submitted: auto-generated Precedence: bulk CC: netmod-chairs@ietf.org, Joel Jaeggli , netmod@ietf.org, draft-ietf-netmod-rfc7277bis@ietf.org, joelja@bogus.com, bclaise@cisco.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151372457896.2735.18267966998763040173.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 15:02:58 -0800 Archived-At: Subject: [netmod] Last Call: (A YANG Data Model for IP Management) 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, 19 Dec 2017 23:02:59 -0000 The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Data Model for IP 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-09. 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 management of IP implementations. The data model includes configuration and system state. This document obsoletes RFC 7277. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Dec 19 15:04:02 2017 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 320A01242F5; Tue, 19 Dec 2017 15:04:01 -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.0 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-rfc7223bis@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: <151372464119.2629.2533582056677096366.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 15:04:01 -0800 Archived-At: Subject: [netmod] Last Call: (A YANG Data Model for Interface Management) 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, 19 Dec 2017 23:04:01 -0000 The IESG has received a request from the Network Modeling WG (netmod) to consider the following document: - 'A YANG Data Model for Interface 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-09. 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 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Dec 20 00:28:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0270F126DFF; Wed, 20 Dec 2017 00:28:46 -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 MC6dPowil7KE; Wed, 20 Dec 2017 00:28:44 -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 CBF1E1200C1; Wed, 20 Dec 2017 00:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2552; q=dns/txt; s=iport; t=1513758524; x=1514968124; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=KCs9DpnojoDrzhFL/KqCHw/EFJ9ZcK3pyPyCjMregAY=; b=T5cFym3LsXL3HPXM0pySXzm2f8jv2YT/djLRBRMFKPd/mnizunkGClc4 zL6BW+gPB4RP9/g0U5IUsCNgkouosFfuzAxpKcYOBO0c0Q2vpgQB0atq6 YCYiZwfrq6TL/dyAI/ZrN9C5dZwmzVzkJWprKg+dC1KPz5kHHWq5R8dP+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQBZHjpa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUYJ4QGixWPaAwnmTkKhTsChVQUAQEBAQEBAQEBayiFJAEFIxV?= =?us-ascii?q?RCxgCAiYCAlcGAQwGAgEBiiekNYInhBcBhloBAQEBAQEBAQIBAQEBAQEigQ+CX?= =?us-ascii?q?4NogWkpC4J4gzCBWIMsgmMBBKNDlS6CFooBJIc7jnWIBIE7NiKBTzIaCBsVPII?= =?us-ascii?q?pglMdGYETATpBN4o3AQEB?= X-IronPort-AV: E=Sophos;i="5.45,431,1508803200"; d="scan'208";a="1041976" 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; 20 Dec 2017 08:28:41 +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 vBK8SfQ1006612; Wed, 20 Dec 2017 08:28:41 GMT To: Andy Bierman , Martin Bjorklund , Berger Lou , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org, NetMod WG References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> <20171219.213101.692193824403742919.mbj@tail-f.com> <20171219205422.okuxkyj7egpoqo6t@elstar.local> From: Robert Wilton Message-ID: Date: Wed, 20 Dec 2017 08:28:41 +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: <20171219205422.okuxkyj7egpoqo6t@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Wed, 20 Dec 2017 08:28:46 -0000 On 19/12/2017 20:54, Juergen Schoenwaelder wrote: > On Tue, Dec 19, 2017 at 12:41:28PM -0800, Andy Bierman wrote: >> On Tue, Dec 19, 2017 at 12:31 PM, Martin Bjorklund wrote: >> >>> Hi Lou, >>> >>> Lou Berger wrote: >>>> Hi, >>>> These comments are based on my Shepherd review of this document and >>>> should be addressed as part of addressing any LC comments: >>>> >>>> 1) Considering the recent discussion on Library made me consider the >>>> general case of a module that is composed entirely of operational state. >>>> I think this case is subject to interpretation and therefore needs to >>>> be explicitly covered. For example section 5.3 states: >>>> >>>> The datastore schema for MUST be a superset of the >>>> combined datastore schema used in all configuration datastores except >>>> that YANG nodes supported in a configuration datastore MAY be omitted >>>> from if a server is not able to accurately report them. >>>> >>>> This could be read that a module that an operational state MUST be >>>> present (but presumably empty>?) in some other DS to be present in >>>> operational. I don't believe this is your intent, but it should be >>>> explicitly covered for the benefit of future readers. >>> Ok. How about we add to the paragraph above a sentence: >>> >>> If a module does not contain any configuration data then it MAY be >>> omitted from the schema for the configuration datastores. >> I liked the old YANG library better. >> It allows a client to create of a list of all the >> modules/revisions/features/deviations >> that will be needed to match the schema tree used by the server. >> The compiler does not care if it is looking for a typedef vs. a data node. >> The YANG library details help the compiler find the correct definitions. >> >> Consider iana-crypt-hash that has only typedefs and features. >> Leaving this module out of the library can cause problems for a client. >> > I think this is not the intention. If a module is needed to satisfy > imports, it has to be listed as part of the schema. So perhaps this is > better? > > If a module does not contain any configuration data and it is not > needed to satisfy any imports, then it MAY be omitted from the > schema for the configuration datastores. One minor tweak, I think that "configuration" would be better than "configuration data" for consistency reasons. Thanks, Rob > > /js > From nobody Wed Dec 20 02:21:47 2017 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 D560B1200F3; Wed, 20 Dec 2017 02:21:41 -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.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151376530180.2739.207042237963738855@ietfa.amsl.com> Date: Wed, 20 Dec 2017 02:21:41 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-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: Wed, 20 Dec 2017 10:21:42 -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-08.txt Pages : 38 Date : 2017-12-20 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-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 Wed Dec 20 02:23:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F983126C22 for ; Wed, 20 Dec 2017 02:23:13 -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 08HUR4lUNQUm for ; Wed, 20 Dec 2017 02:23:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A1A7F1200F3 for ; Wed, 20 Dec 2017 02:23:11 -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 E23621AE0388 for ; Wed, 20 Dec 2017 11:23:10 +0100 (CET) Date: Wed, 20 Dec 2017 11:23:10 +0100 (CET) Message-Id: <20171220.112310.1199256299838110805.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <151376530180.2739.207042237963738855@ietfa.amsl.com> References: <151376530180.2739.207042237963738855@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] I-D Action: draft-ietf-netmod-revised-datastores-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, 20 Dec 2017 10:23:13 -0000 Hi, This version addresses the WGLC comments from Andy and Lou, as discussed on the list. /martin 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 Management Datastore Architecture > Authors : Martin Bjorklund > Juergen Schoenwaelder > Phil Shafer > Kent Watsen > Robert Wilton > Filename : draft-ietf-netmod-revised-datastores-08.txt > Pages : 38 > Date : 2017-12-20 > > 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-08 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-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/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Dec 20 03:11:06 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DC512421A for ; Wed, 20 Dec 2017 03:11:05 -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 LGtZuiChoNa2 for ; Wed, 20 Dec 2017 03:11: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 D43FE1200F3 for ; Wed, 20 Dec 2017 03:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7958; q=dns/txt; s=iport; t=1513768263; x=1514977863; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=JTGxfyr2013rln9OzXqJucOmguIzipFmchmncCPav9w=; b=eAMQywV26ovcd/u1F948au4iTx0Tkp7F+hqhtuD/a7hZhaIjEAotvrPF EGZ1c/gQZMZS1qF7Jdbofy2G5GPDeNgT+JRLjxV10xoAIlHnD1buPnukS 3JAqNfBgk64kUexEugmZeEBroh8Q4TWBHDFqY9r0/FNi5ODC96g2cBiOf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgCcQzpa/xbLJq1bGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQkdCeEBosVoXKFZIIBCiWFFgKFVBUBAQEBAQEBAQFrKIUkBiNmTQI?= =?us-ascii?q?CVwYNCAEBFooREKRngicmikYBAQEBAQEBAwEBAQEBAQEcBYN/g2iBaSmGMgGBN?= =?us-ascii?q?oNOgmMFo0SIAI0ugheKASSHO40dgVmIBYE7NSOBTzIaCBsVgmaCUxyBaEA3AYp?= =?us-ascii?q?lAQEB?= X-IronPort-AV: E=Sophos;i="5.45,431,1508803200"; d="scan'208,217";a="992307" 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; 20 Dec 2017 11:11:00 +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 vBKBB0H4013838 for ; Wed, 20 Dec 2017 11:11:00 GMT References: From: Benoit Claise To: NETMOD Working Group X-Forwarded-Message-Id: Message-ID: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com> Date: Wed, 20 Dec 2017 12:11:00 +0100 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="------------9C44FAAECD77F072EF713322" Content-Language: en-US Archived-At: Subject: [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, 20 Dec 2017 11:11:05 -0000 This is a multi-part message in MIME format. --------------9C44FAAECD77F072EF713322 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, Here is my AD review of draft-ietf-netmod-entity-06. Note that if you post the new version soon (before the end of this week), I could start the IETF last call, and the draft could be on Jan 11th IESG telechat. - I don't believe that the RFC 2119 keywords are right on the following sentences (SHOULD => should): o The hardware data model SHOULD be suitable for new implementations to use as is. o The hardware data model defined in this document can be implemented on a system that also implements ENTITY-MIB, thus the mapping between the hardware data model and ENTITY-MIB SHOULD be clear. - 1.2. Tree Diagrams Tree diagrams used in this document follow the notation defined in [I-D.ietf-netmod-yang-tree-diagrams ]. You could remove the above and add the reference to section 3. This document defines the YANG module "ietf-hardware", which has the following structure [I-D.ietf-netmod-yang-tree-diagrams ]: Martin, be consistent with all your YANG modules. So keep your temp versions of RFC7223bis and RFC7277bis consistent as well. - 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. In the reverse direction, entPhysicalMfgName is read-only in RFC6933, while it's "config true" in draft-ietf-netmod-entity You should mention these ro/rw differences with RFC6933. There might be other differences. - UUIDorZero entPhysicalUUID OBJECT-TYPE SYNTAX UUIDorZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains identification information about the physical entity. The object contains a Universally Unique Identifier, the syntax of this object must conform toRFC 4122, Section 4.1 . A zero-length octet string is returned if no UUID information is known." The YANG module is: leaf uuid { type yang:uuid; config false; description "A Universally Unique Identifier of the component."; reference "RFC 6933 : entPhysicalUUID"; } Where: typedef uuid { type string { pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; } description "A Universally Unique IDentifier in the string representation defined in RFC 4122. The canonical representation uses lowercase characters. The following is an example of a UUID in string representation: f81d4fae-7dec-11d0-a765-00a0c91e6bf6 "; reference "RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace"; } Again a difference between the MIB and YANG module to mention in the document? Regards, Benoit (as OPS AD) --------------9C44FAAECD77F072EF713322 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Here is my AD review of draft-ietf-netmod-entity-06.
Note that if you post the new version soon (before the end of this week), I could start the IETF last call, and the draft could be on Jan 11th IESG telechat.

- I don't believe that the RFC 2119 keywords are right on the following sentences (SHOULD => should):

   o  The hardware data model SHOULD be suitable for new implementations
      to use as is.

   o  The hardware data model defined in this document can be
      implemented on a system that also implements ENTITY-MIB, thus the
      mapping between the hardware data model and ENTITY-MIB SHOULD be
      clear.

-

1.2.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [I-D.ietf-netmod-yang-tree-diagrams].
You could remove the above and add the reference to section 3. 
   This document defines the YANG module "ietf-hardware", which has the
   following structure [I-D.ietf-netmod-yang-tree-diagrams]:
Martin, be consistent with all your YANG modules. So keep your temp versions of RFC7223bis and RFC7277bis consistent as well.
- 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.
In the reverse direction, entPhysicalMfgName is read-only in RFC6933, while it's "config true" in draft-ietf-netmod-entity
You should mention these ro/rw differences with RFC6933.
There might be other differences. 

- 
UUIDorZero

entPhysicalUUID OBJECT-TYPE
    SYNTAX      UUIDorZero
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "This object contains identification information
            about the physical entity.  The object contains a
            Universally Unique Identifier, the syntax of this object
            must conform to RFC 4122, Section 4.1.

            A zero-length octet string is returned if no UUID
            information is known."


The YANG module is:

         leaf uuid {
           type yang:uuid;
           config false;
           description
             "A Universally Unique Identifier of the component.";
           reference "RFC 6933: entPhysicalUUID";
         }


Where:

 typedef uuid {
    type string {
      pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
            + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
    }
    description
     "A Universally Unique IDentifier in the string representation
      defined in RFC 4122.  The canonical representation uses
      lowercase characters.

      The following is an example of a UUID in string representation:
      f81d4fae-7dec-11d0-a765-00a0c91e6bf6
      ";
    reference
     "RFC 4122: A Universally Unique IDentifier (UUID) URN
                Namespace";
  }

Again a difference between the MIB and YANG module to mention in the document?


Regards, Benoit (as OPS AD)

 
--------------9C44FAAECD77F072EF713322-- From nobody Wed Dec 20 03:42:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D4412D890 for ; Wed, 20 Dec 2017 03:42: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=unavailable 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 ANGbG2D3dgv8 for ; Wed, 20 Dec 2017 03:42: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 DBDE2126B71 for ; Wed, 20 Dec 2017 03:42:03 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id AB3291E1C12 for ; Wed, 20 Dec 2017 04:25:11 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id oBR71w00u2SSUrH01BRAZl; Wed, 20 Dec 2017 04:25:11 -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=kj9zAlcOel0A:10 a=ocR9PWop10UA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=KpH9rkeAy9x1duHln4YA:9 a=CjuIK1q_8ugA: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=T+yNKIVumY0j+sxHKvXF5z91lY5Jb5r4Bc83YttrhHE=; b=TUvkT6ViYwkHhE+SBcT9ey9jc+ vy2+rIF6vnMN1QkZtfDXuuaeI4WNY8lS+lnyUgf6VoPIvyefS95rGt4QoFF7aZRWZQLrpDosPnPef Jx9VauI7VDgkojKsj8Ap5/JhW; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47366 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 1eRcUl-002xGQ-Nr; Wed, 20 Dec 2017 04:25:07 -0700 From: Lou Berger To: Martin Bjorklund CC: , , Date: Wed, 20 Dec 2017 06:25:04 -0500 Message-ID: <16073ab7280.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20171219.213101.692193824403742919.mbj@tail-f.com> References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> <20171219.213101.692193824403742919.mbj@tail-f.com> User-Agent: AquaMail/1.12.0-651 (build: 101200001) 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: 1eRcUl-002xGQ-Nr 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]:47366 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Wed, 20 Dec 2017 11:42:05 -0000 On December 19, 2017 3:31:34 PM Martin Bjorklund wrote: > Hi Lou, > > Lou Berger wrote: >> Hi, ... > >> 3) A minor point, the document uses the terms boot and reboot. I >> suspect that these terms are intended to cover any full or partial, >> e.g., protocol, restart operation supported on a system - which may not >> include a full boot. I think the document needs to be clear on this >> point. Perhaps just add a definition, or note that full and partial >> restart operations are included when the document refers to boot and reboot. > > RFC 6241 uses the same terms, so using them is at least consistent > with that document. Umm, so are pre-NMDA datastores. > I'm not sure I think they need to be defined in > this document. If the text above is accurate, I think something along its lined along its lined should be added. If not accurate, then I think you have a new point to clarify... Lou > > > /martin > > From nobody Wed Dec 20 04:06:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6031276AF; Wed, 20 Dec 2017 04:06: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, 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 ph0iUy3tC0vK; Wed, 20 Dec 2017 04:06:30 -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 0829012741D; Wed, 20 Dec 2017 04:06: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 2CE62F4C; Wed, 20 Dec 2017 13:06:28 +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 LibHUK4vS0PT; Wed, 20 Dec 2017 13:06:27 +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, 20 Dec 2017 13:06:28 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19A8820130; Wed, 20 Dec 2017 13:06:28 +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 AvPgp1JjQ44Z; Wed, 20 Dec 2017 13:06:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 588F220073; Wed, 20 Dec 2017 13:06:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3D70641F4A70; Wed, 20 Dec 2017 13:06:27 +0100 (CET) Date: Wed, 20 Dec 2017 13:06:27 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Martin Bjorklund , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org Message-ID: <20171220120627.kl2h6l3n73bc3n5h@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> <20171219.213101.692193824403742919.mbj@tail-f.com> <16073ab7280.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16073ab7280.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Wed, 20 Dec 2017 12:06:32 -0000 On Wed, Dec 20, 2017 at 06:25:04AM -0500, Lou Berger wrote: > > If the text above is accurate, I think something along its lined along its > lined should be added. If not accurate, then I think you have a new point > to clarify... > Saying that '[re]boot' includes full and partial [re]boots does not really help unless there is somewhere a definition what a full reboot is and what a partial reboot is. /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 Dec 20 04:25:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B9212D892 for ; Wed, 20 Dec 2017 04:25:42 -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=unavailable 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 NWD9eg-ruOcc for ; Wed, 20 Dec 2017 04:25:42 -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 8210F12D946 for ; Wed, 20 Dec 2017 04:25:40 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id C674E1E07A7 for ; Wed, 20 Dec 2017 05:25:39 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id oCRb1w00J2SSUrH01CRecp; Wed, 20 Dec 2017 05:25:39 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=ocR9PWop10UA:10 a=WbWaN0goj5-GqRtqXKoA: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=83tJR0fdZouNkN2UscURTRl4kXgJmjyUuFzweq5CPmw=; b=113JdYC+CgkSua7Y54RAt7oO00 S3e76JgJK2PCUZawvqMtELbXAj4wY+cGY6n+6fjJElNbxIZ6498xUjFF8P2Ow9UmXE8Cf1lUBlShx oESGIQUmjhTXvm8jnCZo5LcXF; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:40938 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 1eRdRH-003PTp-Lx; Wed, 20 Dec 2017 05:25:35 -0700 To: Martin Bjorklund , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net> <198a88e4-9b8b-945b-09a1-49fa9f57cbb0@labn.net> <20171219.213101.692193824403742919.mbj@tail-f.com> <16073ab7280.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171220120627.kl2h6l3n73bc3n5h@elstar.local> From: Lou Berger Message-ID: Date: Wed, 20 Dec 2017 07:25:34 -0500 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: <20171220120627.kl2h6l3n73bc3n5h@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: 1eRdRH-003PTp-Lx 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]:40938 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Wed, 20 Dec 2017 12:25:43 -0000 On 12/20/2017 07:06 AM, Juergen Schoenwaelder wrote: > On Wed, Dec 20, 2017 at 06:25:04AM -0500, Lou Berger wrote: >> >> If the text above is accurate, I think something along its lined along its >> lined should be added. If not accurate, then I think you have a new point >> to clarify... >> > > Saying that '[re]boot' includes full and partial [re]boots does not > really help unless there is somewhere a definition what a full reboot > is and what a partial reboot is. > Humm, this sounds like more of can of worms that is worth addressing here/in this draft at this time. Let's see if it comes up in IESG processing or IETF LC... Lou > /js > From nobody Wed Dec 20 04:56:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB36212D7F7 for ; Wed, 20 Dec 2017 04:56: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, 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 QzKH6ZS717oL for ; Wed, 20 Dec 2017 04:56:55 -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 7BC34126BFD for ; Wed, 20 Dec 2017 04:56:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4FC5AF39 for ; Wed, 20 Dec 2017 13:56:54 +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 beVWZHX5NJMO for ; Wed, 20 Dec 2017 13:56:53 +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 for ; Wed, 20 Dec 2017 13:56:54 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D8C920130 for ; Wed, 20 Dec 2017 13:56:54 +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 979cMEB_GT8R; Wed, 20 Dec 2017 13:56:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADF8920073; Wed, 20 Dec 2017 13:56:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9E12541F4D89; Wed, 20 Dec 2017 13:56:53 +0100 (CET) Date: Wed, 20 Dec 2017 13:56:53 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20171220125653.3tbcrzqtcufwunfl@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20171215 Archived-At: Subject: [netmod] rfc 6087 bis bug X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Dec 2017 12:56:57 -0000 Hi, section 6 refers first to http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines which seems to be OK and then a few lines down it refers to http://www.ops.ietf.org/netconf/yang-security-considerations.txt which results in a 'page not found'. I think there should be only one URL (and the working one is preferred). Note, the first URL also shows up in Appendix B. /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 Dec 20 05:32:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF03C120724 for ; Wed, 20 Dec 2017 05:32: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 wJB-Pka5PJy9 for ; Wed, 20 Dec 2017 05:32:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2573B12422F for ; Wed, 20 Dec 2017 05:32:56 -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 1AC3D1AE0388; Wed, 20 Dec 2017 14:32:54 +0100 (CET) Date: Wed, 20 Dec 2017 14:32:53 +0100 (CET) Message-Id: <20171220.143253.1584852195806955458.mbj@tail-f.com> To: bclaise@cisco.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com> References: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@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] 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, 20 Dec 2017 13:32:58 -0000 Hi, Benoit Claise wrote: > Dear all, > = > Here is my AD review of draft-ietf-netmod-entity-06. > Note that if you post the new version soon (before the end of this > week), I could start the IETF last call, and the draft could be on Ja= n > 11th IESG telechat. > = > - I don't believe that the RFC 2119 keywords are right on the followi= ng > - sentences (SHOULD =3D> should): > = > o The hardware data model SHOULD be suitable for new implementati= ons > to use as is. > = > o The hardware data model defined in this document can be > implemented on a system that also implements ENTITY-MIB, thus t= he > mapping between the hardware data model and ENTITY-MIB SHOULD b= e > clear. You are right, fixed. > 1.2. Tree Diagrams > = > = > Tree diagrams used in this document follow the notation defined in= > [I-D.ietf-netmod-yang-tree-diagrams > ]. > = > You could remove the above and add the reference to section 3. I guess, but having it in the introduction seems consistent with the other documents. > This document defines the YANG module "ietf-hardware", which has t= he > following structure [I-D.ietf-netmod-yang-tree-diagrams > ]: > = > Martin, be consistent with all your YANG modules. Of course, I try to be consistent. > So keep your temp > versions of RFC7223bis and RFC7277bis consistent as well. It would help if you pointed out the inconsistencies you found. > - 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. > 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". 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. > You should mention these ro/rw differences with RFC6933. Ok. > There might be other differences. > = > - > UUIDorZero > = > entPhysicalUUID OBJECT-TYPE > SYNTAX UUIDorZero > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object contains identification information > about the physical entity. The object contains a > Universally Unique Identifier, the syntax of this object > must conform toRFC 4122, Section=A04.1 > . > = > A zero-length octet string is returned if no UUID > information is known." > = > = > The YANG module is: > = > leaf uuid { > type yang:uuid; > config false; > description > "A Universally Unique Identifier of the component."; > reference "RFC 6933 := > entPhysicalUUID"; > } > = > = > Where: > = > typedef uuid { > type string { > pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' > + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; > } > description > "A Universally Unique IDentifier in the string representation > defined in RFC 4122. The canonical representation uses > lowercase characters. > = > The following is an example of a UUID in string representation:= > f81d4fae-7dec-11d0-a765-00a0c91e6bf6 > "; > reference > "RFC 4122: A Universally Unique IDentifier (UUID) URN > Namespace"; > } > = > Again a difference between the MIB and YANG module to mention in the > document? I can add, in the description of leaf "uuid": "If no UUID information is known for this component, this leaf is not instantiated." /martin From nobody Wed Dec 20 06:01:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6D612785F for ; Wed, 20 Dec 2017 06:01:18 -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 lS0kjMtHxcfd for ; Wed, 20 Dec 2017 06:01:17 -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 CC502126CD6 for ; Wed, 20 Dec 2017 06:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3416; q=dns/txt; s=iport; t=1513778477; x=1514988077; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=c5AxbFUMgDtzK/j049z1afvEhgM5k0C3PtqxAXJnTSU=; b=iAF2jIkzsLmpt64DsFrWYzTeoDnOpyXORewUc52dJBnbOmGx79c/yzPj 2MhVxB7ycmdjShQiU/wZqugDS6Amue6cyqdpGI40ny4demjj/clxV0Vri CI/3umxPqIDfwJ22I6LZA8bzlK8XcLJxZzND2SRo1ug/12QuGYkNNDJDC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAAbDpa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCeEBosVj2qZbQojhRgChVUVAQEBAQEBAQEBayiFJAYjDwE?= =?us-ascii?q?FQRALDgwCJgICVwYNCAEBFooREKRMgieKbQEBAQEBAQEBAQEBAQEBAQEBAQEaB?= =?us-ascii?q?YEPgnCDaIFpKYMDgy8BhQSCYwWSHJEoiACNLoIXigEkhzyNHoFZiAWBOzUjgU8?= =?us-ascii?q?yGggbFTyCKoJTHIFoQDcBimMBAQE?= X-IronPort-AV: E=Sophos;i="5.45,432,1508803200"; d="scan'208";a="1048588" 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; 20 Dec 2017 14:01:14 +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 vBKE1EXS000943; Wed, 20 Dec 2017 14:01:14 GMT To: Martin Bjorklund Cc: netmod@ietf.org References: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com> <20171220.143253.1584852195806955458.mbj@tail-f.com> From: Benoit Claise Message-ID: Date: Wed, 20 Dec 2017 15:01:14 +0100 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: <20171220.143253.1584852195806955458.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: Wed, 20 Dec 2017 14:01:19 -0000 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. Now, an attacker who could modify YANG objects can do way more damage that playing with inventory management. "forwarding" in https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-01 comes to mind. >> - >> UUIDorZero >> >> entPhysicalUUID OBJECT-TYPE >> SYNTAX UUIDorZero >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object contains identification information >> about the physical entity. The object contains a >> Universally Unique Identifier, the syntax of this object >> must conform toRFC 4122, Section 4.1 >> . >> >> A zero-length octet string is returned if no UUID >> information is known." >> >> >> The YANG module is: >> >> leaf uuid { >> type yang:uuid; >> config false; >> description >> "A Universally Unique Identifier of the component."; >> reference "RFC 6933 : >> entPhysicalUUID"; >> } >> >> >> Where: >> >> typedef uuid { >> type string { >> pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-' >> + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'; >> } >> description >> "A Universally Unique IDentifier in the string representation >> defined in RFC 4122. The canonical representation uses >> lowercase characters. >> >> The following is an example of a UUID in string representation: >> f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >> "; >> reference >> "RFC 4122: A Universally Unique IDentifier (UUID) URN >> Namespace"; >> } >> >> Again a difference between the MIB and YANG module to mention in the >> document? > I can add, in the description of leaf "uuid": > > "If no UUID information is known for this component, this leaf is > not instantiated." This works. Thanks, Benoit From nobody Wed Dec 20 06:41:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C84126579 for ; Wed, 20 Dec 2017 06:41:22 -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 bWs2ePUaLGOx for ; Wed, 20 Dec 2017 06:41:20 -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 DACD5127023 for ; Wed, 20 Dec 2017 06:41:19 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id g80so19859339lfg.0 for ; Wed, 20 Dec 2017 06:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=9kzjFXnBpYgm+4Wj33vpLPf04r7tgkpTIXFIebV+tHU=; b=IMnDqqoXr/8uKC1H1wFCjqthhxcsaxBt7JlYI4mRWGrGQhldC13snrRH2SJb3i0WEE Vyt0PEx127ZHku/uHA8+KKdZYLQViHhoLOH0ZIHDWmDTOch9ib7RQvzxugkj9KOo6deI JH+Zp40kbs1hyws81OxAezinTkdMy2Sq+TjA8dnKCmYovTSNv2Lv2p4DzyHbuwYF7uW7 PiujVOrJwOyoDzylK3rHLzB3mOxV/B/P1j1ExAe1ic9NchEfAHJjRS4fz0rKq7bHQL1F +Lx+cmZCcL9/fK5Tm8oWyqy4hwvM3l6QEmsHkhlWAASpX/37E/cXwZwr9DvXPrW+1f8u V8Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=9kzjFXnBpYgm+4Wj33vpLPf04r7tgkpTIXFIebV+tHU=; b=YJht/Z7+yIIjBKHpOJ4llsU2fDyjRe4LlTVEZBHJPtS3NfucHXbOUvxaRVlGIDv4hj +UGMilXqzl+BcPwfRKpA6SY3n4q4VRgxoT8Jpp3+aYG1x3IkdlAvkM37AIPJS8h4tUls d0KeShMH+v/5I2MuRYL00DoaXMp5MkhV4auO/eX1wE6OV3FwAomE/BWwb41zc5xzJKRo HvTZvQCOAvEFt2kZDIy4yCWhAYsB2EpMxlenQvkrMlTgRcOtVErYMzk61ykKxk+ihnHm 01i3XVzMBtUb4x1afppOP7u4jSMIaZxevkzqFbo0cCZAPY4Y0SUOoEFCmWFNHhEVftnP 33oQ== X-Gm-Message-State: AKGB3mLaFA9jitm2gdQT9AaDgTBa2A3oTg/vmCLvkO3CfI6Zi5Dl7YKI BAb65op+voPnLPCWjG1Bb/A= X-Google-Smtp-Source: ACJfBovpjeIqxinNE4JsgV256WC/nAYnNjUv/i5j/Zutck7vcPNARddaGGYeFZ8cNzmlfddM/v2T8A== X-Received: by 10.25.92.20 with SMTP id q20mr4344976lfb.48.1513780877715; Wed, 20 Dec 2017 06:41:17 -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 r89sm3679459ljr.16.2017.12.20.06.41.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 06:41:17 -0800 (PST) From: "Xufeng Liu" To: "'Andy Bierman'" , "'Alexander Clemm'" Cc: "'Juergen Schoenwaelder'" , "'NETMOD WG'" References: <20171219191528.2snk3ahnipxcojtb@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4D37@sjceml521-mbx.china.huawei.com> In-Reply-To: Date: Wed, 20 Dec 2017 09:41:13 -0500 Message-ID: <006001d379a0$97c58970$c7509c50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01D37976.AEEF8170" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGWYnqZMJX02CEBETxtgDrcU+RVeACxpE8TAhfCqgMCPM32C6OeSY3w Content-Language: en-us x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy1kMjdlNTViNC1lNTkzLTExZTctOWMzZi0xODVlMGZlM2M0NWNcYW1lLXRlc3RcZDI3ZTU1YjYtZTU5My0xMWU3LTljM2YtMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iNzgyNCIgdD0iMTMxNTgyNTQ0NzMzNzA2ODkzIiBoPSJqYUJzc21nSStScFpkQnMxa29mTWJmYjFmYXM9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ Archived-At: Subject: Re: [netmod] Augmentation to Groupings X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Dec 2017 14:41:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01D37976.AEEF8170 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The restrictions and scopes might be defined, hopefully. It would also = be ok to add new name. =20 Thanks, - Xufeng =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Tuesday, December 19, 2017 3:01 PM To: Alexander Clemm Cc: Juergen Schoenwaelder ; Xufeng = Liu ; NETMOD WG Subject: Re: [netmod] Augmentation to Groupings =20 Hi, =20 I do not want YANG to have augment for groupings because there is no way to control all possible uses-stmts and make sure the augmentation is only used where intended. This seems no different than OO code. A new class name is required for the derived class. In YANG a new = grouping is required and specific uses-stmts have to be updated to use the new = grouping. =20 =20 Andy =20 =20 On Tue, Dec 19, 2017 at 11:51 AM, Alexander Clemm = > wrote: IMHO it would be worth a try. If you wanted to only augment _some_ uses = of a grouping, you could still do the same as today. Also, I would = expect augmentations to only affect servers that support the module = defining the augmentation. If verbosity were not an issue, why were = groupings introduced in the first place? --- Alex > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org = ] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, December 19, 2017 11:15 AM > To: Xufeng Liu > > Cc: NETMOD WG > > Subject: Re: [netmod] Augmentation to Groupings > > The current approach may be verbose but it protects users of groupings = from > unwanted and uncontrolled side effects. Augmenting a grouping as > suggested affects _all_ uses of a grouping; this can be tricky in = situations > where groupings are widely used. > > /js > > On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu wrote: > > During the discussions of TE tunnel and topology models, we have = found > > that it is desirable to have the capability of augmenting a = grouping. > > > > In our case, there are multiple technology specific models = augmenting > > a base generic model. In the base model, some groupings are used > > multiple times, and each augmentation model needs to add more schema > > nodes to the grouping structure. For now, we have to specify an > > =E2=80=9Caugment=E2=80=9D statement for each location where the = grouping is used. Such > > an =E2=80=9Caugment=E2=80=9D statement is repeated many times. It = would be convenient > > and cleaner if we could augment the grouping. > > > > We=E2=80=99d like to hear opinions on the feasibility of such a = capability. > > > > Thanks, > > > > - Xufeng > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org =20 > > 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org =20 > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod =20 ------=_NextPart_000_0061_01D37976.AEEF8170 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The = restrictions and scopes might be defined, hopefully. It would also be ok = to add new name.

 

Thanks,

- = Xufeng

 

From: Andy = Bierman [mailto:andy@yumaworks.com]
Sent: Tuesday, December = 19, 2017 3:01 PM
To: Alexander Clemm = <alexander.clemm@huawei.com>
Cc: Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de>; Xufeng Liu = <xufeng.liu.ietf@gmail.com>; NETMOD WG = <netmod@ietf.org>
Subject: Re: [netmod] Augmentation to = Groupings

 

Hi,

 

I = do not want YANG to have augment for groupings because there = is

no way to control all = possible uses-stmts and make sure the = augmentation

is only used = where intended.  This seems no different than OO = code.

A new class name is = required for the derived class. In YANG a new = grouping

is required and = specific uses-stmts have to be updated to use the new = grouping.

 

 

Andy

 

 

On Tue, = Dec 19, 2017 at 11:51 AM, Alexander Clemm <alexander.clemm@huawei.com> = wrote:

IMHO it = would be worth a try.  If you wanted to only augment _some_ uses of = a grouping, you could still do the same as today.  Also, I would = expect augmentations to only affect servers that support the module = defining the augmentation.  If verbosity were not an issue, why = were groupings introduced in the first place?
--- Alex

> = -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On = Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, December = 19, 2017 11:15 AM
> To: Xufeng Liu <xufeng.liu.ietf@gmail.com&g= t;
> Cc: NETMOD WG <netmod@ietf.org>
> Subject: = Re: [netmod] Augmentation to Groupings
>
> The current = approach may be verbose but it protects users of groupings from
> = unwanted and uncontrolled side effects. Augmenting a grouping as
> = suggested affects _all_ uses of a grouping; this can be tricky in = situations
> where groupings are widely used.
>
> = /js
>
> On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu = wrote:
> > During the discussions of TE tunnel and topology = models, we have found
> > that it is desirable to have the = capability of augmenting a grouping.
> >
> > In our = case, there are multiple technology specific models augmenting
> = > a base generic model. In the base model, some groupings are = used
> > multiple times, and each augmentation model needs to = add more schema
> > nodes to the grouping structure. For now, = we have to specify an
> > =E2=80=9Caugment=E2=80=9D statement = for each location where the grouping is used. Such
> > an = =E2=80=9Caugment=E2=80=9D statement is repeated many times. It would be = convenient
> > and cleaner if we could augment the = grouping.
> >
> > We=E2=80=99d like to hear opinions = on the feasibility of such a capability.
> >
> > = Thanks,
> >
> > - Xufeng
>
> > = _______________________________________________
> > 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    =      <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

 

------=_NextPart_000_0061_01D37976.AEEF8170-- From nobody Wed Dec 20 07:00:26 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E8A126C19 for ; Wed, 20 Dec 2017 07:00:24 -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 07LGmhsQWX1k for ; Wed, 20 Dec 2017 07:00: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 F15F51252BA for ; Wed, 20 Dec 2017 07:00: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 813331AE0388; Wed, 20 Dec 2017 16:00:20 +0100 (CET) Date: Wed, 20 Dec 2017 16:00:20 +0100 (CET) Message-Id: <20171220.160020.956270997417344353.mbj@tail-f.com> To: bclaise@cisco.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com> <20171220.143253.1584852195806955458.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] 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, 20 Dec 2017 15:00:25 -0000 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. /martin From nobody Wed Dec 20 07:52:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D1C127137 for ; Wed, 20 Dec 2017 07:52:54 -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 03hfldjZslsE for ; Wed, 20 Dec 2017 07:52: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 5ADFB1270A3 for ; Wed, 20 Dec 2017 07:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6813; q=dns/txt; s=iport; t=1513785171; x=1514994771; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=khO7bD288zywO8swts1qUwPJYLPni7GyXeWf/mMnnys=; b=Hh9N5p2hLuSd2ERvpOOPydznvP9jCQ78Aifd3YykV4UAOYOuGB+MU34u tJJFRgVLlV+uVo/786lwsDNyiGz7dHKmnaYQT7FfAQ4nftHIdhAuAN8BD CvpCP39JNVGMlWXGiQCdKhG3A1jYT0vEn1EcXnwPMaMgcDgVKzdkKGa6m U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAQDuhTpa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCeEBosVj2kzkVWFUIIVCh+BYoM6AoVVFgEBAQEBAQEBAWs?= =?us-ascii?q?ohSQBBSNWEAsOCioCAlcGDQYCAQEWihEQpE6CJyaKRQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEaBYN/g2iBaSmDA4MvAYFYgyyCYwWKXIdAkSiIAI0ugheKASSHPI0egVm?= =?us-ascii?q?IBYE7JggqgU8yGggbFTyCKYRYQDeKZAEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,432,1508803200"; d="scan'208,217";a="1049615" 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; 20 Dec 2017 15:52: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 vBKFqlAg022716; Wed, 20 Dec 2017 15:52:47 GMT To: Martin Bjorklund Cc: netmod@ietf.org References: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com> <20171220.143253.1584852195806955458.mbj@tail-f.com> <20171220.160020.956270997417344353.mbj@tail-f.com> From: Benoit Claise Message-ID: Date: Wed, 20 Dec 2017 16:52:46 +0100 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: <20171220.160020.956270997417344353.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------B1C9B5478AF6FCA512B4CC22" 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, 20 Dec 2017 15:52:54 -0000 This is a multi-part message in MIME format. --------------B1C9B5478AF6FCA512B4CC22 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 > . > --------------B1C9B5478AF6FCA512B4CC22 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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: entPhysicalMfgName";

Regards, Benoit


    

      


/martin
.



    

    

  


--------------B1C9B5478AF6FCA512B4CC22--


From nobody Wed Dec 20 08:10:47 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D351241F3 for ; Wed, 20 Dec 2017 08:10: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, 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 bmkSzXA3myPL for ; Wed, 20 Dec 2017 08:10:44 -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 5554D1200FC for ; Wed, 20 Dec 2017 08:10:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9238; q=dns/txt; s=iport; t=1513786243; x=1514995843; h=subject:from:to:references:message-id:date:mime-version: in-reply-to; bh=0NzzG+VIywPtEjHTnGTLt2p433AceY6g6X0oQOMhYwU=; b=OwnM/g5rbns55ABRp8wpQCwS2TttVNaZLGQ1XYCicuSgRdbJOXcYMFMk 8JeA2u41DIUtxyetSOmWKW/KXYhEBJnOORiGcFQ+F5AFwkmmG8F+oQCUz hxegu91ni2BASbBuKSihdoksY3nns4eMEbXKgDCckra7b0i5ZZfztU/1P k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAgCOijpa/xbLJq1bGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQkdCeEBosVj2qSCIVQFIIBChgBDIRHTwKFVBcBAQEBAQEBAQFrKIU?= =?us-ascii?q?kAgEDAQEhSxsLQgICJzAGDQYCAQEWihEQpFaCJyaKRgEBAQEBAQEDAQEBAQEBA?= =?us-ascii?q?RwFg3+DaIFpKYMDgy8BgTaDToJjBaNEiACNLoIXigEkhzyNHoFZiAWBOyEDNIF?= =?us-ascii?q?PMhoIGxU8gimCVByBaEA3AYpjAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,432,1508803200"; d="scan'208,217";a="1049921"
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; 20 Dec 2017 16:10:41 +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 vBKGAf9T024810 for ; Wed, 20 Dec 2017 16:10:41 GMT
From: Benoit Claise 
To: NETMOD Working Group 
References:  <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com>
Message-ID: <1d21349e-0ffa-0a66-371c-4e1de948475e@cisco.com>
Date: Wed, 20 Dec 2017 17:10:41 +0100
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: <9e66674b-4c6b-94f4-5fb6-4013c390c5db@cisco.com>
Content-Type: multipart/alternative; boundary="------------1E11859226632F282C2413E1"
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, 20 Dec 2017 16:10:46 -0000

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

Dear all,

One more comment, which I forgot in my AD review.
The -state YANG module in the appendix should actually be "deprecated".

Regards, Benoit
> Dear all,
>
> Here is my AD review of draft-ietf-netmod-entity-06.
> Note that if you post the new version soon (before the end of this 
> week), I could start the IETF last call, and the draft could be on Jan 
> 11th IESG telechat.
>
> - I don't believe that the RFC 2119 keywords are right on the 
> following sentences (SHOULD => should):
>
>     o  The hardware data model SHOULD be suitable for new implementations
>        to use as is.
>
>     o  The hardware data model defined in this document can be
>        implemented on a system that also implements ENTITY-MIB, thus the
>        mapping between the hardware data model and ENTITY-MIB SHOULD be
>        clear.
>
> -
>
>
>       1.2. Tree Diagrams
>
>
>     Tree diagrams used in this document follow the notation defined in
>     [I-D.ietf-netmod-yang-tree-diagrams 
> ].
>
> You could remove the above and add the reference to section 3.
>     This document defines the YANG module "ietf-hardware", which has the
>     following structure [I-D.ietf-netmod-yang-tree-diagrams 
> ]:
> Martin, be consistent with all your YANG modules. So keep your temp 
> versions of RFC7223bis and RFC7277bis consistent as well.
> - 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.
> In the reverse direction, entPhysicalMfgName is read-only in RFC6933, while it's "config true" in draft-ietf-netmod-entity
> You should mention these ro/rw differences with RFC6933.
> There might be other differences.
>
> -
> UUIDorZero
>
> entPhysicalUUID OBJECT-TYPE
>      SYNTAX      UUIDorZero
>      MAX-ACCESS  read-only
>      STATUS      current
>      DESCRIPTION
>              "This object contains identification information
>              about the physical entity.  The object contains a
>              Universally Unique Identifier, the syntax of this object
>              must conform toRFC 4122, Section 4.1 .
>
>              A zero-length octet string is returned if no UUID
>              information is known."
>
>
> The YANG module is:
>
>           leaf uuid {
>             type yang:uuid;
>             config false;
>             description
>               "A Universally Unique Identifier of the component.";
>             reference "RFC 6933 : entPhysicalUUID";
>           }
>
>
> Where:
>
>   typedef uuid {
>      type string {
>        pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
>              + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
>      }
>      description
>       "A Universally Unique IDentifier in the string representation
>        defined in RFC 4122.  The canonical representation uses
>        lowercase characters.
>
>        The following is an example of a UUID in string representation:
>        f81d4fae-7dec-11d0-a765-00a0c91e6bf6
>        ";
>      reference
>       "RFC 4122: A Universally Unique IDentifier (UUID) URN
>                  Namespace";
>    }
>
> Again a difference between the MIB and YANG module to mention in the document?
>
>
> Regards, Benoit (as OPS AD)
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------1E11859226632F282C2413E1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear all,

      

      One more comment, which I forgot in my AD review.

      The -state YANG module in the appendix should actually be
      "deprecated".

      

      Regards, Benoit

    

    

      
      Dear all,

      

        


          Here is my AD review of draft-ietf-netmod-entity-06.

          Note that if you post the new version soon (before the end of
          this week), I could start the IETF last call, and the draft
          could be on Jan 11th IESG telechat.

          

          - I don't believe that the RFC 2119 keywords are right on the
          following sentences (SHOULD => should):

          

          
   o  The hardware data model SHOULD be suitable for new implementations
      to use as is.

   o  The hardware data model defined in this document can be
      implemented on a system that also implements ENTITY-MIB, thus the
      mapping between the hardware data model and ENTITY-MIB SHOULD be
      clear.

-

1.2.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [I-D.ietf-netmod-yang-tree-diagrams].



          You could remove the above and add the reference to section 3.
          
   This document defines the YANG module "ietf-hardware", which has the
   following structure [I-D.ietf-netmod-yang-tree-diagrams]:

          Martin, be consistent with all your YANG modules. So keep your
          temp versions of RFC7223bis and RFC7277bis consistent as well.

          
- 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.
In the reverse direction, entPhysicalMfgName is read-only in RFC6933, while it's "config true" in draft-ietf-netmod-entity
You should mention these ro/rw differences with RFC6933.
There might be other differences. 

- 
UUIDorZero

entPhysicalUUID OBJECT-TYPE
    SYNTAX      UUIDorZero
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "This object contains identification information
            about the physical entity.  The object contains a
            Universally Unique Identifier, the syntax of this object
            must conform to RFC 4122, Section 4.1.

            A zero-length octet string is returned if no UUID
            information is known."


The YANG module is:

         leaf uuid {
           type yang:uuid;
           config false;
           description
             "A Universally Unique Identifier of the component.";
           reference "RFC 6933: entPhysicalUUID";
         }


Where:

 typedef uuid {
    type string {
      pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
            + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
    }
    description
     "A Universally Unique IDentifier in the string representation
      defined in RFC 4122.  The canonical representation uses
      lowercase characters.

      The following is an example of a UUID in string representation:
      f81d4fae-7dec-11d0-a765-00a0c91e6bf6
      ";
    reference
     "RFC 4122: A Universally Unique IDentifier (UUID) URN
                Namespace";
  }

Again a difference between the MIB and YANG module to mention in the document?


Regards, Benoit (as OPS AD)


          

            

      

      

      

      

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


    

    

  


--------------1E11859226632F282C2413E1--


From nobody Wed Dec 20 08:40:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158D8124B17; Wed, 20 Dec 2017 08:40: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 KF4hX6svbI8T; Wed, 20 Dec 2017 08:40:35 -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 62E891200FC; Wed, 20 Dec 2017 08:40:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9009; q=dns/txt; s=iport; t=1513788034; x=1514997634; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=c40y9a8iw2HI8b8cgJYDsgvgGzfZOQu0fC/tHzDpC78=; b=nBnAQ0NGnmFbr4ghMTBYKHk9DQxbJnDdBFFR093/UO3JjcDA5eZpZAA0 X+idC7dNZggtOihVfvmcNPgAZQD8vnTIfrkTxZUhEdFjC5ce+ZH377DRf t2ikepHuDJyCRqcalIj6m0/pWfiySRAAghn0WTEHoUDWsXHSrr54QKCdl k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAwBhkTpa/xbLJq1SCRoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGEJHSELYsVj2oMkXyFUBSCAQofhRwChVQXAQEBAQEBAQEBayiFJAY?= =?us-ascii?q?jBGJNAgJXBgEMCAEBiicQpGmBbTomikMBAQEBAQEBAQIBAQEBAQEBARsFg3+Da?= =?us-ascii?q?IISC4YnAYE2DoNAgmMFik6HTpEoiACDcYk9gheKASSHPI0egVmIBYE7IAE3gU8?= =?us-ascii?q?yGggbFYJmhFdAiFQsghsBAQE?=
X-IronPort-AV: E=Sophos;i="5.45,432,1508803200"; d="scan'208,217";a="1051553"
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; 20 Dec 2017 16:40: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 vBKGeUwa032676; Wed, 20 Dec 2017 16:40:30 GMT
References: 
From: Benoit Claise 
To: NETMOD Working Group , "draft-ietf-netmod-revised-datastores@ietf.org" 
X-Forwarded-Message-Id: 
Message-ID: 
Date: Wed, 20 Dec 2017 17:40:30 +0100
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="------------961B34A367DCC7E01FBE1467"
Content-Language: en-US
Archived-At: 
Subject: [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: Wed, 20 Dec 2017 16:40:37 -0000

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

Dear all,

In order not to be the bottleneck in the process and assuming that the 
document will be in "publication requested" pretty soon, here is my AD 
review of draft-ietf-netmod-revised-datastores-08

-


        5.3.2. Missing Resources

    Configuration in  can refer to resources that are not
    available or otherwise not physically present.  In these situations,
    these parts of  are not applied.  The data appears in
     but does not appear in .


I understand what you want to say.
Let me take an example. I have a router with a Line Card configured and 
working well. if I remove the LC, the configuration should still be in 
the  and  but not in .
However, based on figure below, the notion of "inactive" nodes might be 
misleading. Indeed, people might read that the LC is inactive, so the LC 
configuration should not be in 

      +-------------+                 +-----------+
      |  |                 |  |
      |  (ct, rw)   |<---+       +--->| (ct, rw)  |
      +-------------+    |       |    +-----------+
             |           |       |           |
             |         +-----------+         |
             +-------->|  |<--------+
                       | (ct, rw)  |
                       +-----------+
                             |
                             |        // configuration transformations,
                             |        // e.g., removal of "inactive"
                             |        // nodes, expansion of templates
                             v
                       +------------+
                       |  | // subject to validation
                       | (ct, ro)   |
                       +------------+

I understand that "inactive nodes" has a different meaning.

Proposal:
OLD: removal of "inactive" nodes
NEW: removal of the nodes marked as "inactive"

- In the C.1 example,

    

      bar

      
        eth0
        
          true
          1000
        
        100
        

          2001:db8::10
          64
        

        

          2001:db8::1:100
          64
        

      

I guess it "or:dynamic" should be replaced by "or:learned"

Justification:

      identity learned {
        base origin;
        description
          "Denotes configuration learned from protocol interactions with
           other devices, instead of via either the intended
           configuration datastore or any dynamic configuration
           datastore.

           Examples of protocols that provide learned configuration
           include link-layer negotiations, routing protocols,_and DHCP._";


_Editorial:_

- number the figures

- section 8.2
    This document registers two YANG modules in the YANG Module Names
    registry [RFC6020 ].  Following the format in [RFC6020 ], the the
    following registrations are requested:

duplicated "the the"
  
Regards, Benoit (OPS AD)


--------------961B34A367DCC7E01FBE1467
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    

    In order not to be the bottleneck in the process and assuming that
    the document will be in "publication requested" pretty soon, here is
    my AD review of draft-ietf-netmod-revised-datastores-08

    
 

      - 
        
5.3.2. Missing Resources

      
      

        

          
   Configuration in <intended> can refer to resources that are not
   available or otherwise not physically present.  In these situations,
   these parts of <intended> are not applied.  The data appears in
   <intended> but does not appear in <operational>.

          

          I understand what you want to say.

          Let me take an example. I have a router with a Line Card
          configured and working well. if I remove the LC, the
          configuration should still be in the <running> and
          <intended> but not in <operational>.

          However, based on figure below, the notion of "inactive" nodes
          might be misleading. Indeed, people might read that the LC is
          inactive, so the LC configuration should not be in
          <intended>
          
     +-------------+                 +-----------+
     | <candidate> |                 | <startup> |
     |  (ct, rw)   |<---+       +--->| (ct, rw)  |
     +-------------+    |       |    +-----------+
            |           |       |           |
            |         +-----------+         |
            +-------->| <running> |<--------+
                      | (ct, rw)  |
                      +-----------+
                            |
                            |        // configuration transformations,
                            |        // e.g., removal of "inactive"
                            |        // nodes, expansion of templates
                            v
                      +------------+
                      | <intended> | // subject to validation
                      | (ct, ro)   |
                      +------------+

          I understand that "inactive nodes" has a different meaning.

          

          Proposal: 

          OLD: removal of "inactive" nodes

          NEW: removal of the nodes marked as "inactive"

          

          - In the C.1 example,

          
   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

     <hostname or:origin="or:dynamic">bar</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:dynamic">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

          
I guess it "or:dynamic" should be replaced by "or:learned"

Justification:

     identity learned {
       base origin;
       description
         "Denotes configuration learned from protocol interactions with
          other devices, instead of via either the intended
          configuration datastore or any dynamic configuration
          datastore.

          Examples of protocols that provide learned configuration
          include link-layer negotiations, routing protocols, and
          DHCP.";

          

          
Editorial:

- number the figures

- section 8.2
   This document registers two YANG modules in the YANG Module Names
   registry [RFC6020].  Following the format in [RFC6020], the the
   following registrations are requested:

duplicated "the the"
 
Regards, Benoit (OPS AD)


        

      

    

  


--------------961B34A367DCC7E01FBE1467--


From nobody Wed Dec 20 12:17:06 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847FF126DC2 for ; Wed, 20 Dec 2017 12:17:02 -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 sm-tKIAwhWmO for ; Wed, 20 Dec 2017 12:16:59 -0800 (PST)
Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 23ADE1289B0 for ; Wed, 20 Dec 2017 12:16:48 -0800 (PST)
Received: by mail-lf0-x241.google.com with SMTP id m20so12315667lfi.6 for ; Wed, 20 Dec 2017 12:16:48 -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=4YHVsCZA4QDakbiFlzIbE5TLMnTAp5pC3e8WEfgX7Oo=; b=Hd31CZ7QZF0OF7HVgIXjEC7Df9bMRDyRLFl45TTsllect4OcQbQuhzV6y/uXBLh6sf H9KqiIq/d6IOavpOOGD6f14QyDP81IB1B7B3syWcy+WpIMVSy1SvH8vvIzjlWW8Gy4v4 fBpaaSuyVZ/gKNgcdtQvpkDV4n6qdi6QCZBvWkfiYgn6UOM0tgslcpTAQTSMqjMgqiJw aqlpJxCYK0rCFObJA441lcDP0hp9kT/8ov+wmlTb1Ay0L1wwSztXg/s7xBBkDsitTZes BhO7g3ddPL/G2vNgMb+mxbxzZzySQG/b6RNBxZKl593cOgEuwHIcpZ1jZ2auW2T0z71T fzVw==
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=4YHVsCZA4QDakbiFlzIbE5TLMnTAp5pC3e8WEfgX7Oo=; b=DCI6+7VRu/TV2owpJ3/Fj8PA25wrwsE7fpPPhQCcegp+A1CGD6xlWgcEZTrtNjhNU5 OmXcO7yNo9VUPVIEX0IHZir931O1ABBGBN3DYxX0hLfQglBztCJQ1H+3JXwzuJOcp/J6 QBxJZorQ3HYFqZTEaZp1C+aeII/IqFJ255qo7Mnmh8fO/qcLb4OrusEDYy8ADNSJwj1S Rkl6WaV/b2OAG9I+rbqMEty5zXognKkR+yUKx/83LB4jpKJsr0otKKtR4j4Sxzne8RuE PltRGtDiieidoErTaRqthoTEZjufM+HixI+etg/T5RNUfCphu5MMs4XwtJxuGyOucEIN IiRQ==
X-Gm-Message-State: AKGB3mJgQb4W/f485ICu+NgwnsJCPOjsbSmrn5lR18YraV8vR0VlwvgN kcaJ4KNb1lr4v91GakWCvGIYaHq4RRCyt4Y4wZjxkw==
X-Google-Smtp-Source: ACJfBos7dBFYPbDoswYXDJS19xYRv7/wPc/TDoADLtgZijhjxdYxQI9QpR4uXUrJFhl7Z6iLwz9s3hIAhmbxoZAHBYI=
X-Received: by 10.25.28.9 with SMTP id c9mr4778061lfc.40.1513801006223; Wed, 20 Dec 2017 12:16:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 20 Dec 2017 12:16:44 -0800 (PST)
In-Reply-To: <60876a73-3dec-9a4f-e313-1787b432fb34@cisco.com>
References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local>  <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz>   <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com>  <60876a73-3dec-9a4f-e313-1787b432fb34@cisco.com>
From: Andy Bierman 
Date: Wed, 20 Dec 2017 12:16:44 -0800
Message-ID: 
To: Robert Wilton 
Cc: Kent Watsen , "netmod@ietf.org" ,  "netconf@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114020f03cb0310560cb43b7"
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Dec 2017 20:17:02 -0000

--001a114020f03cb0310560cb43b7
Content-Type: text/plain; charset="UTF-8"

On Wed, Dec 13, 2017 at 6:55 AM, Robert Wilton  wrote:

>
>
> On 11/12/2017 20:55, Andy Bierman wrote:
>
>
>
> On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton  wrote:
>
>> Hi,
>>
>> On 08/12/2017 18:01, Andy Bierman wrote:
>>
>> Hi,
>>
>> A library per datastore sounds too complicated.
>> I prefer the proposal that was made at the IETF meeting that had
>> a 'not-implemented-in' leaf-list and a single module list.
>>
>> The use case that this particular design doesn't work particularly well
>> for is if you have a dynamic datastore that just contains a few modules
>> that are not supported via the conventional datastores.
>>
>> I think that there are future uses cases where the set of modules used
>> for a dynamic datastore could be really quite different and separate from
>> conventional configuration.  E.g. if dynamic subscribers were managed
>> through a dynamic configuration datastore rather than RADIUS.
>>
>>
>> Why is it interesting to have a separate module list for regular modules
>> and imported modules?
>>
>> Several reasons:
>> 1) It means that the list of implemented modules have a single key and
>> hence any references to an implemented module are cleaner/simpler.
>>
>
>
> IMO you are replacing universally meaningful keys  (module-name,
> revision-date) with an arbitrary name,
> It is not cleaner and not simpler for a client.
>
> No, for alternatives A and B, the list key is the module name itself, nor
> an arbitrary name.
> Alternative C uses an arbitrary name.
>
>
>
>
> 2) The model structure naturally more strictly enforces that only a single
>> revision/version of a module is implemented.  (E.g. it prevents a server
>> stating that two revisions of a module are both implemented).
>>
>
>
> How is that the case if the schema list includes its own module list?
> You mean there is a "unique" statement in the outer list that insures that
> a module/revision
> shows up at most once in all instances of the inner module list?
>
> For alt A, each schema represents a single list (so no duplicated
> implemented modules are possible).
>
> For alt B, yes, the rule is that there must be no duplicates in the
> module-sets that are combined into a single schema.
>
>
>

The alt-B approach that seems to be favored is not constrained, but even if
the server does conform
(and not have any overlaps between schema lists) this approach is rather
complicated in order
to answer the simple question "What datastores are supported for module
foo, revision A?"

If the previous design was used, a client could simply retrieve the module
entry and check
the 'not-implemented-in' leaf-list.  Now a client has to retrieve the
entire library, then analyze the
datastore lists (built from the schema entries for the datastore). The
client has to match
instances and look for module "foo" in multiple places.  The client then
assumes that
any missing entry means the module is not supported in that datastore
(assumes read access control
is never applied to the YANG library).

The corner case used as an excuse to redesign the library (ephemeral
datastore with a few modules in it)
is not very interesting, and also not expensive in terms of processing
complexity and bandwidth.
IMO the library should be optimized for conventional + operational, and
also be optimized for
the long-term, not a short-term transition period, biased for server
developers who want
to release partial implementations.


Andy



>
>
>> 3) I genuinely think that the list of implemented modules is more
>> interesting to the client than the imported, but not implemented modules.
>>
>
>
> The conformance leaf was good enough.
> Duplicating the module list and removing the conformance leaf is
> aggressively non-backward compatible.
>
>
>
>>
>> For a server, I would design it to "implement" one revision of every
>> module that it uses (including those that don't contain any data nodes,
>> RPCs, actions, notifications, or deviations), and then the "import-only"
>> list becomes the list of modules that the server implements to satisfy
>> "import-by-revision" and these are stated in the implemented schema anyway.
>>
>>
>> I prefer to keep the conformance leaf and not change the module list.
>>
>> NMDA needs to be possible to implement with a single schema tree such
>> that a module
>> is implemented in all datastores, or a subset of all datastores.
>> Otherwise it probably won't
>> get supported in clients.
>>
>> All solutions accommodate this requirement.
>>
>
>
> Seems to me all new solutions allow a server to violate the MUST in the
> NMDA draft that
> there is a superset of all modules.  A client has to look for every module
> in a server-specific
> set of named schema sets, and then reconcile all these sets.
> I still prefer the single module list with a conformance leaf and a
> leaf-list indicating
> the supported (or unsupported) datastores.
>
> So, this is a trade off between a more expressive model vs a more
> constrained model.
>
> It is worth noting that the existing YANG library (RFC 7895) allows
> servers to produce illegal module lists because they could implement
> multiple revisions of the same module.
>
> Thanks,
> Rob
>
>
>
>
>
>> For me, some of the interesting design questions have revolved around:
>> - is it better to reduce duplication in the list of modules reported at
>> the cost of increased model complexity?
>> - does the solution extend to schema mount?
>> - how well does the solution cope with with configuration datastores that
>> support very different sets of modules?
>>
>> To a lesser extent we have also been considering how well the solution
>> extends to packaging and semantic versioning, but I think that it is quite
>> tricky to know who these are going to pan out.  E.g. I think that the
>> restriction that a given schema will only implement a single revision of a
>> module will end up still holding, but I'm not sure that everyone has that
>> same view point.
>>
>> Thanks,
>> Rob
>>
>>
>>
>
> Andy
>
>
>>
>>
>> Andy
>>
>>
>>
>> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen  wrote:
>>
>>> CC-ing NETCONF, where the draft is being worked on.
>>>
>>> Kent
>>>
>>>
>>> On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
>>> > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
>>> > >
>>> > > Yes. The default value for yang-library-datastore leaf is
>>> ds:operational
>>> > > (the only possible one for the ds:operational datastore). This is
>>> backward
>>> > > compatible. If one needs different model for 'running', etc. then a
>>> new
>>> > > datastore identity has to be defined  and set in place of the
>>> default value.
>>> > > Then this identity can be used to read the yang-library data with
>>> > > .
>>> > >
>>> >
>>> > Sorry, but I have to ask this: How do I obtain the schema for the
>>> > datastore (lets call it ) that reports the schema for
>>> > ? Is there another  datastore? Will
>>> > the recursion end? Perhaps it does since 
>>> > might have itself listed as the schema defining datastore. I guess
>>> > Lada will like these kind of meta and meta-meta datastores.
>>>
>>> Not really. Metadata needn't be in datastores.
>>>
>>> Lada
>>>
>>> >
>>> > /js
>>> >
>>> --
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>>> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh
>>> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv
>>> jISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I
>>> 7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>
>

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




On Wed, Dec 13, 2017 at 6:55 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 11/12/2017 20:5=
5, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Dec 11, 2017 at 2:57 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
Hi,

                

                

                
On
                  08/12/2017 18:01, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
A library per datastore sounds too complicated.
                    
I prefer the proposal that was made at the IETF
                      meeting that had

                    
a 'not-implemented-in' leaf-list and a sin=
gle
                      module list.

                  

                

                The use case that this particular design doesn't work
                particularly well for is if you have a dynamic datastore
                that just contains a few modules that are not supported
                via the conventional datastores.

                

                I think that there are future uses cases where the set
                of modules used for a dynamic datastore could be really
                quite different and separate from conventional
                configuration.=C2=A0 E.g. if dynamic subscribers were manag=
ed
                through a dynamic configuration datastore rather than
                RADIUS.

                

                

                  

                    


                    

                    
Why is it interesting to have a separate module
                      list for regular modules and imported modules?

                  

                

                Several reasons:

                1) It means that the list of implemented modules have a
                single key and hence any references to an implemented
                module are cleaner/simpler.

              

            

            


            

            


            

            
IMO you are replacing universally meaningful keys
              =C2=A0(module-name, revision-date) with an arbitrary name,
            
It is not cleaner and not simpler for a client.

          

        

      

    

    No, for alternatives A and B, the list key is the module name
    itself, nor an arbitrary name.

    Alternative C uses an arbitrary name.

    

    

    

      

        

          

            


            

            


            

            

              
 2) The model
                structure naturally more strictly enforces that only a
                single revision/version of a module is implemented.=C2=A0
                (E.g. it prevents a server stating that two revisions of
                a module are both implemented).

              

            

            


            

            


            

            
How is that the case if the schema list includes its
              own module list?

            
You mean there is a "unique" statement in the ou=
ter
              list that insures that a module/revision

            
shows up at most once in all instances of the inner
              module list?

          

        

      

    

    For alt A, each schema represents a single list (so no duplicated
    implemented modules are possible).

    

    For alt B, yes, the rule is that there must be no duplicates in the
    module-sets that are combined into a single schema.

    

    


The alt-B app=
roach that seems to be favored is not constrained, but even if the server d=
oes conform
(and not have any overlaps between schema lists) this=
 approach is rather complicated in order
to answer the simple que=
stion "What datastores are supported for module foo, revision A?"=


If the previous design was used, a client could s=
imply retrieve the module entry and check
the 'not-implemente=
d-in' leaf-list.=C2=A0 Now a client has to retrieve the entire library,=
 then analyze the
datastore lists (built from the schema entries =
for the datastore). The client has to match
instances and look fo=
r module "foo" in multiple places.=C2=A0 The client then assumes =
that
any missing entry means the module is not supported in that =
datastore (assumes read access control
is never applied to the YA=
NG library).

The corner case used as an excuse to =
redesign the library (ephemeral datastore with a few modules in it)
is not very interesting, and also not expensive in terms of processing c=
omplexity and bandwidth.
IMO the library should be optimized for =
conventional + operational, and also be optimized for
the long-te=
rm, not a short-term transition period, biased for server developers who wa=
nt
to release partial implementations.

<=
br>
Andy



    

      

        

          

            


            

            
=C2=A0

            

              
 3) I genuinely
                think that the list of implemented modules is more
                interesting to the client than the imported, but not
                implemented modules.

              

            

            


            

            


            

            
The conformance leaf was good enough.

            
Duplicating the module list and removing the
              conformance leaf is aggressively non-backward compatible.
            


            

            
=C2=A0

            

              
 

                For a server, I would design it to "implement" on=
e
                revision of every module that it uses (including those
                that don't contain any data nodes, RPCs, actions,
                notifications, or deviations), and then the
                "import-only" list becomes the list of modules th=
at the
                server implements to satisfy "import-by-revision"=
 and
                these are stated in the implemented schema anyway.

                

                

                

                  

                    
I prefer to keep the conformance leaf and not
                      change the module list.

                    


                    

                    
NMDA needs to be possible to implement with a
                      single schema tree such that a module

                    
is implemented in all datastores, or a subset
                      of all datastores.=C2=A0 Otherwise it probably won=
9;t

                    
get supported in clients.

                  

                

                All solutions accommodate this requirement.

              

            

            


            

            


            

            
Seems to me all new solutions allow a server to violate
              the MUST in the NMDA draft that

            
there is a superset of all modules.=C2=A0 A client has to
              look for every module in a server-specific

            
set of named schema sets, and then reconcile all these
              sets.

            
I still prefer the single module list with a
              conformance leaf and a leaf-list indicating

            
the supported (or unsupported) datastores.

          

        

      

    

    So, this is a trade off between a more expressive model vs a more
    constrained model.

    

    It is worth noting that the existing YANG library (RFC 7895) allows
    servers to produce illegal module lists because they could implement
    multiple revisions of the same module.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            

              
 

                For me, some of the interesting design questions have
                revolved around:

                - is it better to reduce duplication in the list of
                modules reported at the cost of increased model
                complexity?

                - does the solution extend to schema mount?

                - how well does the solution cope with with
                configuration datastores that support very different
                sets of modules?

                

                To a lesser extent we have also been considering how
                well the solution extends to packaging and semantic
                versioning, but I think that it is quite tricky to know
                who these are going to pan out.=C2=A0 E.g. I think that the
                restriction that a given schema will only implement a
                single revision of a module will end up still holding,
                but I'm not sure that everyone has that same view point=
.

                

                Thanks,

                Rob

                

                

              

            

            


            

            


            

            
Andy

            
=C2=A0

            

              

                

                  

                    


                    

                    


                    

                    
Andy

                    


                    

                    


                    

                  

                  


                    
On Fri, Dec 8, 2017 at 9:21
                      AM, Kent Watsen <kwatsen@juniper.net>
                      wrote:

                      
CC-ing NETCONF, where
                        the draft is being worked on.

                        

                        Kent

                        

                        

                        On Fri, 2017-12-08 at 16:34 +0100, Juergen
                        Schoenwaelder wrote:

                        > On Fri, Dec 08, 2017 at 04:19:28PM +0100,
                        Vladimir Vassilev wrote:

                        > >

                        > > Yes. The default value for
                        yang-library-datastore leaf is ds:operational

                        > > (the only possible one for the
                        ds:operational datastore). This is backward

                        > > compatible. If one needs different
                        model for 'running', etc. then a new

                        > > datastore identity has to be defined=C2=
=A0
                        and set in place of the default value.

                        > > Then this identity can be used to read
                        the yang-library data with

                        > > <get-data>.

                        > >

                        >

                        > Sorry, but I have to ask this: How do I
                        obtain the schema for the

                        > datastore (lets call it
                        <running-library>) that reports the schema
                        for

                        > <running>? Is there another
                        <running-library-library> datastore? Will

                        > the recursion end? Perhaps it does since
                        <running-library-library>

                        > might have itself listed as the schema
                        defining datastore. I guess

                        > Lada will like these kind of meta and
                        meta-meta datastores.

                        

                        Not really. Metadata needn't be in datastores.<=
br>
                        

                        Lada

                        

                        >

                        > /js

                        >

                        --

                        Ladislav Lhotka

                        Head, CZ.NIC Labs

                        PGP Key ID: 0xB8F92B08A9F76C67

                        

                        ______________________________________________=
_

                        netmod mailing list

                        netmod@ietf.org

                        https://urldefense.proofpoint.com/v2/url?u=3Dhtt=
ps-3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=
=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUv=
ZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwqYmkAVeKz5axFV=
8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFR=
rvQI5l8&e=3D

                        

                        

                        ______________________________________________=
_

                        netmod mailing list

                        netmod@ietf.org

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

                      

                    

                    

                  

                  

                  

                  

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


                

                

              

            

          

          

        

      

    

    

  






--001a114020f03cb0310560cb43b7--


From nobody Wed Dec 20 13:25:25 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68DE1201F2; Wed, 20 Dec 2017 13: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 jhDZE6Ihup8X; Wed, 20 Dec 2017 13:25: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 C75FB1200C5; Wed, 20 Dec 2017 13:25: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 B59EC1AE0388; Wed, 20 Dec 2017 22:25:19 +0100 (CET)
Date: Wed, 20 Dec 2017 22:25:19 +0100 (CET)
Message-Id: <20171220.222519.1257114239789698472.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: netmod@ietf.org, draft-ietf-netmod-revised-datastores@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: Wed, 20 Dec 2017 21:25:23 -0000

Hi,

Thanks for this review!


Benoit Claise  wrote:
> Dear all,
> =

> In order not to be the bottleneck in the process and assuming that th=
e
> document will be in "publication requested" pretty soon, here is my A=
D
> review of draft-ietf-netmod-revised-datastores-08
> =

> -
> =

> =

>        5.3.2. Missing Resources
> =

>    Configuration in  can refer to resources that are not
>    available or otherwise not physically present.  In these situation=
s,
>    these parts of  are not applied.  The data appears in
>     but does not appear in .
> =

> =

> I understand what you want to say.
> Let me take an example. I have a router with a Line Card configured
> and working well. if I remove the LC, the configuration should still
> be in the  and  but not in .
> However, based on figure below, the notion of "inactive" nodes might
> be misleading. Indeed, people might read that the LC is inactive, so
> the LC configuration should not be in 
> =

>      +-------------+                 +-----------+
>      |  |                 |  |
>      |  (ct, rw)   |<---+       +--->| (ct, rw)  |
>      +-------------+    |       |    +-----------+
>             |           |       |           |
>             |         +-----------+         |
>             +-------->|  |<--------+
>                       | (ct, rw)  |
>                       +-----------+
>                             |
>                             |        // configuration transformations=
,
>                             |        // e.g., removal of "inactive"
>                             |        // nodes, expansion of templates=

>                             v
>                       +------------+
>                       |  | // subject to validation
>                       | (ct, ro)   |
>                       +------------+
> =

> I understand that "inactive nodes" has a different meaning.
> =

> Proposal:
> OLD: removal of "inactive" nodes
> NEW: removal of the nodes marked as "inactive"

Ok, I will make this change.

> - In the C.1 example,
> =

>            xmlns=3D"urn:example:system"
>        xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-origin">
> =

>      bar
> =

>      
>        eth0
>        
>          true
>          1000
>        
>        100
>        

>          2001:db8::10
>          64
>        

>        

>          2001:db8::1:100
>          64
>        

>      
> =

> I guess it "or:dynamic" should be replaced by "or:learned"

Yes, I'll fix this.

> Justification:
> =

>      identity learned {
>        base origin;
>        description
>          "Denotes configuration learned from protocol interactions wi=
th
>           other devices, instead of via either the intended
>           configuration datastore or any dynamic configuration
>           datastore.
> =

>           Examples of protocols that provide learned configuration
>           include link-layer negotiations, routing protocols,_and DHC=
P._";
> =

> =

> _Editorial:_
> =

> - number the figures

Ok.

> - section 8.2
>   =A0This document registers two YANG modules in the YANG Module Name=
s
>    registry [RFC6020 ].  Followi=
ng
>    the format in [RFC6020 ], the=
 the
>    following registrations are requested:
> =

> duplicated "the the"

Fixed.

Chairs, should I post a new version with these fixes?


/martin


From nobody Wed Dec 20 13:25:37 2017
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 D7FDA128954; Wed, 20 Dec 2017 13:25:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lou Berger 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, lberger@labn.net, iesg-secretary@ietf.org, netmod@ietf.org, Lou Berger 
Message-ID: <151380513286.2727.13231015021299933226.idtracker@ietfa.amsl.com>
Date: Wed, 20 Dec 2017 13:25:32 -0800
Archived-At: 
Subject: [netmod] Publication has been requested for draft-ietf-netmod-revised-datastores-08
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, 20 Dec 2017 21:25:33 -0000

Lou Berger has requested publication of draft-ietf-netmod-revised-datastores-08 as Proposed Standard on behalf of the NETMOD working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/


From nobody Wed Dec 20 13:44:38 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CE31200C5 for ; Wed, 20 Dec 2017 13:44:38 -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 4U4rebaFD-pj for ; Wed, 20 Dec 2017 13:44:35 -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 CFA26127867 for ; Wed, 20 Dec 2017 13:44:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id E2BFF33E06E9; Wed, 20 Dec 2017 22:44:32 +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 LJnOFS8_VpGI; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B7F7A33E06EA; Wed, 20 Dec 2017 22:44:32 +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 uml9hnUSaA0H; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 86D7F33E06E4; Wed, 20 Dec 2017 22:44:32 +0100 (CET)
To: Benoit Claise , NETMOD Working Group 
References:  
From: Vladimir Vassilev 
Message-ID: <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com>
Date: Wed, 20 Dec 2017 22:44:32 +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] 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: Wed, 20 Dec 2017 21:44:38 -0000

Hello,

On 12/20/2017 05:40 PM, Benoit Claise wrote:

> Dear all,
>
> In order not to be the bottleneck in the process and assuming that the=20
> document will be in "publication requested" pretty soon, here is my AD=20
> review of draft-ietf-netmod-revised-datastores-08
>
> -
>
>
>         5.3.2. Missing Resources
>
>     Configuration in  can refer to resources that are not
>     available or otherwise not physically present.  In these situations=
,
>     these parts of  are not applied.  The data appears in
>      but does not appear in .

I have some concerns with this section.

Systems implementing this are expected to remove config true; nodes=20
while figuring the necessary changes to ensure the remaining set of=20
config true; nodes in operational validates against the operational=20
datastore model. The implementation of this is not a trivial task at=20
all. In order to remove configuration nodes considered inactive on the=20
fly one needs to remove all references to those nodes in mandatory=20
leafrefs in the best case and a potentially long and complex dependency=20
chain of YANG constrain-statements (Xpath etc.) have to be resolved in a=20
worse case. It is difficult to automate this. It requires significant=20
effort to track and remove/fix all those dependencies just to come up=20
with valid configuration that represents the configuration without the=20
"inactive" nodes which in many usecases is completely unjustified=20
implementation effort.

In addition in many cases it is not desirable to remove config true;=20
nodes that depended on a removed resource. For example:

1. A configuration instance of a filter with mandatory interface-ref=20
ingress and egress ports has to be removed from the operational=20
datastore if the egress port is removed as a physical resource. This in=20
effect removes the config false; statistics that might be still of=20
interest counting the matched=C2=A0 traffic while the filter does not hav=
e=20
physical egress port to send the packets.

2. Alarm that is configured with mandatory reference to the missing=20
resource containing a counter of the elapsed time since the resource=20
went missing etc.

I do not find any text in the draft addressing the concerns above. I do=20
not propose a change yet but I hope to hear what others think about that.

Vladimir

> I understand what you want to say.
> Let me take an example. I have a router with a Line Card configured=20
> and working well. if I remove the LC, the configuration should still=20
> be in the  and  but not in .
> However, based on figure below, the notion of "inactive" nodes might=20
> be misleading. Indeed, people might read that the LC is inactive, so=20
> the LC configuration should not be in 
>       +-------------+                 +-----------+
>       |  |                 |  |
>       |  (ct, rw)   |<---+       +--->| (ct, rw)  |
>       +-------------+    |       |    +-----------+
>              |           |       |           |
>              |         +-----------+         |
>              +-------->|  |<--------+
>                        | (ct, rw)  |
>                        +-----------+
>                              |
>                              |        // configuration transformations,
>                              |        // e.g., removal of "inactive"
>                              |        // nodes, expansion of templates
>                              v
>                        +------------+
>                        |  | // subject to validation
>                        | (ct, ro)   |
>                        +------------+
> I understand that "inactive nodes" has a different meaning.
>
> Proposal:
> OLD: removal of "inactive" nodes
> NEW: removal of the nodes marked as "inactive"
>
> - In the C.1 example,
>              xmlns=3D"urn:example:system"
>         xmlns:or=3D"urn:ietf:params:xml:ns:yang:ietf-origin">
>
>       bar
>
>       
>         eth0
>         
>           true
>           1000
>         
>         100
>         

>           2001:db8::10
>           64
>         

>         

>           2001:db8::1:100
>           64
>         

>       
> I guess it "or:dynamic" should be replaced by "or:learned"
>
> Justification:
>
>       identity learned {
>         base origin;
>         description
>           "Denotes configuration learned from protocol interactions wit=
h
>            other devices, instead of via either the intended
>            configuration datastore or any dynamic configuration
>            datastore.
>
>            Examples of protocols that provide learned configuration
>            include link-layer negotiations, routing protocols,_and DHCP=
._";
>
> _Editorial:_
>
> - number the figures
>
> - section 8.2
>    =C2=A0This document registers two YANG modules in the YANG Module Na=
mes
>     registry [RFC6020 ].  Followin=
g the format in [RFC6020 ], the the
>     following registrations are requested:
>
> duplicated "the the"
>  =20
> Regards, Benoit (OPS AD)
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Dec 20 13:56:38 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21EF12D7E5 for ; Wed, 20 Dec 2017 13:56: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=unavailable 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 WtLOv3Sd7YMF for ; Wed, 20 Dec 2017 13:56:35 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 B336D1205D3 for ; Wed, 20 Dec 2017 13:56:35 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 0F2E614048E for ; Wed, 20 Dec 2017 14:56:33 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id oMwV1w00J2SSUrH01MwYFZ; Wed, 20 Dec 2017 14:56:33 -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=ocR9PWop10UA:10 a=RiLJYPmADETnYTw-zrQA: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=v+eATDviO/01sJkxnA+mL6pQGjhOGilvI4sG99cUULE=; b=LV4dEQfre+hUh/otQqYnsJkb2g g5jM6CmeGKWXH3M+jGcSWkoodRu1+9dKu1wX70wfFYwkwxD0cyN33Y/Hk7vc7um1E2GcwkjghJxav 3hQz6Zk8bDMlYDkFq8VA/hoPx;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60162 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eRmLl-003CUi-3v; Wed, 20 Dec 2017 14:56:29 -0700
To: Martin Bjorklund , bclaise@cisco.com
Cc: draft-ietf-netmod-revised-datastores@ietf.org, netmod@ietf.org
References:   <20171220.222519.1257114239789698472.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <753ad393-4262-8ee1-2bcd-13e0f3953b3e@labn.net>
Date: Wed, 20 Dec 2017 16:56:24 -0500
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: <20171220.222519.1257114239789698472.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: 1eRmLl-003CUi-3v
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]:60162
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Wed, 20 Dec 2017 21:56:37 -0000

On 12/20/2017 4:25 PM, Martin Bjorklund wrote:
> Chairs, should I post a new version with these fixes?
Please, but only once you have addressed/closed Vladimir's comment.

Thanks,
Lou


From nobody Wed Dec 20 15:14:39 2017
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 DA9B5124D37; Wed, 20 Dec 2017 15:14:25 -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.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151381166587.12766.12637690948240642513@ietfa.amsl.com>
Date: Wed, 20 Dec 2017 15:14:25 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-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: Wed, 20 Dec 2017 23:14:26 -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-05.txt
	Pages           : 77
	Date            : 2017-12-20

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 main difference from the first version is that this version fully
   conforms to the Network Management Datastore Architecture (NMDA).
   Consequently, 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-05
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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 Wed Dec 20 19:53:44 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D31B127058 for ; Wed, 20 Dec 2017 19:53:42 -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 uGNcK7Q4Hsqu for ; Wed, 20 Dec 2017 19:53:40 -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 A4C621242EA for ; Wed, 20 Dec 2017 19:53:39 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id m20so13221287lfi.6 for ; Wed, 20 Dec 2017 19:53:39 -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=e51EqECKlpqsW4E9HGFFVFS59zquIIqkgU596GxSI1o=; b=uF8Ua0ghhVTBZtGxsYpZzzgOyzIvoFZ6rHcnFD9tJOvQP00Q1hOSONfrNFvH2A2h44 j/skLeFKT6PHwb4n7xEtlxgPzJGStDq49kjKoX8Tt34jr+oMe4hOvQHRBbYI9djAwTrA aMMc4pnpGfdpzFnO9+koDkkx7cuS/C/9IZtHDnQFsZL89Lh4gPT3T82fDGefUkjT3cHI OMQ6cjS+KhaxHElD1PmuOfNtMSt/+zVb2fEI+OVyyXW9cVp8rmw4jPAVIF1lOm/8WeFt /xtc8nc3J7S9XRSpEa09/cyz2L+aDky2f0qij6Zi9Cv/ucdQNW+EKHQDXNZblwaVfN5d mKWQ==
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=e51EqECKlpqsW4E9HGFFVFS59zquIIqkgU596GxSI1o=; b=kpX/TBp+UKQstl5W5mhx5mx7Cbqk/VVrF1gyR/LN/fEWlgZ56n41+FJnVVyGD9NTv1 lUFiKi4R+cZ0DPtcVHgztPl8c291WWhareE+AqTEnFHY3CXv9N/sycZ2TN/nsvtRQEAS Yf8dbB6Ev3NI/9kHB6CCzoqMRTPf2iBgzC4zeU4skEBhAZOc3acZWoA0VY525SItPzED +O1tda1aLAXtH/34ccyHtBpI9fmwNuqE0G6DfbY/0G4JykFfjSliUYnkAMDFWh3FMchM svVESictHpkC11OIpXpMkfvTNqsj9023eFfI0x/DhQOH1ZXjADSFpzyrEnuIvABiXJGG m+lw==
X-Gm-Message-State: AKGB3mLEYnXlX1TLK5UddGnHmQVTHrYpJNgF3fpYQoROFnVrnQ6Tw1Gc qgiH+7IJ5e3YkoIPWBjXz50Ymm9zW/OikVJbDYzd7A==
X-Google-Smtp-Source: ACJfBosqntMtyTCreJJogrcK9jhRNgVc6UZ5P4NJw9kpkhtIPyvk7e9S3WCnMHAiXAti5/1JvXM2sfDbR9KIqAqOR/0=
X-Received: by 10.46.93.27 with SMTP id r27mr6301563ljb.96.1513828417938; Wed, 20 Dec 2017 19:53:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 20 Dec 2017 19:53:37 -0800 (PST)
In-Reply-To: <20171220.112310.1199256299838110805.mbj@tail-f.com>
References: <151376530180.2739.207042237963738855@ietfa.amsl.com> <20171220.112310.1199256299838110805.mbj@tail-f.com>
From: Andy Bierman 
Date: Wed, 20 Dec 2017 19:53:37 -0800
Message-ID: 
To: Martin Bjorklund 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="001a114d60421a386c0560d1a50d"
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 03:53:42 -0000

--001a114d60421a386c0560d1a50d
Content-Type: text/plain; charset="UTF-8"

Hi,

On Wed, Dec 20, 2017 at 2:23 AM, Martin Bjorklund  wrote:

> Hi,
>
> This version addresses the WGLC comments from Andy and Lou, as
> discussed on the list.
>
>
I have reviewed draft-08.

The behavior and server capability reporting for the RFC 6241 datastores
should
remain the authoritative conformance mechanism for conventional datastores.
The server YANG library and  advertisement MUST reflect the same
server metadata (for the relevant standard capabilities).

Sec. 5.1 needs to be clear that the existing :candidate, :writable-running,
and :startup
capabilities still apply, if advertised by the server. Not sure what text
to add.





> /martin
>


Andy


>
>
> 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 Management Datastore Architecture
> >         Authors         : Martin Bjorklund
> >                           Juergen Schoenwaelder
> >                           Phil Shafer
> >                           Kent Watsen
> >                           Robert Wilton
> >       Filename        : draft-ietf-netmod-revised-datastores-08.txt
> >       Pages           : 38
> >       Date            : 2017-12-20
> >
> > 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-08
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
> revised-datastores-08
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-
> revised-datastores-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/
> >
> > _______________________________________________
> > 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
>

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


Hi,

On Wed, Dec 20, 2017 at 2:23 AM, Martin Bjorklund =
<mbj@tail-f.com&=
gt; wrote:
Hi,



This version addresses the WGLC comments from Andy and Lou, as

discussed on the list.



I have reviewed draft-08.
The behavior and server capability reporting for the RFC 6241 =
datastores should
remain the authoritative conformance mechanism =
for conventional datastores.
The server YANG library and <hell=
o> advertisement MUST reflect the same
server metadata (for th=
e relevant standard capabilities).

Sec. 5.1 needs =
to be clear that the existing :candidate, :writable-running, and :startup
capabilities still apply, if advertised by the server. Not sure wh=
at text to add.




=




/martin


Andy
=
=C2=A0





internet-drafts@ietf.org wr=
ote:

>

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

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0: Network Management Datastore Architecture

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0: Martin Bjorklund

>=C2=A0 =C2=A0 =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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Phil Shafer

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Kent Watsen

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0Robert Wilton

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-=
ietf-netmod-revised-datastores-08.txt

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 38

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : 2017-12-20

>

> Abstract:

>=C2=A0 =C2=A0 Datastores are a fundamental concept binding the data mod=
els written

>=C2=A0 =C2=A0 in the YANG data modeling language to network management =
protocols

>=C2=A0 =C2=A0 such as NETCONF and RESTCONF.=C2=A0 This document defines=
 an architectural

>=C2=A0 =C2=A0 framework for datastores based on the experience gained w=
ith the

>=C2=A0 =C2=A0 initial simpler model, addressing requirements that were =
not well

>=C2=A0 =C2=A0 supported in the initial model.=C2=A0 This document updat=
es 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-08

> https://datatracke=
r.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-08
>

> A diff from the previous version is available at:

> https://www.ietf.org=
/rfcdiff?url2=3Ddraft-ietf-netmod-revised-datastores-08

>

>

> 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

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a114d60421a386c0560d1a50d--


From nobody Wed Dec 20 23:36:40 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FBA1250B8 for ; Wed, 20 Dec 2017 23:36:38 -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 FvHp2-5iGuvQ for ; Wed, 20 Dec 2017 23:36:36 -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 06100120726 for ; Wed, 20 Dec 2017 23:36:36 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CCED6ED7; Thu, 21 Dec 2017 08:36: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 e437LiTIUzfj; Thu, 21 Dec 2017 08:36:34 +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, 21 Dec 2017 08:36:34 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA4A120130; Thu, 21 Dec 2017 08:36:34 +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 gnuXzPVoAlvg; Thu, 21 Dec 2017 08:36:34 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 445D520073; Thu, 21 Dec 2017 08:36:34 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E69B041F5D1C; Thu, 21 Dec 2017 08:36:31 +0100 (CET)
Date: Thu, 21 Dec 2017 08:36:31 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Martin Bjorklund , NetMod WG 
Message-ID: <20171221073631.kzo5vasqpydcoywt@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Martin Bjorklund , NetMod WG 
References: <151376530180.2739.207042237963738855@ietfa.amsl.com> <20171220.112310.1199256299838110805.mbj@tail-f.com> 
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] I-D Action: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 07:36:38 -0000

On Wed, Dec 20, 2017 at 07:53:37PM -0800, Andy Bierman wrote:
> Hi,
> 
> On Wed, Dec 20, 2017 at 2:23 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > This version addresses the WGLC comments from Andy and Lou, as
> > discussed on the list.
> >
> >
> I have reviewed draft-08.
> 
> The behavior and server capability reporting for the RFC 6241 datastores
> should
> remain the authoritative conformance mechanism for conventional datastores.
> The server YANG library and  advertisement MUST reflect the same
> server metadata (for the relevant standard capabilities).
> 
> Sec. 5.1 needs to be clear that the existing :candidate, :writable-running,
> and :startup
> capabilities still apply, if advertised by the server. Not sure what text
> to add.
>

There are a lot of things that are not changed at all - does it make
sense to cherry pick some of them and say that they did not change?
It seems that technically there is no point in doing this.

/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 Dec 21 01:42:25 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250511272E1; Thu, 21 Dec 2017 01:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSeQHgKkK5Xq; Thu, 21 Dec 2017 01:42:22 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 30A291200FC; Thu, 21 Dec 2017 01:42:21 -0800 (PST)
Received: from [192.168.1.201] ([80.159.240.8]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0Mbwm6-1ekBEz3K8U-00JJwo; Thu, 21 Dec 2017 10:42:19 +0100
From: Ian Farrer 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com>
Date: Thu, 21 Dec 2017 10:42:18 +0100
Cc: netmod@ietf.org
To: draft-ietf-netmod-yang-tree-diagrams@ietf.org
X-Mailer: Apple Mail (2.3273)
X-Provags-ID: V03:K0:K1ox8dY/ODym9k3PX8s55LXW6l/IJVmvTFDP1hCpX4uh6Tka1qi wp/mkY7YyMEBxMYzqdqK80nSp47GLdXC/oMuRJKP0AB1anoKpa2mjZrKmkKc2cW9HdpdZGI cMwwa5DyavcVPL4ZblPOybTGQEe4b2FNwVotMAblkTxen9bGWiIf5/LRs4AndpBEDdgHI5Q YAW3j0k14EZOCbjivFrSQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:IblLSVtWWcI=:Do0zAuQvsrKt+wp5Zm13kT l8FE//mtjFkOeSRi0HvusSGTERQNv6KRf+MZGCRBxWziQ+Pg6MfbYJNfR7k5zjkHI9Dm/lLBA nI8Mbv6PM687G/Gk2GFpAFeIdruGs5/1UuAQMPTpcS/OUA3XUAau1Dj0E9HrI/mD4i4H9P/Zk nscPbOuRPRq3/KJ2zN+ni38wGSpGQX3EsutSsjdEgWq+jLSbFgsXlpiYIktPqDdNI93K+1gkJ tEW3mLij6jyqZlusXtQjXgwXqZMsARdbM6S6fRXmnCUJKBT4AGCezgCOaNn7oiu5ZYHhSltXU dUGQSYRUgx3DqaEqzx1v8N1jEy7GMVAHlHKmwcd9uXP2iH+iSeTXLfABX1UaOZLfFE+3LT9NC KJtb4H9f34hrfaKbUyda7smpnXTQefMwS9E4es9GILknou6DOZBuXq8c38QEecQ2NA22I/9z8 RIeipsYph5QTOg8WcyfrVkUkZr4q3dBfu18f66xRLFaSIk4lQAk2B83WKGNBB5YSF4PS0Btg1 SM3Rk0rXuz/CQcqBBVE7/2CDsG+MGbst1P9kz2K/Nbl50qkUaLViIbo09+WXRv14CQOty423T 6sfZ9dnK7sgAyO/a2u79eRWA5568wWIw0oU2BN3wRywXyfDhspAY2N90Jg4mu0r5Hz9xEntnP /cdpBdzc1019XpdOAnwytwdvTIiRTME7dDE10spXP/klxzNK//DKRfbNGLWQG4B/BGwdJdqgI oFsh8apdVivhmBplWgcd37t1v6X6D27s+f2TGfVRbWg+/BCH8J657BfBIuFXK63l8fnkdPJy4 6n1GR/Klq4P8CN5Di8Q7+4lLGk6HqRS0vcj61ubbYOJ3Zol1XU=
Archived-At: 
Subject: [netmod] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 09:42:24 -0000

Hi,

I=E2=80=99m just looking at the guidance on wrapping long lines given in =
Section 3.1. Unfortunately, this doesn=E2=80=99t cover the case where I =
refer to a long path. E.g:

augment =
/nat:nat/nat:instances/nat:instance/nat:mapping-table/nat:mapping-entry:

In this case, the total length (unindented) is 80 characters, 82 =
indented and the path is 72 characters. Moving the path onto it=E2=80=99s =
own line with indents will exceed the 72 character limit, so I need a =
line break in the path. What=E2=80=99s the correct way to do this?

Thanks,
Ian=20=


From nobody Thu Dec 21 02:16:26 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339C812762F for ; Thu, 21 Dec 2017 02:16:25 -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 mczTkBjOeTe1 for ; Thu, 21 Dec 2017 02:16:23 -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 5B24F1200C1 for ; Thu, 21 Dec 2017 02:16:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1513851383; x=1515060983; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1ar2AUsEoOJsPKNl5iRTG0rGolrP7zdPiZr3qJCybTU=; b=ah7irm7qBmpltcAnUm4hEQYjn2Aoc/z04MXD8WKCC45qWgSynMkDoFfO 5HJB+KkqqoFtFT2CUaNaMuhB+sK038FpH/WT9edJbv9SXGvI8CsjN5v7j 5n2MFYCVIc8mH55SW3QvBYLQrObJ+bxTSK23FZA5+yfGzu2FiFtaf5Qwp Q=;
X-IronPort-AV: E=Sophos;i="5.45,435,1508803200";  d="scan'208";a="1063531"
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; 21 Dec 2017 10:16:21 +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 vBLAGKcn031354; Thu, 21 Dec 2017 10:16:21 GMT
To: "Acee Lindem (acee)" , Ladislav Lhotka , NETMOD WG 
References: <1512130382.9397.20.camel@nic.cz> 
From: Benoit Claise 
Message-ID: <3fb3c5e8-5dbe-c950-f83f-777a78f9da11@cisco.com>
Date: Thu, 21 Dec 2017 11:16:20 +0100
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] YANG module security considerations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 10:16:25 -0000

Dear all,

The proposed change has been applied to 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
For all document authors, please apply the new template.

Diff at 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines?action=diff&version=13&old_version=12

Regards, Benoit
> Hi Lada, et al,
>
> I haven’t seen any response to this. Your suggestion seems to me to be
> more technically accurate.
>
> Thanks,
> Acee
>
> On 12/1/17, 7:13 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
>
>> Hi,
>>
>> the security considerations template text [1] that has already been used
>> in a
>> number of documents is apparently incorrect - YANG modules aren't
>> accessed by NM
>> protocols. Hence
>>
>> OLD
>>
>> The YANG module defined in this document is designed to be accessed via
>> network
>> management protocols such as ...
>>
>> NEW
>>
>> The YANG module specified in this document defines a schema for data that
>> is
>> designed to be accessed via network management protocols such as ...
>>
>>
>> [1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
>>
>> 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


From nobody Thu Dec 21 02:29:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3C1200C1; Thu, 21 Dec 2017 02:28:59 -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 amra_admI1cu; Thu, 21 Dec 2017 02:28:57 -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 984B912D77B; Thu, 21 Dec 2017 02:28:57 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id E1B5C64452; Thu, 21 Dec 2017 11:28:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513852135; bh=ma1Lg8t6gCZhSkA9O42bGqm/1BN6oq2xL0Ela70UK6o=; h=From:To:Date; b=YqtTYJphIsRV7P4u0NTpIlKnFpgDaXo+fSuLz3O2CMIRQ0Ec9kWL5IcP54FzBw/zU kc1LIAbw4eIiyvcBEo9zGCLiTOmJGuWFz6CAOmg5D8UPRLcRLHUkyXVuDjLOShp0Ui 2sm240bIxle1YdAMTOmD4LF3l91hEmLAQp0vGeVc=
Message-ID: <1513852135.9539.15.camel@nic.cz>
From: Ladislav Lhotka 
To: Ian Farrer ,  draft-ietf-netmod-yang-tree-diagrams@ietf.org
Cc: netmod@ietf.org
Date: Thu, 21 Dec 2017 11:28:55 +0100
In-Reply-To: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com>
References: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.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] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 10:28:59 -0000

Hi Ian,

On Thu, 2017-12-21 at 10:42 +0100, Ian Farrer wrote:
> Hi,
> 
> I’m just looking at the guidance on wrapping long lines given in Section 3.1.
> Unfortunately, this doesn’t cover the case where I refer to a long path. E.g:
> 
> augment /nat:nat/nat:instances/nat:instance/nat:mapping-table/nat:mapping-
> entry:
> 
> In this case, the total length (unindented) is 80 characters, 82 indented and
> the path is 72 characters. Moving the path onto it’s own line with indents
> will exceed the 72 character limit, so I need a line break in the path. What’s
> the correct way to do this?

XPath syntax permits whitespace between tokens, but the argument of "augment" is
a schema node identifier and not XPath. The ABNF productions for schema node
identifiers do not permit whitespace but you can always use string
concatenation:

augment "/nat:nat/nat:instances/nat:instance/"
      + "nat:mapping-table/nat:mapping-entry";

Lada

> 
> Thanks,
> Ian 
> _______________________________________________
> 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 Dec 21 02:30:03 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7AD12D82F; Thu, 21 Dec 2017 02:29:58 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XjLQCRCEICkC; Thu, 21 Dec 2017 02:29:56 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 13B1F1200C1; Thu, 21 Dec 2017 02:29:55 -0800 (PST)
Received: from hargashouseofribs.lan ([80.159.240.8]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MXqaN-1eWlDd45AN-00WqVk; Thu, 21 Dec 2017 11:29:51 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ian Farrer 
In-Reply-To: <1513852135.9539.15.camel@nic.cz>
Date: Thu, 21 Dec 2017 11:29:37 +0100
Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com> <1513852135.9539.15.camel@nic.cz>
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.3273)
X-Provags-ID: V03:K0:eVGw4mbxsuLKs+HQpNRzK1I0d4OA94l3badmks0Gdv1NlGhMo9j mRdQMpLSLkwpVsRQHRP6sFZFLlsacy4PJIl/cy5+YlV+Z0ZfghVA1sptUUJ4QfVIhFnucEz iYfEE0ONPIv+WMQ0TM4h6xfelKigMD19L958ZQvKp+2ujT3zTl7y62nD87GaSne2lFyV+ql zPZTeooGICtNzTUjHV5HQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Tgxtrc4BV+U=:xA2b56WWaeYmgv/rG+aVYh IMlemYSzMHaw6lE5PGIfhym4hA6YHiWMhmwuCVSNEmXHZPyNgVJxSFf9dHe+EXcIxsypfa0Rb J8LWvMbOmS/ENoHhLirA2XeaosRdm5FJbH8RMnxydPx33JROySbi0FhUX4IvSFPUtejNmJEFD FJ88AAujvZxDiTjC9+kzQJsr6NXfdRk1tdEGCclw2srSdw/FG6n1fH+JVj7kuPJN6Ssrx/zje IPIM/0lf9YhyOxCBkp1luRgUGderYpx+jZ87l4nONA6ycbwTL0MJ8m29uKYs6iE4y9On1r5IB wOEzBKYbYNpR+Ib4ulU+XkeZYM1w7fOwl3DF0K2eQ8W8aOk5YF5s8jEstqDJDPzdHNeW5P6DZ c47o+3V7J1fbMRo03IOJoCySA8ahPtkRqL4tXOEK1ewupUvIhGdUmxuapKtDIo/eYDlQnQ7qC nl8KN5uqOPNLIAZrrciqiTdypVEK6L5OH6cWijgAA0OezZozZk57pXViycQv2/Hr0gSfna4Zk i7OFMzZzL72Jzrs+LEGB15ekPDWSW9rStGQy8dw/OJBd5liTWRRWBl3dd2hzYsfOnfeT13KMp 0FHcUFr+cnbQhUWHyxnx5Tkm6uOEo5Q2mPNSqT9LBhAb66e3Fnvg3//5FOAj6cY1TF7CjHGIl kSPkYtJZ0Tsu8xyTSkY8HIDB7S+IaRC8x4miX2ewQlxSUhCt0YbuHZyQLApLnHk//t0H3Y2K4 EMOS+DrDEjD3nkL4fBGLt0jQ8ErE5lZGSkBqulT+9/RgCyK5rcWfVsl4ski+/tr3GDDvS5Ey6 if/VoZdqvOWOIcGfxxxcm5+QY9R7TBhBRmwxzFih0rEKWl7XTY=
Archived-At: 
Subject: Re: [netmod] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 10:29:59 -0000

Great. Many thanks,
Ian

> On 21. Dec 2017, at 11:28, Ladislav Lhotka  wrote:
>=20
> Hi Ian,
>=20
> On Thu, 2017-12-21 at 10:42 +0100, Ian Farrer wrote:
>> Hi,
>>=20
>> I=E2=80=99m just looking at the guidance on wrapping long lines given =
in Section 3.1.
>> Unfortunately, this doesn=E2=80=99t cover the case where I refer to a =
long path. E.g:
>>=20
>> augment =
/nat:nat/nat:instances/nat:instance/nat:mapping-table/nat:mapping-
>> entry:
>>=20
>> In this case, the total length (unindented) is 80 characters, 82 =
indented and
>> the path is 72 characters. Moving the path onto it=E2=80=99s own line =
with indents
>> will exceed the 72 character limit, so I need a line break in the =
path. What=E2=80=99s
>> the correct way to do this?
>=20
> XPath syntax permits whitespace between tokens, but the argument of =
"augment" is
> a schema node identifier and not XPath. The ABNF productions for =
schema node
> identifiers do not permit whitespace but you can always use string
> concatenation:
>=20
> augment "/nat:nat/nat:instances/nat:instance/"
>      + "nat:mapping-table/nat:mapping-entry";
>=20
> Lada
>=20
>>=20
>> Thanks,
>> Ian=20
>> _______________________________________________
>> 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 Thu Dec 21 02:34:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA35712D77B for ; Thu, 21 Dec 2017 02:34:35 -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 DBImEMdbNpbB for ; Thu, 21 Dec 2017 02:34: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 C4A921200C1 for ; Thu, 21 Dec 2017 02:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9181; q=dns/txt; s=iport; t=1513852473; x=1515062073; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ShwN1fhCmXOcFwXVeUR8OEbfvW2O9H4YqZB7vR99ymA=; b=MNxpcGBzLB69KfbnDZJKZCFZjmGAcr5oWdn5C5gK8XVmW+K3sECIETuC a04ys0U/rhGecDyq5rCIiDCa5/GSbfprbAKKiO5NHGGQrGmgkW0N2kWvn pftwyu//h81U8gjJCMzAYR2+dYQwa8wZ0zvn/Je+cYQ007ZSTerKiX4/t Y=;
X-IronPort-AV: E=Sophos;i="5.45,435,1508803200";  d="scan'208";a="1010535"
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; 21 Dec 2017 10:34:31 +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 vBLAYUpD002825; Thu, 21 Dec 2017 10:34:31 GMT
To: Vladimir Vassilev , NETMOD Working Group 
References:   <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com>
From: Robert Wilton 
Message-ID: <64f59023-e000-18c4-8830-29ba6e9be7e9@cisco.com>
Date: Thu, 21 Dec 2017 10:34:30 +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: <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.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: Thu, 21 Dec 2017 10:34:36 -0000

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).  But I agree that there could be 
configuration that is referencing those missing resources, and depending 
on implementation then that configuration may need to become not applied 
as well.  Or perhaps the failure is reported in a different way (e.g. 
IGP neighbor is down).

I also agree that this is non trivial, but the systems that I am 
familiar with have always had to deal with this issue.  At the data 
model level I don't think that this is any more complex than the 
existing 'when' statement processing that has exactly the same issues if 
a "when" statement becomes invalid during a config change and requires 
the associated configuration to be deleted (which again can recursively 
require configuration to be removed).

Alternative solutions are:
  - mandate that nobody physically removes a linecard if there is still 
configuration referencing it, but it is hard to enforce this in software :-)
  - freeze the config from any further changes if a linecard is removed 
that makes the config invalid, but this doesn't seem like a robust 
solution ...

I think that the existing solution is the best approach.

A couple of further comments inline below as well ...

On 20/12/2017 21:44, Vladimir Vassilev wrote:
> Hello,
>
> On 12/20/2017 05:40 PM, Benoit Claise wrote:
>
>> Dear all,
>>
>> In order not to be the bottleneck in the process and assuming that 
>> the document will be in "publication requested" pretty soon, here is 
>> my AD review of draft-ietf-netmod-revised-datastores-08
>>
>> -
>>
>>
>>         5.3.2. Missing Resources
>>
>>     Configuration in  can refer to resources that are not
>>     available or otherwise not physically present.  In these situations,
>>     these parts of  are not applied.  The data appears in
>>      but does not appear in .
>
> I have some concerns with this section.
>
> Systems implementing this are expected to remove config true; nodes 
> while figuring the necessary changes to ensure the remaining set of 
> config true; nodes in operational validates against the operational 
> datastore model. The implementation of this is not a trivial task at 
> all. In order to remove configuration nodes considered inactive on the 
> fly one needs to remove all references to those nodes in mandatory 
> leafrefs in the best case and a potentially long and complex 
> dependency chain of YANG constrain-statements (Xpath etc.) have to be 
> resolved in a worse case. It is difficult to automate this. It 
> requires significant effort to track and remove/fix all those 
> dependencies just to come up with valid configuration that represents 
> the configuration without the "inactive" nodes which in many usecases 
> is completely unjustified implementation effort.
>
> In addition in many cases it is not desirable to remove config true; 
> nodes that depended on a removed resource. For example:
>
> 1. A configuration instance of a filter with mandatory interface-ref 
> ingress and egress ports has to be removed from the operational 
> datastore if the egress port is removed as a physical resource. This 
> in effect removes the config false; statistics that might be still of 
> interest counting the matched  traffic while the filter does not have 
> physical egress port to send the packets.
This isn't necessarily true.  The architecture does not require that the 
filter object is removed because operational is allowed to violate the 
constraints.  Ultimately I think that the behaviour here will depend on 
implementation.

>
> 2. Alarm that is configured with mandatory reference to the missing 
> resource containing a counter of the elapsed time since the resource 
> went missing etc.
Again, the draft does not require that the alarm becomes not applied.  
This also depends on the implementation.

Thanks,
Rob


>
> I do not find any text in the draft addressing the concerns above. I 
> do not propose a change yet but I hope to hear what others think about 
> that.
>
> Vladimir
>
>> I understand what you want to say.
>> Let me take an example. I have a router with a Line Card configured 
>> and working well. if I remove the LC, the configuration should still 
>> be in the  and  but not in .
>> However, based on figure below, the notion of "inactive" nodes might 
>> be misleading. Indeed, people might read that the LC is inactive, so 
>> the LC configuration should not be in 
>>       +-------------+                 +-----------+
>>       |  |                 |  |
>>       |  (ct, rw)   |<---+       +--->| (ct, rw)  |
>>       +-------------+    |       |    +-----------+
>>              |           |       |           |
>>              |         +-----------+         |
>>              +-------->|  |<--------+
>>                        | (ct, rw)  |
>>                        +-----------+
>>                              |
>>                              |        // configuration transformations,
>>                              |        // e.g., removal of "inactive"
>>                              |        // nodes, expansion of templates
>>                              v
>>                        +------------+
>>                        |  | // subject to validation
>>                        | (ct, ro)   |
>>                        +------------+
>> I understand that "inactive nodes" has a different meaning.
>>
>> Proposal:
>> OLD: removal of "inactive" nodes
>> NEW: removal of the nodes marked as "inactive"
>>
>> - In the C.1 example,
>>     >         xmlns="urn:example:system"
>>         xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>>
>>       bar
>>
>>       
>>         eth0
>>         
>>           true
>>           1000
>>         
>>         100
>>         

>>           2001:db8::10
>>           64
>>         

>>         

>>           2001:db8::1:100
>>           64
>>         

>>       
>> I guess it "or:dynamic" should be replaced by "or:learned"
>>
>> Justification:
>>
>>       identity learned {
>>         base origin;
>>         description
>>           "Denotes configuration learned from protocol interactions with
>>            other devices, instead of via either the intended
>>            configuration datastore or any dynamic configuration
>>            datastore.
>>
>>            Examples of protocols that provide learned configuration
>>            include link-layer negotiations, routing protocols,_and 
>> DHCP._";
>>
>> _Editorial:_
>>
>> - number the figures
>>
>> - section 8.2
>>     This document registers two YANG modules in the YANG Module Names
>>     registry [RFC6020 ].  
>> Following the format in [RFC6020 
>> ], the the
>>     following registrations are requested:
>>
>> duplicated "the the"
>>   Regards, Benoit (OPS AD)
>>
>>
>> _______________________________________________
>> 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 Dec 21 02:39:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7650B12D82D; Thu, 21 Dec 2017 02:39:50 -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 9aB4GkS5hT9k; Thu, 21 Dec 2017 02:39: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 DADA31200C1; Thu, 21 Dec 2017 02:39:48 -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 182B31AE0311; Thu, 21 Dec 2017 11:39:48 +0100 (CET)
Date: Thu, 21 Dec 2017 11:39:47 +0100 (CET)
Message-Id: <20171221.113947.2011578475461538770.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: ianfarrer@gmx.com, draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1513852135.9539.15.camel@nic.cz>
References: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com> <1513852135.9539.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=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 10:39:50 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSGkgSWFuLA0KPiANCj4g
T24gVGh1LCAyMDE3LTEyLTIxIGF0IDEwOjQyICswMTAwLCBJYW4gRmFycmVyIHdyb3RlOg0KPiA+
IEhpLA0KPiA+IA0KPiA+IEnigJltIGp1c3QgbG9va2luZyBhdCB0aGUgZ3VpZGFuY2Ugb24gd3Jh
cHBpbmcgbG9uZyBsaW5lcyBnaXZlbiBpbiBTZWN0aW9uIDMuMS4NCj4gPiBVbmZvcnR1bmF0ZWx5
LCB0aGlzIGRvZXNu4oCZdCBjb3ZlciB0aGUgY2FzZSB3aGVyZSBJIHJlZmVyIHRvIGEgbG9uZyBw
YXRoLiBFLmc6DQo+ID4gDQo+ID4gYXVnbWVudCAvbmF0Om5hdC9uYXQ6aW5zdGFuY2VzL25hdDpp
bnN0YW5jZS9uYXQ6bWFwcGluZy10YWJsZS9uYXQ6bWFwcGluZy0NCj4gPiBlbnRyeToNCj4gPiAN
Cj4gPiBJbiB0aGlzIGNhc2UsIHRoZSB0b3RhbCBsZW5ndGggKHVuaW5kZW50ZWQpIGlzIDgwIGNo
YXJhY3RlcnMsIDgyIGluZGVudGVkIGFuZA0KPiA+IHRoZSBwYXRoIGlzIDcyIGNoYXJhY3RlcnMu
IE1vdmluZyB0aGUgcGF0aCBvbnRvIGl04oCZcyBvd24gbGluZSB3aXRoIGluZGVudHMNCj4gPiB3
aWxsIGV4Y2VlZCB0aGUgNzIgY2hhcmFjdGVyIGxpbWl0LCBzbyBJIG5lZWQgYSBsaW5lIGJyZWFr
IGluIHRoZSBwYXRoLiBXaGF04oCZcw0KPiA+IHRoZSBjb3JyZWN0IHdheSB0byBkbyB0aGlzPw0K
PiANCj4gWFBhdGggc3ludGF4IHBlcm1pdHMgd2hpdGVzcGFjZSBiZXR3ZWVuIHRva2VucywgYnV0
IHRoZSBhcmd1bWVudCBvZiAiYXVnbWVudCIgaXMNCj4gYSBzY2hlbWEgbm9kZSBpZGVudGlmaWVy
IGFuZCBub3QgWFBhdGguIFRoZSBBQk5GIHByb2R1Y3Rpb25zIGZvciBzY2hlbWEgbm9kZQ0KPiBp
ZGVudGlmaWVycyBkbyBub3QgcGVybWl0IHdoaXRlc3BhY2UgYnV0IHlvdSBjYW4gYWx3YXlzIHVz
ZSBzdHJpbmcNCj4gY29uY2F0ZW5hdGlvbjoNCj4gDQo+IGF1Z21lbnQgIi9uYXQ6bmF0L25hdDpp
bnN0YW5jZXMvbmF0Omluc3RhbmNlLyINCj4gICAgICAgKyAibmF0Om1hcHBpbmctdGFibGUvbmF0
Om1hcHBpbmctZW50cnkiOw0KDQpCdXQgdGhpcyBpcyBpbiB0aGUgWUFORyBzb3VyY2U7IEkgdGhp
bmsgSWFuIGFza2VkIGFib3V0IHRoZSB0cmVlDQpkaWFncmFtIHN5bnRheC4gIE1heWJlIHRoZSBj
b3JyZXNwb25kaW5nIHN5bnRheCBpbiB0aGUgdHJlZSBkaWFncmFtDQpjb3VsZCBiZSBzaW1wbHk6
DQoNCmF1Z21lbnQgL25hdDpuYXQvbmF0Omluc3RhbmNlcy9uYXQ6aW5zdGFuY2UNCiAgICAgICAg
L25hdDptYXBwaW5nLXRhYmxlL25hdDptYXBwaW5nLWVudHJ5Og0KDQpPciBldmVuIHNpbXBsZXIs
IG1heWJlIHdlIGNhbiBzYXkgdGhhdCBhbnkgc3RyaW5nIGluIHRoZSB0cmVlIGRpYWdyYW0NCnN5
bnRheCBjYW4gZm9sbG93IHRoZSBZQU5HIHN0cmluZyBydWxlcy4NCg0KDQoNCi9tYXJ0aW4NCg==


From nobody Thu Dec 21 02:43:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76456126C22; Thu, 21 Dec 2017 02:43: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 b-sRLNoeNJSC; Thu, 21 Dec 2017 02:43:30 -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 047181200C1; Thu, 21 Dec 2017 02:43: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 CC9816B7; Thu, 21 Dec 2017 11:43:28 +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 0W_12CQYOMxF; Thu, 21 Dec 2017 11:43:27 +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, 21 Dec 2017 11:43:28 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B967320130; Thu, 21 Dec 2017 11:43:28 +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 wGcyPmB6OhhI; Thu, 21 Dec 2017 11:43:28 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 614FA20073; Thu, 21 Dec 2017 11:43:28 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 45D2741F6752; Thu, 21 Dec 2017 11:43:28 +0100 (CET)
Date: Thu, 21 Dec 2017 11:43:28 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: lhotka@nic.cz, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
Message-ID: <20171221104328.ssex3bvj5zuxsjeo@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com> <1513852135.9539.15.camel@nic.cz> <20171221.113947.2011578475461538770.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171221.113947.2011578475461538770.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 10:43:32 -0000

On Thu, Dec 21, 2017 at 11:39:47AM +0100, Martin Bjorklund wrote:

> But this is in the YANG source; I think Ian asked about the tree
> diagram syntax.  Maybe the corresponding syntax in the tree diagram
> could be simply:
> 
> augment /nat:nat/nat:instances/nat:instance
>         /nat:mapping-table/nat:mapping-entry:

Works for me.
 
> Or even simpler, maybe we can say that any string in the tree diagram
> syntax can follow the YANG string rules.

The YANG string rules are for machines to get the parsing right. Since
the tree diagrams are for humans, the less noise the 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 Thu Dec 21 03:09:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA8127010 for ; Thu, 21 Dec 2017 03:09: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 TNXWybruMShd for ; Thu, 21 Dec 2017 03:09:48 -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 49E9E1200C1 for ; Thu, 21 Dec 2017 03:09:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1535; q=dns/txt; s=iport; t=1513854588; x=1515064188; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=E9ifloyv8LVb9twHHyaXoM5Z58RmocU8y9RtrfqZOYo=; b=JdPVkPCYfRX+SQm7L/qgdmD/BhkpUPDIxWtO0i7gAGEYNO32q9plQFQ/ gIdH7JJU1wqmZWHRxMEOhGGtCy/kOr7N16wLdYW+qId9jhYX3SiQymrCj dqfS1QWnpuIPItynZJJpnBIdI8xaSHl6hvybayq1JySd36v7AQyLfb8+L U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQBtlTta/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPggknhAaLGJAdmT4KhTsChQoVAQEBAQEBAQEBayiFJAEFIw8?= =?us-ascii?q?BBVELEgYCAiYCAkkOBgEMBgIBAYonpGqCJ4ptAQEBAQEBAQMBAQEBAQEBASCBD?= =?us-ascii?q?4Jwg2iBaSmDBYMwgViDLYJlBaNIlS+MGIdijnqIBYE7NSOBTzIaCBsVPIIpglQ?= =?us-ascii?q?cgWdBN4l3AQEB?=
X-IronPort-AV: E=Sophos;i="5.45,435,1508803200";  d="scan'208";a="1064600"
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; 21 Dec 2017 11:09:46 +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 vBLB9kr3013312; Thu, 21 Dec 2017 11:09:46 GMT
To: Andy Bierman , Martin Bjorklund , NetMod WG 
References: <151376530180.2739.207042237963738855@ietfa.amsl.com> <20171220.112310.1199256299838110805.mbj@tail-f.com>  <20171221073631.kzo5vasqpydcoywt@elstar.local>
From: Robert Wilton 
Message-ID: 
Date: Thu, 21 Dec 2017 11:09:45 +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: <20171221073631.kzo5vasqpydcoywt@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 11:09:51 -0000

On 21/12/2017 07:36, Juergen Schoenwaelder wrote:
> On Wed, Dec 20, 2017 at 07:53:37PM -0800, Andy Bierman wrote:
>> Hi,
>>
>> On Wed, Dec 20, 2017 at 2:23 AM, Martin Bjorklund  wrote:
>>
>>> Hi,
>>>
>>> This version addresses the WGLC comments from Andy and Lou, as
>>> discussed on the list.
>>>
>>>
>> I have reviewed draft-08.
>>
>> The behavior and server capability reporting for the RFC 6241 datastores
>> should
>> remain the authoritative conformance mechanism for conventional datastores.
>> The server YANG library and  advertisement MUST reflect the same
>> server metadata (for the relevant standard capabilities).
This statement seems reasonable, but would probably be better placed in 
the NETCONF NMDA protocol draft?

>>
>> Sec. 5.1 needs to be clear that the existing :candidate, :writable-running,
>> and :startup
>> capabilities still apply, if advertised by the server. Not sure what text
>> to add.
> There are a lot of things that are not changed at all - does it make
> sense to cherry pick some of them and say that they did not change?
> It seems that technically there is no point in doing this.
I'm also not sure whether this needs stating.  Isn't the assumption that 
everything still applies unless explicitly stated to the contrary?

But if we need to add any text then I think that any such text would be 
more appropriate in the NMDA protocol drafts rather than the base NMDA 
architecture specification.

Thanks,
Rob


>
> /js
>


From nobody Thu Dec 21 03:14:57 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51B412D837; Thu, 21 Dec 2017 03:14:55 -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 YGIJ-s0Ns0V5; Thu, 21 Dec 2017 03:14:54 -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 CDDA11200C1; Thu, 21 Dec 2017 03:14:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1080; q=dns/txt; s=iport; t=1513854894; x=1515064494; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/T+MTMP3l25M6U4VOqHS5fL0j1jZp4yPMEHU+CsjDCs=; b=F4PNuCiiT2z7DL80/ZY87DnAVsw0cBOL5mC1jUJyou3kQ3piXwM5hS4s gN2iBj+A8noE7viWmW/qVhQ5YDNWRmOXsGA83/Rl+i3U6LyOqpwoyfI4H 6rQtd3DfRKUy00rEQ1VMOPMsIMyi9hpXNlvDQiMv6vl+Lc9IuJxbZLQjP Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQBxljta/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUYhC2LGI92J5k+CoU7AoULFAEBAQEBAQEBAWsohSMBAQEBAgE?= =?us-ascii?q?jFVELDgoCAiYCAlcGAQwIAQGKHwika4Inim0BAQEBAQEBAQEBAQEBAQEBAQEgg?= =?us-ascii?q?Q+CcINoghIMgnmINYJlBaNIlS+MGIdijnqIBYE7NiKBTzIaCBsVPIIqgwiBTkG?= =?us-ascii?q?KLgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.45,435,1508803200";  d="scan'208";a="1011438"
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; 21 Dec 2017 11:14:52 +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 vBLBEpe2014807; Thu, 21 Dec 2017 11:14:52 GMT
To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
References: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com> <1513852135.9539.15.camel@nic.cz> <20171221.113947.2011578475461538770.mbj@tail-f.com> <20171221104328.ssex3bvj5zuxsjeo@elstar.local>
From: Robert Wilton 
Message-ID: 
Date: Thu, 21 Dec 2017 11:14:51 +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: <20171221104328.ssex3bvj5zuxsjeo@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 11:14:56 -0000

On 21/12/2017 10:43, Juergen Schoenwaelder wrote:
> On Thu, Dec 21, 2017 at 11:39:47AM +0100, Martin Bjorklund wrote:
>
>> But this is in the YANG source; I think Ian asked about the tree
>> diagram syntax.  Maybe the corresponding syntax in the tree diagram
>> could be simply:
>>
>> augment /nat:nat/nat:instances/nat:instance
>>          /nat:mapping-table/nat:mapping-entry:
> Works for me.
This is a trivial thing, but I would probably outdent or indent the 
second and subsequent lines to help it seem like one string rather than 
a list of strings.

E.g. perhaps:

augment /nat:nat/nat:instances/nat:instance
           /nat:mapping-table/nat:mapping-entry:

Or

augment /nat:nat/nat:instances/nat:instance
     /nat:mapping-table/nat:mapping-entry:

Thanks,
Rob


>   
>> Or even simpler, maybe we can say that any string in the tree diagram
>> syntax can follow the YANG string rules.
> The YANG string rules are for machines to get the parsing right. Since
> the tree diagrams are for humans, the less noise the better.
>
> /js
>


From nobody Thu Dec 21 03:15:18 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DDE1200C1; Thu, 21 Dec 2017 03:15:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tjgD5k1naEt; Thu, 21 Dec 2017 03:15:15 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 CAB7312D833; Thu, 21 Dec 2017 03:15:12 -0800 (PST)
Received: from [192.168.1.201] ([80.159.240.8]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0M3S2C-1fIhvR1o8G-00r0WN; Thu, 21 Dec 2017 12:15:01 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ian Farrer 
In-Reply-To: <20171221104328.ssex3bvj5zuxsjeo@elstar.local>
Date: Thu, 21 Dec 2017 12:15:00 +0100
Cc: Martin Bjorklund , netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com> <1513852135.9539.15.camel@nic.cz> <20171221.113947.2011578475461538770.mbj@tail-f.com> <20171221104328.ssex3bvj5zuxsjeo@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3273)
X-Provags-ID: V03:K0:lynX3VMmOIPakdYVRKUlcj1vV+aod+xMw01AMvC1PsEzKHr28KR s39HF5iLKXN5Dnwx63FyVj/Rs+jLFFLBkBBhJuosaG97bv+vWWLKpHfNikkCNSKnDj92FRh euPdBBwqVNXMzdQpuaEfdaYtq/YX6Tsr1zXOehkm9F5jJVaeSQ6G2pcBXXIbp6wGinmL4d5 KjNfFC4sKKrDDgE86faXw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:V+xRDhCAvJE=:nPzjvM+jTzj4oqqYAUw5Hq Gb+A5NS/F+5aQhvr/7jbowChPinq60gQ3/Xi5sLyqMtda52liks/PVY+Vy53Huf9Gy5cEJeQc bKyEWqbs2BQQIwoME1BKRUQjhHHLKhEzPRHKvxi+epTWw6QbZVuAL/1VTGBKfpO6WqEa33hdv LLf6rWvc9JQvtEwP8YIze+4q0VcYryEj7NJQD45ejJ5w2fm3NcmRpa0Z8a/LOWqryvKIlSODe iaj7ILZVLF7e2WDxzcyWeWUjZI9fW4k0Lswq/bUHtYxA/Bn93dMknO5bTo40kVzmGpkypyyvB 56m8QT1H6pHn2/vzCx4bKO7xCFZLHEBIvLZlIt1nHdo3dEMYPumctroEcact19eEGrEhdM80H MfUvoZ6Okg1rZg4DxfU2dz5C3BytsQp1tkG+njQvkLB0zh/Y3duw8YruhL6S2HmX5sYGbxzuE ZAelzsFO949FdQHoGqlfCp8HLrBOkf4tG16LGOtAMUgzLe7uBlYlRyUom33AsKlyzCDeCp7T7 stkMXeixlbwlWbwT8y2a4iMt1q0UxsWvmEyFARH2HpGaCkjMoAXcYlAY/tApqApN1wa0HN6tK no4uF1lpvar2gyr9wr6bPSbYdMIM7rKB9zA0ibSr/FX4NUf1PXYSN6qpNoVyhTpCoQxpVI4O+ mHEJ5PthBTu8csQV09CtIxlSLYrbV324ImtbSWgR4PZsIobHBt0Qrr1gPo1KtEkenl9nGWfFw uqEO6Ut9kt1F7c812FvkWHJxKFIHb0UQjmeF4UYfwuAZpNj8vsk38ihIoobN4yhO0UjS4Fsbe yymVnVBHZi31ckjnU9B5XebV6FC1kQ3CUK6UUEgsPGBwcNZZ4E=
Archived-At: 
Subject: Re: [netmod] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 11:15:18 -0000

Thanks. This suggestion seems cleanest. Can the tree diagrams draft be =
updated to describe this?

BR,
Ian


> On 21. Dec 2017, at 11:43, Juergen Schoenwaelder =
 wrote:
>=20
> On Thu, Dec 21, 2017 at 11:39:47AM +0100, Martin Bjorklund wrote:
>=20
>> But this is in the YANG source; I think Ian asked about the tree
>> diagram syntax.  Maybe the corresponding syntax in the tree diagram
>> could be simply:
>>=20
>> augment /nat:nat/nat:instances/nat:instance
>>        /nat:mapping-table/nat:mapping-entry:
>=20
> Works for me.
>=20
>> Or even simpler, maybe we can say that any string in the tree diagram
>> syntax can follow the YANG string rules.
>=20
> The YANG string rules are for machines to get the parsing right. Since
> the tree diagrams are for humans, the less noise the better.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Dec 21 03:28:22 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5AF12D838; Thu, 21 Dec 2017 03:28:21 -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 ezgFdF-ybuAe; Thu, 21 Dec 2017 03:28:19 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7AF124D68; Thu, 21 Dec 2017 03:28:19 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 48DC4182040F; Thu, 21 Dec 2017 12:27:59 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id A684D18203F5; Thu, 21 Dec 2017 12:27:57 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: ianfarrer@gmx.com, draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org
In-Reply-To: <20171221.113947.2011578475461538770.mbj@tail-f.com>
References: <45E0BE8A-DA0B-459E-9757-C9817912E473@gmx.com> <1513852135.9539.15.camel@nic.cz> <20171221.113947.2011578475461538770.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , ianfarrer@gmx.com, draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org
Date: Thu, 21 Dec 2017 12:28:14 +0100
Message-ID: <87r2rol3qp.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 11:28:21 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Hi Ian,
>>=20
>> On Thu, 2017-12-21 at 10:42 +0100, Ian Farrer wrote:
>> > Hi,
>> >=20
>> > I=E2=80=99m just looking at the guidance on wrapping long lines given =
in Section 3.1.
>> > Unfortunately, this doesn=E2=80=99t cover the case where I refer to a =
long path. E.g:
>> >=20
>> > augment /nat:nat/nat:instances/nat:instance/nat:mapping-table/nat:mapp=
ing-
>> > entry:
>> >=20
>> > In this case, the total length (unindented) is 80 characters, 82 inden=
ted and
>> > the path is 72 characters. Moving the path onto it=E2=80=99s own line =
with indents
>> > will exceed the 72 character limit, so I need a line break in the path=
. What=E2=80=99s
>> > the correct way to do this?
>>=20
>> XPath syntax permits whitespace between tokens, but the argument of "aug=
ment" is
>> a schema node identifier and not XPath. The ABNF productions for schema =
node
>> identifiers do not permit whitespace but you can always use string
>> concatenation:
>>=20
>> augment "/nat:nat/nat:instances/nat:instance/"
>>       + "nat:mapping-table/nat:mapping-entry";
>
> But this is in the YANG source; I think Ian asked about the tree
> diagram syntax.  Maybe the corresponding syntax in the tree diagram

Oh, sorry, I thought is was about 6087bis.

Lada

> could be simply:
>
> augment /nat:nat/nat:instances/nat:instance
>         /nat:mapping-table/nat:mapping-entry:
>
> Or even simpler, maybe we can say that any string in the tree diagram
> syntax can follow the YANG string rules.
>
>
>
> /martin

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Dec 21 03:37:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60E7124D68 for ; Thu, 21 Dec 2017 03:37:50 -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 eZv6K0zY_QhJ for ; Thu, 21 Dec 2017 03:37:48 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2285F12025C for ; Thu, 21 Dec 2017 03:37:48 -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 5B2F01AE0311 for ; Thu, 21 Dec 2017 12:37:47 +0100 (CET)
Date: Thu, 21 Dec 2017 12:37:46 +0100 (CET)
Message-Id: <20171221.123746.382540578845045602.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20171220.160020.956270997417344353.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] 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, 21 Dec 2017 11:37:50 -0000

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.

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


From nobody Thu Dec 21 03:50:19 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262D4126DFB for ; Thu, 21 Dec 2017 03:50:18 -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 GwGVLs8ejVDH for ; Thu, 21 Dec 2017 03:50:13 -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 D704012421A for ; Thu, 21 Dec 2017 03:50:12 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A969A69; Thu, 21 Dec 2017 12:50:11 +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 wuZGQxM8HnxZ; Thu, 21 Dec 2017 12:50:10 +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, 21 Dec 2017 12:50:11 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7776020130; Thu, 21 Dec 2017 12:50:11 +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 rGKUoFebAqRJ; Thu, 21 Dec 2017 12:50:10 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D02520073; Thu, 21 Dec 2017 12:50:10 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 23D1941F6A0A; Thu, 21 Dec 2017 12:50:10 +0100 (CET)
Date: Thu, 21 Dec 2017 12:50:10 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Message-ID: <20171221115010.annbhb4vs3roo4dk@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References:  <20171220.160020.956270997417344353.mbj@tail-f.com>  <20171221.123746.382540578845045602.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171221.123746.382540578845045602.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
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, 21 Dec 2017 11:50:18 -0000

On Thu, Dec 21, 2017 at 12:37:46PM +0100, 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.
> 
> 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).

The last sentence is not useful since nobody knows what 'preferred'
value means. So remove it.

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

I do not think 'post-it' note helps to clarify things. What about
changing the second sentence to:

  The configured value is used only if the server cannot determine the
  vendor-specific serial number from the component itself.

I do not understand the pre-provisioning part. Something
pre-provisioning won't appear in  and when it appears,
then the normal rules apply, no?

>            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.";

This may not be needed if we use the above formulation.

>         reference "RFC 6933: entPhysicalSerialNum";
>       }
> 
> And corresponding text for 'mfg-name' and 'model-name'.

/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 Dec 21 03:58:29 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228A112421A for ; Thu, 21 Dec 2017 03:58: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 cmHrgtSAiMWb for ; Thu, 21 Dec 2017 03:58: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 808B112D848 for ; Thu, 21 Dec 2017 03:58:27 -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 69DAF1AE0311; Thu, 21 Dec 2017 12:58:26 +0100 (CET)
Date: Thu, 21 Dec 2017 12:58:26 +0100 (CET)
Message-Id: <20171221.125826.1295894140821866805.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20171221115010.annbhb4vs3roo4dk@elstar.local>
References:  <20171221.123746.382540578845045602.mbj@tail-f.com> <20171221115010.annbhb4vs3roo4dk@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] 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, 21 Dec 2017 11:58:29 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Dec 21, 2017 at 12:37:46PM +0100, 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.
> > 
> > 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).
> 
> The last sentence is not useful since nobody knows what 'preferred'
> value means. So remove it.

This text comes from RFC 6933.  Do you really think it is not clear
what the intention is?

> >            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.
> 
> I do not think 'post-it' note helps to clarify things. What about
> changing the second sentence to:
> 
>   The configured value is used only if the server cannot determine the
>   vendor-specific serial number from the component itself.

Works for me.

> I do not understand the pre-provisioning part. Something
> pre-provisioning won't appear in  and when it appears,
> then the normal rules apply, no?

Yes.


> 
> >            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.";
> 
> This may not be needed if we use the above formulation.

Agreed.  So we'd have a single paragraph:

   This leaf can be configured.  The configured value is used only if
   the server cannot determine the vendor-specific serial number from
   the component itself.


/martin


From nobody Thu Dec 21 04:03:42 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDA612D833 for ; Thu, 21 Dec 2017 04:03:40 -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 S4Rqep3tKlMH for ; Thu, 21 Dec 2017 04:03: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 EF56412421A for ; Thu, 21 Dec 2017 04:03: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 B8EF9F39; Thu, 21 Dec 2017 13:03: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 Inf1_7cRo3yo; Thu, 21 Dec 2017 13:03:36 +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, 21 Dec 2017 13:03:37 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6BA820131; Thu, 21 Dec 2017 13:03:37 +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 9Cs1aotboeE2; Thu, 21 Dec 2017 13:03:37 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C98920130; Thu, 21 Dec 2017 13:03:37 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1014041F6B37; Thu, 21 Dec 2017 13:03:37 +0100 (CET)
Date: Thu, 21 Dec 2017 13:03:36 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Message-ID: <20171221120336.asqnp343in7y26ie@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References:  <20171221.123746.382540578845045602.mbj@tail-f.com> <20171221115010.annbhb4vs3roo4dk@elstar.local> <20171221.125826.1295894140821866805.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171221.125826.1295894140821866805.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
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, 21 Dec 2017 12:03:41 -0000

On Thu, Dec 21, 2017 at 12:58:26PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Dec 21, 2017 at 12:37:46PM +0100, 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.
> > > 
> > > 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).
> > 
> > The last sentence is not useful since nobody knows what 'preferred'
> > value means. So remove it.
> 
> This text comes from RFC 6933.  Do you really think it is not clear
> what the intention is?

I guess I read too fast. No, the sentence is fine. My comment was wrong.

[...] 
 
> Agreed.  So we'd have a single paragraph:
> 
>    This leaf can be configured.  The configured value is used only if
>    the server cannot determine the vendor-specific serial number from
>    the component itself.

Yes, I think this covers it.

/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 Dec 21 05:03:53 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFD71275F4 for ; Thu, 21 Dec 2017 05:03: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, 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 QNCVwpNIjR9B for ; Thu, 21 Dec 2017 05:03:48 -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 673BA12741D for ; Thu, 21 Dec 2017 05:03:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 454D533E06E8; Thu, 21 Dec 2017 14:03:46 +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 U5_-W0LLtD-m; Thu, 21 Dec 2017 14:03:46 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 18C2433E06E7; Thu, 21 Dec 2017 14:03:46 +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 EUGtNJAJMUlu; Thu, 21 Dec 2017 14:03:46 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id DD79933E06E2; Thu, 21 Dec 2017 14:03:45 +0100 (CET)
To: Robert Wilton , NETMOD Working Group 
References:   <79d1baae-397d-883e-3bc0-e1c5f71fc4f8@transpacket.com> <64f59023-e000-18c4-8830-29ba6e9be7e9@cisco.com>
From: Vladimir Vassilev 
Message-ID: <6e899e21-8931-b61c-3b73-6c8a8a1c912a@transpacket.com>
Date: Thu, 21 Dec 2017 14:03:45 +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: <64f59023-e000-18c4-8830-29ba6e9be7e9@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
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: Thu, 21 Dec 2017 13:03:52 -0000

On 12/21/2017 11:34 AM, Robert Wilton wrote:

> Hi Vladimir,
>
> First point of clarification is that this is not about=20
> running/intended at all.=C2=A0 The contents of running/intended do not=20
> change in anyway depending on whether hardware is present or absent.
>
> The section is only concerned with how the configuration is applied in=20
> operational, and basically says that you cannot apply configuration=20
> for resources that are missing (which seems reasonable).=C2=A0 E.g. I=20
> cannot configure an IP address on a physical interface that isn't=20
> there.=C2=A0 Or if the physical interface gets removed then the=20
> configuration associated with that interface is also removed from=20
> operational.
>
> Operational isn't validated and data model constraints are allowed to=20
> be broken (ideally transiently).
I want to focus on this. IMO giving up schema validitiy for any=20
datastore is unacceptable price. Pre-NMDA devices had full model support=20
in operational data (all YANG constrains part of the model without=20
discrimination were enforced). If this is about to change it will=20
compromise interoperability and a significant portion of the client=20
implementation workload that can be automated will need to be coded in=20
hand and tested. Unresolved leafrefs, undefined behaviour of different=20
implementations removing different configuration nodes in violation of=20
YANG semantic constraints (which I do not think can be so clearly=20
separated from the syntactic constraints when one considers types like=20
leafref, instance-identifier etc.) and the corresponding side effects=20
based on the server implementators own creativity is eventually going to=20
create more problems.

1. IMO the only acceptable solution is to have YANG valid operational=20
datastore at all times. operational like any other datastore MUST be=20
valid YANG data tree and it has to be a system implementation task to=20
consider all complications resulting from the removal of the resources=20
leading to any data transformations. If this is difficult or impossible=20
other mechanisms to flag missing resources should be used (e.g.=20
/interfaces/interface/oper-status=3Dnot-present) This sounds like a usefu=
l=20
contract providing the value of a standard the alternative does not.

2. Even with the change in 1. I do not see the removal of intended=20
configuration nodes from operational as a solution worth implementing on=20
our servers. I do not see a real world plug-and-play scenario that can=20
be automatically solved without specific additions to the models e.g.=20
/interfaces/interface/oper-status=3Dnot-present is oversimplified solutio=
n=20
but it needs to be extended exactly as much as the solution provided by=20
the removal of config true; nodes without the sacrifice of YANG validity=20
of operational.

3. Solutions like /interfaces/interface/admin-state stop working. With=20
the interface removed you can no longer figure if the if-mib has or does=20
not have the interface enabled so an operator has to use SNMP or wait=20
for a replacement line card to be connected to figure this bit of=20
information. My interpretation of the MAY as requirement level in sec.=20
5.3. The Operational State Datastore () is that=20
plug-and-play solutions can be implemented without this limited approach=20
that has the same problem as the pre-NMDA only now we have to have=20
/interfaces-state to keep config false; data relevant to hardware that=20
is configured but not present:

 =C2=A0=C2=A0 configuration data nodes supported in a configuration datas=
tore
 =C2=A0=C2=A0 MAY be omitted from  if a server is not able t=
o
 =C2=A0=C2=A0 accurately report them.

I realize this discussion comes late. I have stated my objections to=20
this particular part of the NMDA draft earlier.

Vladimir

> =C2=A0 But I agree that there could be configuration that is referencin=
g=20
> those missing resources, and depending on implementation then that=20
> configuration may need to become not applied as well.=C2=A0 Or perhaps =
the=20
> failure is reported in a different way (e.g. IGP neighbor is down).
>
> I also agree that this is non trivial, but the systems that I am=20
> familiar with have always had to deal with this issue.=C2=A0 At the dat=
a=20
> model level I don't think that this is any more complex than the=20
> existing 'when' statement processing that has exactly the same issues=20
> if a "when" statement becomes invalid during a config change and=20
> requires the associated configuration to be deleted (which again can=20
> recursively require configuration to be removed).
>
> Alternative solutions are:
> =C2=A0- mandate that nobody physically removes a linecard if there is s=
till=20
> configuration referencing it, but it is hard to enforce this in=20
> software :-)
> =C2=A0- freeze the config from any further changes if a linecard is rem=
oved=20
> that makes the config invalid, but this doesn't seem like a robust=20
> solution ...
>
> I think that the existing solution is the best approach.
>
> A couple of further comments inline below as well ...
>
> On 20/12/2017 21:44, Vladimir Vassilev wrote:
>> Hello,
>>
>> On 12/20/2017 05:40 PM, Benoit Claise wrote:
>>
>>> Dear all,
>>>
>>> In order not to be the bottleneck in the process and assuming that=20
>>> the document will be in "publication requested" pretty soon, here is=20
>>> my AD review of draft-ietf-netmod-revised-datastores-08
>>>
>>> -
>>>
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5.3.2. Missing Resources
>>>
>>> =C2=A0=C2=A0=C2=A0 Configuration in  can refer to resources=
 that are not
>>> =C2=A0=C2=A0=C2=A0 available or otherwise not physically present.=C2=A0=
 In these=20
>>> situations,
>>> =C2=A0=C2=A0=C2=A0 these parts of  are not applied.=C2=A0 T=
he data appears in
>>> =C2=A0=C2=A0=C2=A0  but does not appear in .
>>
>> I have some concerns with this section.
>>
>> Systems implementing this are expected to remove config true; nodes=20
>> while figuring the necessary changes to ensure the remaining set of=20
>> config true; nodes in operational validates against the operational=20
>> datastore model. The implementation of this is not a trivial task at=20
>> all. In order to remove configuration nodes considered inactive on=20
>> the fly one needs to remove all references to those nodes in=20
>> mandatory leafrefs in the best case and a potentially long and=20
>> complex dependency chain of YANG constrain-statements (Xpath etc.)=20
>> have to be resolved in a worse case. It is difficult to automate=20
>> this. It requires significant effort to track and remove/fix all=20
>> those dependencies just to come up with valid configuration that=20
>> represents the configuration without the "inactive" nodes which in=20
>> many usecases is completely unjustified implementation effort.
>>
>> In addition in many cases it is not desirable to remove config true;=20
>> nodes that depended on a removed resource. For example:
>>
>> 1. A configuration instance of a filter with mandatory interface-ref=20
>> ingress and egress ports has to be removed from the operational=20
>> datastore if the egress port is removed as a physical resource. This=20
>> in effect removes the config false; statistics that might be still of=20
>> interest counting the matched traffic while the filter does not have=20
>> physical egress port to send the packets.
> This isn't necessarily true.=C2=A0 The architecture does not require th=
at=20
> the filter object is removed because operational is allowed to violate=20
> the constraints.=C2=A0 Ultimately I think that the behaviour here will=20
> depend on implementation.
>
>>
>> 2. Alarm that is configured with mandatory reference to the missing=20
>> resource containing a counter of the elapsed time since the resource=20
>> went missing etc.
> Again, the draft does not require that the alarm becomes not applied.=C2=
=A0=20
> This also depends on the implementation.
>
> Thanks,
> Rob
>
>
>>
>> I do not find any text in the draft addressing the concerns above. I=20
>> do not propose a change yet but I hope to hear what others think=20
>> about that.
>>
>> Vladimir
>>
>>> I understand what you want to say.
>>> Let me take an example. I have a router with a Line Card configured=20
>>> and working well. if I remove the LC, the configuration should still=20
>>> be in the  and  but not in .
>>> However, based on figure below, the notion of "inactive" nodes might=20
>>> be misleading. Indeed, people might read that the LC is inactive, so=20
>>> the LC configuration should not be in 
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------------+=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+-----------+
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |  |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
|  |
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 (ct, rw)=C2=A0=C2=A0 |<---+=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--->| (ct, rw)=C2=A0 |
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------------+=C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 +-----------+
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-----------+=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 +-------->|  |<--------+
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | (ct, rw=
)=C2=A0 |
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------=
---+
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // c=
onfiguration transformations,
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // e=
.g., removal of "inactive"
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // n=
odes, expansion of templates
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 v
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------=
----+
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |  | // subject to validation
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | (ct, ro=
)=C2=A0=C2=A0 |
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 understand that "inactive nodes" has a different meaning.
>>>
>>> Proposal:
>>> OLD: removal of "inactive" nodes
>>> NEW: removal of the nodes marked as "inactive"
>>>
>>> - In the C.1 example,
>>> =C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xmlns=3D"urn:example:syste=
m"
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xmlns:or=3D"urn:ietf:param=
s:xml:ns:yang:ietf-origin">
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bar=

>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 eth0
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 true
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1000
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 100
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2001:db8::=
10
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 

>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2001:db8::=
1:100
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64
>>> =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 guess it "or:dynamic" should be replaced by "or:learned"
>>>
>>> Justification:
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identity learned {
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base origin;
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Denotes confi=
guration learned from protocol interactions=20
>>> with
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other de=
vices, instead of via either the intended
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 configur=
ation datastore or any dynamic configuration
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 datastor=
e.
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Examples=
 of protocols that provide learned configuration
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 include =
link-layer negotiations, routing protocols,_and=20
>>> DHCP._";
>>>
>>> _Editorial:_
>>>
>>> - number the figures
>>>
>>> - section 8.2
>>> =C2=A0=C2=A0 =C2=A0This document registers two YANG modules in the YA=
NG Module Names
>>> =C2=A0=C2=A0=C2=A0 registry [RFC6020 ].=C2=A0=20
>>> Following the format in [RFC6020=20
>>> ], the the
>>> =C2=A0=C2=A0=C2=A0 following registrations are requested:
>>>
>>> duplicated "the the"
>>> =C2=A0 Regards, Benoit (OPS AD)
>>>
>>>
>>> _______________________________________________
>>> 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 Dec 21 05:08:07 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCE21276AF; Thu, 21 Dec 2017 05:08:06 -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 XfeSh3tkOi02; Thu, 21 Dec 2017 05:08:00 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD90127978; Thu, 21 Dec 2017 05:07:59 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id CA026182040F; Thu, 21 Dec 2017 14:07:39 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 1FA9018203F5; Thu, 21 Dec 2017 14:07:37 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund , andy@yumaworks.com
Cc: netmod-chairs@ietf.org, netmod@ietf.org
In-Reply-To: <20171219.212514.769253397796153677.mbj@tail-f.com>
References: <80a900b3-716a-b11f-3472-7cae57662ba4@labn.net>  <20171219.212514.769253397796153677.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod-chairs@ietf.org, netmod@ietf.org
Date: Thu, 21 Dec 2017 14:07:55 +0100
Message-ID: <87d138kz4k.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 13:08:06 -0000

Martin Bjorklund  writes:

> Hi Andy,
>
> Andy Bierman  wrote:
>> Hi,
>> 
>> I have reviewed draft-07 and my previous comments about NMDA have been
>> addressed.
>> 
>> This might be the most important sentence in the draft:
>> 
>> sec. 5.3
>> 
>>    The datastore schema for  MUST be a superset of the
>>    combined datastore schema used in all configuration datastores except
>>    that YANG nodes supported in a configuration datastore MAY be omitted
>>    from  if a server is not able to accurately report them.
>> 
>> The MUST implies that there is no need to design a YANG library that can
>> support
>> an implementation that violates this MUST (i.e., 1 schema tree for the
>> super-set)
>> 
>> The MAY is troublesome because it completely contradicts the conformance
>> expressed
>> in each YANG module supported by the server.  Any data node without any
>> if-feature-stmts is mandatory to implement.
>
> This is required for transition purposes; a server that wants to
> implement  should not have to implement all modules at
> once (as applied config).
>
>> What about config=false subtrees within a config=true subtree?
>> Can they be omitted from  as well, or does the draft just
>> intend to
>> omit the operational value of config=true nodes?  Should be specific.
>
> The text says "nodes supported in a configuration datastore MAY be
> omitted from ".  So it is implicit that it only applies
> to config true nodes (since config false cannot be supported in a
> config ds).  How about:
>
> OLD:
>
>     The datastore schema for  MUST be a superset of the
>     combined datastore schema used in all configuration datastores except
>     that YANG nodes supported in a configuration datastore MAY be omitted
>     from  if a server is not able to accurately report them.
>
> NEW:
>
>     The datastore schema for  MUST be a superset of the
>     combined datastore schema used in all configuration datastores
>     except that YANG "config true" nodes supported in a configuration

If this is about schema or data nodes, I suggest to state it
explicitly:

    ... "config true" schema/data nodes ...

>     datastore MAY be omitted from  if a server is not
>     able to accurately report them.
>
>
>> Perhaps this draft does not need the MAY half of the sentence at all.
>> The YANG library can specify that it is for conformance-reporting, not
>> conformance-defining.
>
> I think we should keep the MAY, since the YANG library has to be
> designed to support this case.

Shouldn't the server add corresponding deviations to the schema for
 in this case?

Lada

>
>
> /martin
>
>
>
>
>> 
>> 
>> 
>> 
>> Andy
>> 
>> 
>> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
>> 
>> > All,
>> >
>> > This starts a second working group last call on
>> > draft-ietf-netmod-revised-datastores.
>> >
>> > As this is a 2nd LC that is focused on changes since the last LC, it
>> > closes in *one* week. The working group last call ends on December 11.
>> > Please send your comments to the netmod mailing list.
>> >
>> > At this point, we're most interested in verifying that previous comments
>> > are addressed since the last call on the -04 rev of the draft was held.
>> >
>> > A summary of changes can be found at
>> > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4
>> >
>> > A diff can be found at
>> > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-
>> > revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt
>> >
>> > Comments along the of: I have reviewed this version of the document and it
>> > addresses my previous comments would be particularly helpful.
>> >
>> > Thank you,
>> > Netmod 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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Dec 21 05:20:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B33312D868 for ; Thu, 21 Dec 2017 05:20:35 -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 Op0Ox9PKH5-O for ; Thu, 21 Dec 2017 05:20: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 6A72E12D867 for ; Thu, 21 Dec 2017 05:20:33 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3B22A731; Thu, 21 Dec 2017 14:20:32 +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 aq59LaczcuWY; Thu, 21 Dec 2017 14:20:31 +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, 21 Dec 2017 14:20:32 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2768620130; Thu, 21 Dec 2017 14:20:32 +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 UQf4N_k0qIUS; Thu, 21 Dec 2017 14:20:31 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CC9E20073; Thu, 21 Dec 2017 14:20:31 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1BBB841F6C1F; Thu, 21 Dec 2017 14:20:30 +0100 (CET)
Date: Thu, 21 Dec 2017 14:20:30 +0100
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Cc: Robert Wilton , NETMOD Working Group 
Message-ID: <20171221132030.7zebh2xkhddmql3c@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Vladimir Vassilev , Robert Wilton , 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>
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: <6e899e21-8931-b61c-3b73-6c8a8a1c912a@transpacket.com>
User-Agent: NeoMutt/20171215
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: Thu, 21 Dec 2017 13:20:35 -0000

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.

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

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

/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 Dec 21 05:25:10 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996C112D867; Thu, 21 Dec 2017 05:25: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 zq-ckajQW1h2; Thu, 21 Dec 2017 05:25:06 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54091127599; Thu, 21 Dec 2017 05:25: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 63FB51AE0311; Thu, 21 Dec 2017 14:25:05 +0100 (CET)
Date: Thu, 21 Dec 2017 14:25:05 +0100 (CET)
Message-Id: <20171221.142505.234244118393393232.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: andy@yumaworks.com, netmod-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87d138kz4k.fsf@nic.cz>
References:  <20171219.212514.769253397796153677.mbj@tail-f.com> <87d138kz4k.fsf@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] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 13:25:09 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi Andy,
> >
> > Andy Bierman  wrote:
> >> Hi,
> >> 
> >> I have reviewed draft-07 and my previous comments about NMDA have been
> >> addressed.
> >> 
> >> This might be the most important sentence in the draft:
> >> 
> >> sec. 5.3
> >> 
> >>    The datastore schema for  MUST be a superset of the
> >>    combined datastore schema used in all configuration datastores except
> >>    that YANG nodes supported in a configuration datastore MAY be omitted
> >>    from  if a server is not able to accurately report them.
> >> 
> >> The MUST implies that there is no need to design a YANG library that can
> >> support
> >> an implementation that violates this MUST (i.e., 1 schema tree for the
> >> super-set)
> >> 
> >> The MAY is troublesome because it completely contradicts the conformance
> >> expressed
> >> in each YANG module supported by the server.  Any data node without any
> >> if-feature-stmts is mandatory to implement.
> >
> > This is required for transition purposes; a server that wants to
> > implement  should not have to implement all modules at
> > once (as applied config).
> >
> >> What about config=false subtrees within a config=true subtree?
> >> Can they be omitted from  as well, or does the draft just
> >> intend to
> >> omit the operational value of config=true nodes?  Should be specific.
> >
> > The text says "nodes supported in a configuration datastore MAY be
> > omitted from ".  So it is implicit that it only applies
> > to config true nodes (since config false cannot be supported in a
> > config ds).  How about:
> >
> > OLD:
> >
> >     The datastore schema for  MUST be a superset of the
> >     combined datastore schema used in all configuration datastores except
> >     that YANG nodes supported in a configuration datastore MAY be omitted
> >     from  if a server is not able to accurately report them.
> >
> > NEW:
> >
> >     The datastore schema for  MUST be a superset of the
> >     combined datastore schema used in all configuration datastores
> >     except that YANG "config true" nodes supported in a configuration
> 
> If this is about schema or data nodes, I suggest to state it
> explicitly:
> 
>     ... "config true" schema/data nodes ...

Yes, the new text uses "configuration data nodes".

> >     datastore MAY be omitted from  if a server is not
> >     able to accurately report them.
> >
> >
> >> Perhaps this draft does not need the MAY half of the sentence at all.
> >> The YANG library can specify that it is for conformance-reporting, not
> >> conformance-defining.
> >
> > I think we should keep the MAY, since the YANG library has to be
> > designed to support this case.
> 
> Shouldn't the server add corresponding deviations to the schema for
>  in this case?

We wanted to explicitly support the case that a server doesn't (yet)
implement a given module with config nodes in operational.  But maybe
we should design for the future and remove the MAY half of the
sentence, as suggested above, and let such servers use deviations in
this case.


/martin




> 
> Lada
> 
> >
> >
> > /martin
> >
> >
> >
> >
> >> 
> >> 
> >> 
> >> 
> >> Andy
> >> 
> >> 
> >> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
> >> 
> >> > All,
> >> >
> >> > This starts a second working group last call on
> >> > draft-ietf-netmod-revised-datastores.
> >> >
> >> > As this is a 2nd LC that is focused on changes since the last LC, it
> >> > closes in *one* week. The working group last call ends on December 11.
> >> > Please send your comments to the netmod mailing list.
> >> >
> >> > At this point, we're most interested in verifying that previous comments
> >> > are addressed since the last call on the -04 rev of the draft was held.
> >> >
> >> > A summary of changes can be found at
> >> > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4
> >> >
> >> > A diff can be found at
> >> > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod-
> >> > revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-07.txt
> >> >
> >> > Comments along the of: I have reviewed this version of the document and it
> >> > addresses my previous comments would be particularly helpful.
> >> >
> >> > Thank you,
> >> > Netmod 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
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Thu Dec 21 06:03:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A084912D873; Thu, 21 Dec 2017 06:03:34 -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 vYCJilwUSFu0; Thu, 21 Dec 2017 06:03:33 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D13C112D7F7; Thu, 21 Dec 2017 06:03:32 -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 A5A841AE0311; Thu, 21 Dec 2017 15:03:30 +0100 (CET)
Date: Thu, 21 Dec 2017 15:03:30 +0100 (CET)
Message-Id: <20171221.150330.1658491882772367375.mbj@tail-f.com>
To: ianfarrer@gmx.com
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org, draft-ietf-netmod-yang-tree-diagrams@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20171221.113947.2011578475461538770.mbj@tail-f.com> <20171221104328.ssex3bvj5zuxsjeo@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] xpaths and Wrapping Long Lines - draft-ietf-netmod-yang-tree-diagrams-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 14:03:34 -0000

Ian Farrer  wrote:
> Thanks. This suggestion seems cleanest. Can the tree diagrams draft
> be updated to describe this?

I suggest we add to the section "Wrapping Long Lines"

NEW:

Long paths (e.g., leafref paths or augment targets) can be split and
printed on more than one line.  For example:

  augment /nat:nat/nat:instances/nat:instance/nat:mapping-table
            /nat:mapping-entry:


then also fix in 2.6:

OLD:

      If the type is a leafref, the type is printed as "-> TARGET",
      where TARGET is either the leafref path, with prefixes removed
      if possible.

NEW:

      If the type is a leafref, the type is either printed as
      "-> TARGET", where TARGET is the leafref path, with prefixes
      removed if possible, or printed as "leafref".
 

FYI, I have fixed pyang so that it breaks long augment targets:

$ pyang -f tree --tree-line-length 55 x.yang 
module: x
  augment /y:pretty-long-identifier-name/y:shorter
            /y:another-long-identifier-name
            /y:also-short/y:but-this-is-long-again:
    +--rw bar?   string



/martin








> 
> BR,
> Ian
> 
> 
> > On 21. Dec 2017, at 11:43, Juergen Schoenwaelder  wrote:
> > 
> > On Thu, Dec 21, 2017 at 11:39:47AM +0100, Martin Bjorklund wrote:
> > 
> >> But this is in the YANG source; I think Ian asked about the tree
> >> diagram syntax.  Maybe the corresponding syntax in the tree diagram
> >> could be simply:
> >> 
> >> augment /nat:nat/nat:instances/nat:instance
> >>        /nat:mapping-table/nat:mapping-entry:
> > 
> > Works for me.
> > 
> >> Or even simpler, maybe we can say that any string in the tree diagram
> >> syntax can follow the YANG string rules.
> > 
> > The YANG string rules are for machines to get the parsing right. Since
> > the tree diagrams are for humans, the less noise the better.
> > 
> > /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
> 


From nobody Thu Dec 21 06:54:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA012D7F7 for ; Thu, 21 Dec 2017 06:53:59 -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 o5TfSPBAQCeI for ; Thu, 21 Dec 2017 06:53:58 -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 8EF9D120724 for ; Thu, 21 Dec 2017 06:53:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2166; q=dns/txt; s=iport; t=1513868037; x=1515077637; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=GWMEEfnzq29l9TOWT85od/mwmVJ+219opJQV66+NRng=; b=X4TI/M31/OsJkPr1KnLKzCC76+rgZCuYp2MuJeexbOo1KpkFXU+Cg4rg h/dx8SbPd/E5i0gUcohPkoHAQrg5LjO9eaLEnqYkGw7DjDs+EPIYOwOdu uh1C2xVf7HdZ0uyxkGqGU9EO6Tg7g0rRa9OCVQmIWcyFRaL4LwyOh8C1/ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQBryjta/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUYJ4QGixiQHZk+CoU7AoUMFQEBAQEBAQEBAWsohSQBBSMVUQs?= =?us-ascii?q?OAggCAiYCAlcGAQwGAgEBiiekZYInim0BAQEBAQEBAwEBAQEBASKBD4Jwg2iCE?= =?us-ascii?q?oMFgzCBTgEBCIMtgmUBBJIdkSuVL4IXigEkhz6OeogFgTs1I4FPMhoIGxWCZYR?= =?us-ascii?q?YQDeHXII7AQEB?=
X-IronPort-AV: E=Sophos;i="5.45,436,1508803200";  d="scan'208";a="1020550"
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; 21 Dec 2017 14:53:43 +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 vBLErhqS001040; Thu, 21 Dec 2017 14:53:43 GMT
To: Martin Bjorklund , netmod@ietf.org
References:  <20171221.123746.382540578845045602.mbj@tail-f.com> <20171221115010.annbhb4vs3roo4dk@elstar.local> <20171221.125826.1295894140821866805.mbj@tail-f.com> <20171221120336.asqnp343in7y26ie@elstar.local>
From: Benoit Claise 
Message-ID: <79cc9570-0bcc-f935-cc3b-4dd5289b4520@cisco.com>
Date: Thu, 21 Dec 2017 15:53:43 +0100
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: <20171221120336.asqnp343in7y26ie@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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, 21 Dec 2017 14:54:00 -0000

On 12/21/2017 1:03 PM, Juergen Schoenwaelder wrote:
> On Thu, Dec 21, 2017 at 12:58:26PM +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder  wrote:
>>> On Thu, Dec 21, 2017 at 12:37:46PM +0100, 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.
>>>>
>>>> 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).
>>> The last sentence is not useful since nobody knows what 'preferred'
>>> value means. So remove it.
>> This text comes from RFC 6933.  Do you really think it is not clear
>> what the intention is?
> I guess I read too fast. No, the sentence is fine. My comment was wrong.
>
> [...]
>   
>> Agreed.  So we'd have a single paragraph:
>>
>>     This leaf can be configured.  The configured value is used only if
>>     the server cannot determine the vendor-specific serial number from
>>     the component itself.
> Yes, I think this covers it.
That works for me.

Regards, B.
>
> /js
>


From nobody Thu Dec 21 06:54:16 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA5412D886 for ; Thu, 21 Dec 2017 06:54: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 CHM9KYT7-Ap4 for ; Thu, 21 Dec 2017 06:54: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 D689112D883 for ; Thu, 21 Dec 2017 06:54:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16323; q=dns/txt; s=iport; t=1513868047; x=1515077647; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=u1WvZutVZLU3gagbrSWXBbdUbEft5koKQRqvPukxajg=; b=BH8RGC6uEFvRuREonm/DS8CMq2jCZMFDO656/nkzedXo7jHV1wQYi3Nr GhQs1elpeMSsLQ1U81BS7j/MTrEiYJkPRajIAv+512I5wk4SRmGOEV8Iy jgRRmYbR3zU80y4faDUekZS+dfoZVO68cTvWagZld+IvKrpxrjK51QHv4 Q=;
X-IronPort-AV: E=Sophos;i="5.45,436,1508803200";  d="scan'208";a="1069259"
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; 21 Dec 2017 14:53:52 +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 vBLErqCj024788; Thu, 21 Dec 2017 14:53:52 GMT
To: Vladimir Vassilev , 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>
From: Robert Wilton 
Message-ID: <537f059a-d2ed-1242-8636-11e5c125e0a2@cisco.com>
Date: Thu, 21 Dec 2017 14:53:52 +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: <6e899e21-8931-b61c-3b73-6c8a8a1c912a@transpacket.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: Thu, 21 Dec 2017 14:54:15 -0000

On 21/12/2017 13:03, 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). 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.
I don't agree with this.  A client can easily see if configuration has 
been applied by looking at the corresponding data node in the 
operational datastore.  If  is fully implemented then this 
applies to any data node in the configuration.


> 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.
I believe that returning the truth is more important that returning 
false information (or no information at all) to satisfy constraints in a 
schema model.

>
> 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.
I think that forcing operational to always be consistent quickly falls 
down as a solution:
  - In the case of a device with multiple linecards you cannot force 
that they are always lockstep in sync with each other.
  - In a case of device with multiple concurrent daemon processes, you 
cannot force that they always all have a consistent view of the 
operational state.
  - When configuration is changing the system may go through transient 
states where the operational state is invalid.
  - The system might run of memory, or daemons crash, or fail, or become 
corrupted, all leaving the system in an invalid operational state.
- You can't stop someone from physical removing an piece of hardware, 
which could immediately make the applied configuration and operational 
state inconsistent (or inaccurate).

If you don't allow invalid states to be reported then you merely prevent 
the client from querying any operational state from the device whilst it 
is an inconsistent state.  I.e. the making the device harder to manage, 
and less maintainable.

The "other mechanism" that you describe above sounds like it requires an 
adhoc solution to this problem for every schema node. The  
datastore solves this problem in a generic way.  A client can always see 
what configuration is currently applied in the system.


>
> 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.
There is somewhat of an implementation choice in this.

The server is obliged to return what is "in use" in operational, but it 
is up to the server vendor to decide what "in use" actually means for a 
particular item of configuration (e.g. for a configured value that might 
be distributed to multiple internal daemons).


> 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. 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:
Admin-status is the intended configuration, clients can always query 
 or  to see the desired state of the system.  They 
can also query  and see that the interface doesn't 
currently exist in the system.  The rest of the properties associated 
with the interface sort of seem a bit irrelevant at that point.

/interfaces-state is deprecated and going away.  Its direct equivalent 
is /interfaces in .  I'm not sure that the semantics 
between the two has necessarily changed very much, except that the NDMA 
architecture now describes a formal mechanism for hardware removal, 
whereas previously it was left entirely to the vendors to each do their 
own thing.

For some of our systems, the applied configuration for a physical 
interface is managed on the linecard hosting that interface.  If that 
linecard is pulled out then all of that applied configuration really has 
gone.  In other cases, a user might remove the optics module for an 
interface, in which case the interface still exists but the interface is 
reported as being operationally down.


>
>    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.
Yes, this discussion does seem very late.

Did you raise your comments during either of the WG LCs?  I thought that 
I had been pretty diligent tracking and replying to all issues that had 
been raised during the WG LC.

Thanks,
Rob


>
> Vladimir
>
>>   But I agree that there could be configuration that is referencing 
>> those missing resources, and depending on implementation then that 
>> configuration may need to become not applied as well.  Or perhaps the 
>> failure is reported in a different way (e.g. IGP neighbor is down).
>>
>> I also agree that this is non trivial, but the systems that I am 
>> familiar with have always had to deal with this issue.  At the data 
>> model level I don't think that this is any more complex than the 
>> existing 'when' statement processing that has exactly the same issues 
>> if a "when" statement becomes invalid during a config change and 
>> requires the associated configuration to be deleted (which again can 
>> recursively require configuration to be removed).
>>
>> Alternative solutions are:
>>  - mandate that nobody physically removes a linecard if there is 
>> still configuration referencing it, but it is hard to enforce this in 
>> software :-)
>>  - freeze the config from any further changes if a linecard is 
>> removed that makes the config invalid, but this doesn't seem like a 
>> robust solution ...
>>
>> I think that the existing solution is the best approach.
>>
>> A couple of further comments inline below as well ...
>>
>> On 20/12/2017 21:44, Vladimir Vassilev wrote:
>>> Hello,
>>>
>>> On 12/20/2017 05:40 PM, Benoit Claise wrote:
>>>
>>>> Dear all,
>>>>
>>>> In order not to be the bottleneck in the process and assuming that 
>>>> the document will be in "publication requested" pretty soon, here 
>>>> is my AD review of draft-ietf-netmod-revised-datastores-08
>>>>
>>>> -
>>>>
>>>>
>>>>         5.3.2. Missing Resources
>>>>
>>>>     Configuration in  can refer to resources that are not
>>>>     available or otherwise not physically present.  In these 
>>>> situations,
>>>>     these parts of  are not applied.  The data appears in
>>>>      but does not appear in .
>>>
>>> I have some concerns with this section.
>>>
>>> Systems implementing this are expected to remove config true; nodes 
>>> while figuring the necessary changes to ensure the remaining set of 
>>> config true; nodes in operational validates against the operational 
>>> datastore model. The implementation of this is not a trivial task at 
>>> all. In order to remove configuration nodes considered inactive on 
>>> the fly one needs to remove all references to those nodes in 
>>> mandatory leafrefs in the best case and a potentially long and 
>>> complex dependency chain of YANG constrain-statements (Xpath etc.) 
>>> have to be resolved in a worse case. It is difficult to automate 
>>> this. It requires significant effort to track and remove/fix all 
>>> those dependencies just to come up with valid configuration that 
>>> represents the configuration without the "inactive" nodes which in 
>>> many usecases is completely unjustified implementation effort.
>>>
>>> In addition in many cases it is not desirable to remove config true; 
>>> nodes that depended on a removed resource. For example:
>>>
>>> 1. A configuration instance of a filter with mandatory interface-ref 
>>> ingress and egress ports has to be removed from the operational 
>>> datastore if the egress port is removed as a physical resource. This 
>>> in effect removes the config false; statistics that might be still 
>>> of interest counting the matched traffic while the filter does not 
>>> have physical egress port to send the packets.
>> This isn't necessarily true.  The architecture does not require that 
>> the filter object is removed because operational is allowed to 
>> violate the constraints.  Ultimately I think that the behaviour here 
>> will depend on implementation.
>>
>>>
>>> 2. Alarm that is configured with mandatory reference to the missing 
>>> resource containing a counter of the elapsed time since the resource 
>>> went missing etc.
>> Again, the draft does not require that the alarm becomes not 
>> applied.  This also depends on the implementation.
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>> I do not find any text in the draft addressing the concerns above. I 
>>> do not propose a change yet but I hope to hear what others think 
>>> about that.
>>>
>>> Vladimir
>>>
>>>> I understand what you want to say.
>>>> Let me take an example. I have a router with a Line Card configured 
>>>> and working well. if I remove the LC, the configuration should 
>>>> still be in the  and  but not in .
>>>> However, based on figure below, the notion of "inactive" nodes 
>>>> might be misleading. Indeed, people might read that the LC is 
>>>> inactive, so the LC configuration should not be in 
>>>>       +-------------+                 +-----------+
>>>>       |  |                 |  |
>>>>       |  (ct, rw)   |<---+       +--->| (ct, rw)  |
>>>>       +-------------+    |       |    +-----------+
>>>>              |           |       |           |
>>>>              |         +-----------+         |
>>>>              +-------->|  |<--------+
>>>>                        | (ct, rw)  |
>>>>                        +-----------+
>>>>                              |
>>>>                              |        // configuration 
>>>> transformations,
>>>>                              |        // e.g., removal of "inactive"
>>>>                              |        // nodes, expansion of templates
>>>>                              v
>>>>                        +------------+
>>>>                        |  | // subject to validation
>>>>                        | (ct, ro)   |
>>>>                        +------------+
>>>> I understand that "inactive nodes" has a different meaning.
>>>>
>>>> Proposal:
>>>> OLD: removal of "inactive" nodes
>>>> NEW: removal of the nodes marked as "inactive"
>>>>
>>>> - In the C.1 example,
>>>>     >>>         xmlns="urn:example:system"
>>>> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>>>>
>>>>       bar
>>>>
>>>>       
>>>>         eth0
>>>>         
>>>>           true
>>>>           1000
>>>>         
>>>>         100
>>>>         

>>>>           2001:db8::10
>>>>           64
>>>>         

>>>>         

>>>>           2001:db8::1:100
>>>>           64
>>>>         

>>>>       
>>>> I guess it "or:dynamic" should be replaced by "or:learned"
>>>>
>>>> Justification:
>>>>
>>>>       identity learned {
>>>>         base origin;
>>>>         description
>>>>           "Denotes configuration learned from protocol interactions 
>>>> with
>>>>            other devices, instead of via either the intended
>>>>            configuration datastore or any dynamic configuration
>>>>            datastore.
>>>>
>>>>            Examples of protocols that provide learned configuration
>>>>            include link-layer negotiations, routing protocols,_and 
>>>> DHCP._";
>>>>
>>>> _Editorial:_
>>>>
>>>> - number the figures
>>>>
>>>> - section 8.2
>>>>     This document registers two YANG modules in the YANG Module Names
>>>>     registry [RFC6020 ].  
>>>> Following the format in [RFC6020 
>>>> ], the the
>>>>     following registrations are requested:
>>>>
>>>> duplicated "the the"
>>>>   Regards, Benoit (OPS AD)
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Dec 21 07:13:48 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB05912D88D for ; Thu, 21 Dec 2017 07:13: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 NsXWi6_i9oAn for ; Thu, 21 Dec 2017 07:13:45 -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 7487B12D886 for ; Thu, 21 Dec 2017 07:13:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8836; q=dns/txt; s=iport; t=1513869224; x=1515078824; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=c35SJTPeRy9/4CnQf/k2oG67u8frGh13vhjIvl8th9g=; b=OCmGZx/iJiuhYYsGjfuCSXojsAPz6a8Hp77ZSX3PictZedOgpXZH0jy3 KJFnRrImum0EpAYnO5dSWrplmzjzN++W9RISec+rckpc0bGpCOGsJ55wj vkdTVwktQmbRzeFEFTGNuvFl3am8mw1mKVCxWWEhnygl6fnrKWYg5+c3u o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQD3zjta/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCeEBosYkB2ZPgoYC4FegmtPAoUMFQEBAQEBAQEBAWsohSM?= =?us-ascii?q?BAQEDAQEBIQ8BBTYbCw4KAgImAgInMAYBDAYCAQEWigkIEKRbgieKbgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgQ+CcINogWkpgwWDLwGBTgEBCIMtgmUFilyHQZE?= =?us-ascii?q?riAGNLoIXigEkhz6NIYFZiAWBOzUjgU8yGggbFTyCKYRXQTeHXII7AQEB?=
X-IronPort-AV: E=Sophos;i="5.45,436,1508803200";  d="scan'208";a="1069550"
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; 21 Dec 2017 15:13: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-1.cisco.com (8.14.5/8.14.5) with ESMTP id vBLFDZ53025390; Thu, 21 Dec 2017 15:13:35 GMT
To: Martin Bjorklund , netmod@ietf.org
References:  <20171220.160020.956270997417344353.mbj@tail-f.com>  <20171221.123746.382540578845045602.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <5aa4a306-7d57-8ad2-7ec0-4a6f59652862@cisco.com>
Date: Thu, 21 Dec 2017 15:13: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: <20171221.123746.382540578845045602.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, 21 Dec 2017 15:13:47 -0000

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


From nobody Thu Dec 21 08:03:27 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5D9126D74; Thu, 21 Dec 2017 08:03:26 -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 K6l5ab-q8uxs; Thu, 21 Dec 2017 08:03: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 55DB1126CD6; Thu, 21 Dec 2017 08:03:23 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:c492:ff:fef1:fb2d]) by mail.nic.cz (Postfix) with ESMTPSA id 98C9863EFA; Thu, 21 Dec 2017 17:03:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513872201; bh=L13vZrfFG67Y+qzTtU59ejT5F/7OV8/eOEEQRV8eGN4=; h=From:To:Date; b=erVtnoUJ5Nl+6NahOoCtkPx0PASvxE1X1fNoxhhEZ9aS48sR9K0u8Vkdh9WbVhllE 2hFrgRcKKzVBIldfNzAqnMUnajYzaC5a0qxEPdXCABVZFfJ/zlU3mWKVKZra9N05cr 8xuGVS1/Crc3p4PZT+Xf5uS0aYUVVh9qaafZrKZs=
Message-ID: <1513872201.18003.1.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: andy@yumaworks.com, netmod-chairs@ietf.org, netmod@ietf.org
Date: Thu, 21 Dec 2017 17:03:21 +0100
In-Reply-To: <20171221.142505.234244118393393232.mbj@tail-f.com>
References:  <20171219.212514.769253397796153677.mbj@tail-f.com> <87d138kz4k.fsf@nic.cz> <20171221.142505.234244118393393232.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 16:03:27 -0000

On Thu, 2017-12-21 at 14:25 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> > 
> > > Hi Andy,
> > >
> > > Andy Bierman  wrote:
> > >> Hi,
> > >> 
> > >> I have reviewed draft-07 and my previous comments about NMDA have been
> > >> addressed.
> > >> 
> > >> This might be the most important sentence in the draft:
> > >> 
> > >> sec. 5.3
> > >> 
> > >>    The datastore schema for  MUST be a superset of the
> > >>    combined datastore schema used in all configuration datastores except
> > >>    that YANG nodes supported in a configuration datastore MAY be omitted
> > >>    from  if a server is not able to accurately report them.
> > >> 
> > >> The MUST implies that there is no need to design a YANG library that can
> > >> support
> > >> an implementation that violates this MUST (i.e., 1 schema tree for the
> > >> super-set)
> > >> 
> > >> The MAY is troublesome because it completely contradicts the conformance
> > >> expressed
> > >> in each YANG module supported by the server.  Any data node without any
> > >> if-feature-stmts is mandatory to implement.
> > >
> > > This is required for transition purposes; a server that wants to
> > > implement  should not have to implement all modules at
> > > once (as applied config).
> > >
> > >> What about config=false subtrees within a config=true subtree?
> > >> Can they be omitted from  as well, or does the draft just
> > >> intend to
> > >> omit the operational value of config=true nodes?  Should be specific.
> > >
> > > The text says "nodes supported in a configuration datastore MAY be
> > > omitted from ".  So it is implicit that it only applies
> > > to config true nodes (since config false cannot be supported in a
> > > config ds).  How about:
> > >
> > > OLD:
> > >
> > >     The datastore schema for  MUST be a superset of the
> > >     combined datastore schema used in all configuration datastores except
> > >     that YANG nodes supported in a configuration datastore MAY be omitted
> > >     from  if a server is not able to accurately report them.
> > >
> > > NEW:
> > >
> > >     The datastore schema for  MUST be a superset of the
> > >     combined datastore schema used in all configuration datastores
> > >     except that YANG "config true" nodes supported in a configuration
> > 
> > If this is about schema or data nodes, I suggest to state it
> > explicitly:
> > 
> >     ... "config true" schema/data nodes ...
> 
> Yes, the new text uses "configuration data nodes".
> 
> > >     datastore MAY be omitted from  if a server is not
> > >     able to accurately report them.
> > >
> > >
> > >> Perhaps this draft does not need the MAY half of the sentence at all.
> > >> The YANG library can specify that it is for conformance-reporting, not
> > >> conformance-defining.
> > >
> > > I think we should keep the MAY, since the YANG library has to be
> > > designed to support this case.
> > 
> > Shouldn't the server add corresponding deviations to the schema for
> >  in this case?
> 
> We wanted to explicitly support the case that a server doesn't (yet)
> implement a given module with config nodes in operational.  But maybe

But with the new schema of YANG library, say Alt B, such a server can simply
omit this module from the schema of , right?

Lada

> we should design for the future and remove the MAY half of the
> sentence, as suggested above, and let such servers use deviations in
> this case.
> 
> 
> /martin
> 
> 
> 
> 
> > 
> > Lada
> > 
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > >> 
> > >> 
> > >> 
> > >> 
> > >> Andy
> > >> 
> > >> 
> > >> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
> > >> 
> > >> > All,
> > >> >
> > >> > This starts a second working group last call on
> > >> > draft-ietf-netmod-revised-datastores.
> > >> >
> > >> > As this is a 2nd LC that is focused on changes since the last LC, it
> > >> > closes in *one* week. The working group last call ends on December 11.
> > >> > Please send your comments to the netmod mailing list.
> > >> >
> > >> > At this point, we're most interested in verifying that previous
> comments
> > >> > are addressed since the last call on the -04 rev of the draft was held.
> > >> >
> > >> > A summary of changes can be found at
> > >> > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU
> 4
> > >> >
> > >> > A diff can be found at
> > >> > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod
> -
> > >> > revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-
> 07.txt
> > >> >
> > >> > Comments along the of: I have reviewed this version of the document and
> it
> > >> > addresses my previous comments would be particularly helpful.
> > >> >
> > >> > Thank you,
> > >> > Netmod 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
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Dec 21 08:05:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E629E126D74; Thu, 21 Dec 2017 08:05: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, 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 yo8H3powxgjZ; Thu, 21 Dec 2017 08:05:31 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB21126CD6; Thu, 21 Dec 2017 08:05:31 -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 B372C1AE0311; Thu, 21 Dec 2017 17:05:30 +0100 (CET)
Date: Thu, 21 Dec 2017 17:05:30 +0100 (CET)
Message-Id: <20171221.170530.2292499981096143243.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: andy@yumaworks.com, netmod-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1513872201.18003.1.camel@nic.cz>
References: <87d138kz4k.fsf@nic.cz> <20171221.142505.234244118393393232.mbj@tail-f.com> <1513872201.18003.1.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] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 16:05:34 -0000

Ladislav Lhotka  wrote:
> On Thu, 2017-12-21 at 14:25 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Martin Bjorklund  writes:
> > > 
> > > > Hi Andy,
> > > >
> > > > Andy Bierman  wrote:
> > > >> Hi,
> > > >> 
> > > >> I have reviewed draft-07 and my previous comments about NMDA have been
> > > >> addressed.
> > > >> 
> > > >> This might be the most important sentence in the draft:
> > > >> 
> > > >> sec. 5.3
> > > >> 
> > > >>    The datastore schema for  MUST be a superset of the
> > > >>    combined datastore schema used in all configuration datastores except
> > > >>    that YANG nodes supported in a configuration datastore MAY be omitted
> > > >>    from  if a server is not able to accurately report them.
> > > >> 
> > > >> The MUST implies that there is no need to design a YANG library that can
> > > >> support
> > > >> an implementation that violates this MUST (i.e., 1 schema tree for the
> > > >> super-set)
> > > >> 
> > > >> The MAY is troublesome because it completely contradicts the conformance
> > > >> expressed
> > > >> in each YANG module supported by the server.  Any data node without any
> > > >> if-feature-stmts is mandatory to implement.
> > > >
> > > > This is required for transition purposes; a server that wants to
> > > > implement  should not have to implement all modules at
> > > > once (as applied config).
> > > >
> > > >> What about config=false subtrees within a config=true subtree?
> > > >> Can they be omitted from  as well, or does the draft just
> > > >> intend to
> > > >> omit the operational value of config=true nodes?  Should be specific.
> > > >
> > > > The text says "nodes supported in a configuration datastore MAY be
> > > > omitted from ".  So it is implicit that it only applies
> > > > to config true nodes (since config false cannot be supported in a
> > > > config ds).  How about:
> > > >
> > > > OLD:
> > > >
> > > >     The datastore schema for  MUST be a superset of the
> > > >     combined datastore schema used in all configuration datastores except
> > > >     that YANG nodes supported in a configuration datastore MAY be omitted
> > > >     from  if a server is not able to accurately report them.
> > > >
> > > > NEW:
> > > >
> > > >     The datastore schema for  MUST be a superset of the
> > > >     combined datastore schema used in all configuration datastores
> > > >     except that YANG "config true" nodes supported in a configuration
> > > 
> > > If this is about schema or data nodes, I suggest to state it
> > > explicitly:
> > > 
> > >     ... "config true" schema/data nodes ...
> > 
> > Yes, the new text uses "configuration data nodes".
> > 
> > > >     datastore MAY be omitted from  if a server is not
> > > >     able to accurately report them.
> > > >
> > > >
> > > >> Perhaps this draft does not need the MAY half of the sentence at all.
> > > >> The YANG library can specify that it is for conformance-reporting, not
> > > >> conformance-defining.
> > > >
> > > > I think we should keep the MAY, since the YANG library has to be
> > > > designed to support this case.
> > > 
> > > Shouldn't the server add corresponding deviations to the schema for
> > >  in this case?
> > 
> > We wanted to explicitly support the case that a server doesn't (yet)
> > implement a given module with config nodes in operational.  But maybe
> 
> But with the new schema of YANG library, say Alt B, such a server can simply
> omit this module from the schema of , right?

Right; note that this document specifies the requirements, and yang
library is designed accordingly.


/martin


> 
> Lada
> 
> > we should design for the future and remove the MAY half of the
> > sentence, as suggested above, and let such servers use deviations in
> > this case.
> > 
> > 
> > /martin
> > 
> > 
> > 
> > 
> > > 
> > > Lada
> > > 
> > > >
> > > >
> > > > /martin
> > > >
> > > >
> > > >
> > > >
> > > >> 
> > > >> 
> > > >> 
> > > >> 
> > > >> Andy
> > > >> 
> > > >> 
> > > >> On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:
> > > >> 
> > > >> > All,
> > > >> >
> > > >> > This starts a second working group last call on
> > > >> > draft-ietf-netmod-revised-datastores.
> > > >> >
> > > >> > As this is a 2nd LC that is focused on changes since the last LC, it
> > > >> > closes in *one* week. The working group last call ends on December 11.
> > > >> > Please send your comments to the netmod mailing list.
> > > >> >
> > > >> > At this point, we're most interested in verifying that previous
> > comments
> > > >> > are addressed since the last call on the -04 rev of the draft was held.
> > > >> >
> > > >> > A summary of changes can be found at
> > > >> > https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU
> > 4
> > > >> >
> > > >> > A diff can be found at
> > > >> > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-netmod
> > -
> > > >> > revised-datastores-04.txt&url2=draft-ietf-netmod-revised-datastores-
> > 07.txt
> > > >> >
> > > >> > Comments along the of: I have reviewed this version of the document and
> > it
> > > >> > addresses my previous comments would be particularly helpful.
> > > >> >
> > > >> > Thank you,
> > > >> > Netmod 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
> > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Thu Dec 21 10:45:49 2017
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 091A2126BF7; Thu, 21 Dec 2017 10:45:48 -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.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151388194798.12887.883819283399476827@ietfa.amsl.com>
Date: Thu, 21 Dec 2017 10:45:48 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-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: Thu, 21 Dec 2017 18:45:48 -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-09.txt
	Pages           : 38
	Date            : 2017-12-21

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-09
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-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 Thu Dec 21 10:53:01 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A2129C5D for ; Thu, 21 Dec 2017 10:53: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 EGIBpyxHNMk9 for ; Thu, 21 Dec 2017 10:52:57 -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 65614124BE8 for ; Thu, 21 Dec 2017 10:52:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7A48433E087F; Thu, 21 Dec 2017 19:52:55 +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 FwNnsn3mZ7at; Thu, 21 Dec 2017 19:52:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4F34333E0881; Thu, 21 Dec 2017 19:52: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 Yvb20V8oiyd8; Thu, 21 Dec 2017 19:52:55 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 22E7833E0879; Thu, 21 Dec 2017 19:52:55 +0100 (CET)
To: Juergen Schoenwaelder , 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>
From: Vladimir Vassilev 
Message-ID: 
Date: Thu, 21 Dec 2017 19:52:54 +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: <20171221132030.7zebh2xkhddmql3c@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
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: Thu, 21 Dec 2017 18:53:00 -0000

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/intend=
ed
>>> at all.=C2=A0 The contents of running/intended do not change in anywa=
y
>>> depending on whether hardware is present or absent.
>>>
>>> The section is only concerned with how the configuration is applied i=
n
>>> operational, and basically says that you cannot apply configuration f=
or
>>> resources that are missing (which seems reasonable).=C2=A0 E.g. I can=
not
>>> 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 datast=
ore is
>> unacceptable price. Pre-NMDA devices had full model support in operati=
onal
>> data (all YANG constrains part of the model without discrimination wer=
e
>> 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=20
can. If not a better model is needed not a hack that breaks the=20
datastore conformance to the YANG model. I do not see how=20
/interfaces/interface/oper-status=3Dnot-present was not representing the=20
reality of a system with removed line card that is configured and ready=20
to resume operation as soon as the line card is reconnected.
>> If this is about to change it will compromise interoperability
>> and a significant portion of the client implementation workload that c=
an be
>> automated will need to be coded in hand and tested. Unresolved leafref=
s,
>> 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 w=
hen
>> one considers types like leafref, instance-identifier etc.) and the
>> corresponding side effects based on the server implementators own crea=
tivity
>> 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 v=
alid
>> YANG data tree and it has to be a system implementation task to consid=
er all
>> complications resulting from the removal of the resources leading to a=
ny
>> data transformations. If this is difficult or impossible other mechani=
sms to
>> flag missing resources should be used (e.g.
>> /interfaces/interface/oper-status=3Dnot-present) This sounds like a us=
eful
>> 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-present is oversimplified solu=
tion but
>> it needs to be extended exactly as much as the solution provided by th=
e
>> removal of config true; nodes without the sacrifice of YANG validity o=
f
>> 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.=20
merge /interfaces-state in /interfaces) comes from the revised=20
datastores draft not me.

By definition config true; data represents intent. Reusing the model of=20
a config true; data to represent state absent of intent (e.g.=20
/interfaces/interface with origin=3D"or:system") is a hack. The hack work=
s=20
fine without compromising the conformance of operational to the YANG=20
model as long as certain conditions are met. I am pointing out that one=20
of the conditions is to keep all of the intended configuration data=20
present in 'operational' and handle missing resources with conventional=20
means e.g. /interfaces/interface/oper-status=3Dnot-present instead of=20
adding the straw that breaks the camel's back.

>> 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 n=
ot
>> 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 informatio=
n.
> 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 Operat=
ional
>> 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 fal=
se;
>> data relevant to hardware that is configured but not present:
>>
>>  =C2=A0=C2=A0 configuration data nodes supported in a configuration da=
tastore
>>  =C2=A0=C2=A0 MAY be omitted from  if a server is not abl=
e to
>>  =C2=A0=C2=A0 accurately report them.
>>
>> I realize this discussion comes late. I have stated my objections to t=
his
>> 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=20
different from "state of hardware that is not present". For example=20
information indicating when the line card became unavailable, what was=20
the reason, or other information like how many packets that had this=20
interface as egress destination are being dropped as a result of the=20
removal.

Vladimir

>
> /js
>


From nobody Thu Dec 21 11:12:18 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCB112D775 for ; Thu, 21 Dec 2017 11:12:17 -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 LOLf7E9_yYJ1 for ; Thu, 21 Dec 2017 11:12:14 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 B40C1124BE8 for ; Thu, 21 Dec 2017 11:12:14 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 5C6231409CA for ; Thu, 21 Dec 2017 12:11:57 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id ojBt1w00h2SSUrH01jBwmH; Thu, 21 Dec 2017 12:11:57 -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=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=boBhL_nzqcWGAuqIPyoA:9 a=QEXdDO2ut3YA:10 a=jM_x9b4JT8QA: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: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=7t1noFCiU6YAqeU84ROxowEAkevMio0Ly5yOvXNljpo=; b=g5ZNIrZJNM2vV9RPxAFLbtD5NK UrHKJOxNMT21D/4FuIrPPv5Wyvgh4kk354BMGTT/u54jv8Cnsw6C9JGcPWzQHGgcFeG7KLP+IuAM9 ezpOvgkIzw1Qv7F0tkCqAQJ8k;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:55606 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eS6G1-003ZwV-Ce for netmod@ietf.org; Thu, 21 Dec 2017 12:11:53 -0700
To: netmod@ietf.org
References: <151388194798.12887.883819283399476827@ietfa.amsl.com>
From: Lou Berger 
Message-ID: 
Date: Thu, 21 Dec 2017 14:11:52 -0500
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: <151388194798.12887.883819283399476827@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
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: 1eS6G1-003ZwV-Ce
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]:55606
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-09.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, 21 Dec 2017 19:12:17 -0000

Just an FYI - I requested that the authors republish so that all could
see the current state of the document.  I note that a post-LC
discussions is taking place and I leave it to the AD to decide how he'd
like to handle it, e.g., as part of WG LC or as an early IETF LC comment.

Lou

(as Shepherd)


On 12/21/2017 1:45 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 Management Datastore Architecture
>         Authors         : Martin Bjorklund
>                           Juergen Schoenwaelder
>                           Phil Shafer
>                           Kent Watsen
>                           Robert Wilton
> 	Filename        : draft-ietf-netmod-revised-datastores-09.txt
> 	Pages           : 38
> 	Date            : 2017-12-21
>
> 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-09
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-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/
>
> _______________________________________________
> 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
>


From nobody Thu Dec 21 11:18:44 2017
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 59D7112D946; Thu, 21 Dec 2017 11:18:40 -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.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151388392032.12921.9552961903551222910@ietfa.amsl.com>
Date: Thu, 21 Dec 2017 11:18:40 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-entity-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, 21 Dec 2017 19:18:40 -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-07.txt
	Pages           : 55
	Date            : 2017-12-21

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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 Dec 21 11:22:42 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072C4129C6F for ; Thu, 21 Dec 2017 11:22:41 -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 Tykzs6O_eaiP for ; Thu, 21 Dec 2017 11:22:39 -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 8A1BA129C6D for ; Thu, 21 Dec 2017 11:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2845; q=dns/txt; s=iport; t=1513884158; x=1515093758; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1dnMb3SBbgWA/mQnheZQXx5w/9MXOVdiU9V87JGTStk=; b=LBSaS1yzW/wdeazkKMY++g3PoSPcflIXIEETJhcU6Ne7CTHoQBiafTpS qIFyyOVW9ZTCK/Q7yom79nIACSwvXdjdv3qOKFT3XgO5IM6uowRoxyNDe 4Rx6jMdKT5/MFAIQD6jLZGVT6uOllC9Mt0I0P/zhx7BBKiRlHjDq4imDZ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADICDxa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdCeEBookdJAdlykUggEKGA2ER08ChQkYAQEBAQEBAQEBayi?= =?us-ascii?q?FJAEBBAEBIQ8BBTQCGwsOBAYCAiYCAiciDgYBDAYCAQEFiiIQpEyCJ4puAQEBA?= =?us-ascii?q?QEBAQECAQEBAQEBAQEBH4EPgnCDaIFpKYMFgyQLAQEXgR6DT4JlBaNIiAGDJYo?= =?us-ascii?q?JghdlhTCDbIdijSF/WogFgTsfOYFPMhoIGxUYJIIpCYRPQDcBig4BAQE?=
X-IronPort-AV: E=Sophos;i="5.45,437,1508803200";  d="scan'208";a="1071239"
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; 21 Dec 2017 19:22:36 +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 vBLJMaub019948; Thu, 21 Dec 2017 19:22:36 GMT
To: Lou Berger , netmod@ietf.org
References: <151388194798.12887.883819283399476827@ietfa.amsl.com> 
From: Benoit Claise 
Message-ID: 
Date: Thu, 21 Dec 2017 20:22:36 +0100
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] I-D Action: draft-ietf-netmod-revised-datastores-09.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, 21 Dec 2017 19:22:41 -0000

Dear all,

We all know it's important to deliver NMDA soon.
I'm sending this document to IETF LC now, till Jan 10th.
If Vladimir's concern needs to be discussed further, let's do so part 
the IETF LC.

Regards, Benoit
> Just an FYI - I requested that the authors republish so that all could
> see the current state of the document.  I note that a post-LC
> discussions is taking place and I leave it to the AD to decide how he'd
> like to handle it, e.g., as part of WG LC or as an early IETF LC comment.
>
> Lou
>
> (as Shepherd)
>
>
> On 12/21/2017 1:45 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 Management Datastore Architecture
>>          Authors         : Martin Bjorklund
>>                            Juergen Schoenwaelder
>>                            Phil Shafer
>>                            Kent Watsen
>>                            Robert Wilton
>> 	Filename        : draft-ietf-netmod-revised-datastores-09.txt
>> 	Pages           : 38
>> 	Date            : 2017-12-21
>>
>> 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-09
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-09
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-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/
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Dec 21 11:23:37 2017
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 B50F3124E15; Thu, 21 Dec 2017 11:23:34 -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.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org, Lou Berger ,  bclaise@cisco.com, lberger@labn.net
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151388421473.12936.719186167168412861.idtracker@ietfa.amsl.com>
Date: Thu, 21 Dec 2017 11:23:34 -0800
Archived-At: 
Subject: [netmod] Last Call:  (Network Management Datastore Architecture) 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: Thu, 21 Dec 2017 19:23:35 -0000

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/ballot/


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





From nobody Thu Dec 21 12:25:08 2017
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 5457012D0C3; Thu, 21 Dec 2017 12:25:06 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Bjorklund 
To: 
Cc: draft-ietf-netmod-rfc8022bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151388790632.12826.12998477680281212918@ietfa.amsl.com>
Date: Thu, 21 Dec 2017 12:25:06 -0800
Archived-At: 
Subject: [netmod] Yangdoctors early review of draft-ietf-netmod-rfc8022bis-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, 21 Dec 2017 20:25:06 -0000

Reviewer: Martin Bjorklund
Review result: Ready with Nits

Hi,

I have reviewed this document mainly from a NMDA perspective.  As
expected, the YANG model follows all conventions and looks good in
general.  Most of my comments below relate to NMDA terminology.



o  Abstract and Introdcution

Both these has:

   The main difference from the first version is that this version fully
   conforms to the Network Management Datastore Architecture (NMDA).
   Consequently, this document obsoletes RFC 8022.

But this is a bit w/o context - no "first version" is mentioned.
Maybe:

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


o  Terminology

The term "state data" is imported from 7950, but this is not correct,
it is actually defined in 6241.  But I suggest you remove this term,
and instead use the terms defined in the NMDA document.  Actually,
most of the rest of my comments below is about this terminology usage.


o  Section 2.1

OLD:

   user-controlled entry:  An entry of a list in operational state data

NEW:

   user-controlled entry:  An entry of a list in operational state



o  Section 4.1

Use the imported terms "intended configuration" and "operational
state" consistently:


OLD:

   In such a list, the server creates the required item as a so-called
   system-controlled entry in state data in the operational state
   datastore [I-D.ietf-netmod-revised-datastores], i.e., inside read-
   only lists in the "routing" container.

NEW:

   In such a list, the server creates the required item as a so-called
   system-controlled entry in the operational state,
   i.e., inside read-only lists
   in the "routing" container.

(the reference isn't needed here, the term is imported in the
Terminology section)


OLD:

   Additional entries may be created in the configuration by a client,
   e.g., via the NETCONF protocol.  These are so-called
   user-controlled entries.  If the server accepts a configured
   user-controlled entry, then this entry also appears in the state
   data version of the list.

NEW:

   Additional entries may be created in the configuration by a client,
   e.g., via the NETCONF protocol.  These are so-called
   user-controlled entries.  If the server accepts a configured
   user-controlled entry, then this entry also appears in the
   operaitonal state version of the list.


OLD:

   Corresponding entries in both versions of the list (in operational
   state datastore and intended datastore

NEW:

   Corresponding entries in both versions of the list (in the intended
   configuration and the operational state)


OLD:

   In order to bind this entry to the corresponding entry in the state
   data list in the operational state datastore, the key of the
   configuration entry has to be set to the same value as the key of
   the state entry.

NEW:

   In order to bind this entry to the corresponding entry in the
   operational state, the key of the configuration entry has to be set
   to the same value as the key of the operational state entry.


OLD:

   Deleting a user-controlled entry from the configuration list results
   in the removal of the corresponding entry in the state data list.  In
   contrast, if client delets a system-controlled entry from the
   configuration list in the intended datastore, only the extra
   configuration specified in that entry is removed but the
   corresponding state data entry remains in the list in the operational
   datastore.

NEW:

   Deleting a user-controlled entry from the intended configuration
   results in the removal of the corresponding entry in the
   operational state list.  In contrast, if client deletes a
   system-controlled entry from the intended configuration, only the
   extra configuration specified in that entry is removed but the
   corresponding operational state entry is not removed.


o  Section 5.2

OLD:

   Routes are primarily state data that appear as entries of RIBs

NEW:

   Routes are primarily system state that appear as entries of RIBs


OLD:

   In the core routing data model, RIBs are state data represented as
   entries of the list "/routing/ribs/rib" in the operational state
   datastore [I-D.ietf-netmod-revised-datastores].

NEW:

   In the core routing data model, RIBs are represented as entries of
   the list "/routing/ribs/rib" in the operational state.


o  Section 5.3.2

OLD:

   It is expected that future YANG modules will create data models for
   additional control-plane protocol types.  Such a new module has to
   define the protocol-specific configuration and state data, and it has
   to integrate it into the core routing framework in the following way:

NEW:

   It is expected that future YANG modules will create data models for
   additional control-plane protocol types.  Such a new module has to
   define the protocol-specific data nodes, and it has
   to integrate it into the core routing framework in the following way:


OLD:

   o  Additional route attributes MAY be defined, preferably in one
      place by means of defining a YANG grouping.  The new attributes
      have to be inserted by augmenting the definitions of the node

       /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route

      and possibly other places in the configuration, state data,
      notifications, and input/output parameters of actions or RPC
      operations.

   o  Configuration parameters and/or state data for the new protocol
      can be defined by augmenting the "control-plane-protocol" data
      node under "/routing".

   By using a "when" statement, the augmented configuration parameters
   and state data specific to the new protocol SHOULD be made
   conditional and valid only if the value of "rt:type" or
   "rt:source-protocol" is equal to (or derived from) the new protocol's
   identity.

NEW:

   o  Additional route attributes MAY be defined, preferably in one
      place by means of defining a YANG grouping.  The new attributes
      have to be inserted by augmenting the definitions of the node

       /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route

      and possibly other places in the schema tree.

   o  Data nodes for the new protocol
      can be defined by augmenting the "control-plane-protocol" data
      node under "/routing".

   By using a "when" statement, the augmented data nodes
   specific to the new protocol SHOULD be made
   conditional and valid only if the value of "rt:type" or
   "rt:source-protocol" is equal to (or derived from) the new protocol's
   identity.


o  Section 5.4

OLD:

   YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is
   a submodule of the "ietf-ipv6-unicast-routing" module, augments the
   configuration and state data of IPv6 interfaces with definitions of
   the following variables as required by Section 6.2.1 of [RFC4861]:

NEW:

   YANG module "ietf-ipv6-router-advertisements" (Section 9.1), which is
   a submodule of the "ietf-ipv6-unicast-routing" module, augments the
   schema tree of IPv6 interfaces with definitions of
   the following variables as required by Section 6.2.1 of [RFC4861]:


o  In ietf-routing

  feature router-id {
    description
      "This feature indicates that the server supports configuration
       of an explicit 32-bit router ID that is used by some routing
       protocols.

and

  container routing {
    description
      "Configuration parameters for the routing subsystem.";
    uses router-id {
      if-feature "router-id";
      description
        "Configuration of the global router ID.  Routing protocols
         that use router ID can use this parameter or override it
         with another value.";

This design actually works:

If a server supports configuration of router-id, it would advertise
the feature "router-id" in the schema for the conventional
configuration datastores, and in the schema for the operational state
datastore.

If a server does not support the configuration of the router-id, it
would have to advertise this feature in the schema for the operational
datastore (but not for conventional).

But if you want to keep this design, the description of the feature
has to change - it is no longer about "configuration", but rather just
"support".


o  In ietf-routing

The description of several nodes says: "Configuration of" or
"Configuration parameters for".  This needs to change; it is not just
about configuration.  This applies to several nodes in the modules.


o  In ietf-routing

OLD:

  grouping next-hop-state-content {
    description
      "Generic parameters of next hops in state data.";
    choice next-hop-options {
      mandatory "true";
      description
        "Options for next hops in state data.

NEW:

  grouping next-hop-state-content {
    description
      "Generic state parameters of next hops.";
    choice next-hop-options {
      mandatory "true";
      description
        "Options for next hops.

OLD:

          description
            "The name of the RIB.

             For system-controlled entries, the value of this leaf
             must be the same as the name of the corresponding entry
             in state data.

NEW:

          description
            "The name of the RIB.

             For system-controlled entries, the value of this leaf
             must be the same as the name of the corresponding entry
             in operational state.


o  In all YANG modules except ietf-routing

In the module description:

OLD:

     This YANG module augments the 'ietf-routing' module with basic
     configuration and state data for IPv4 unicast routing.

NEW:

     This YANG module augments the 'ietf-routing' module with basic
     parameters for IPv4 unicast routing.
     
(or maybe s/parameters/data nodes/)

There's a similar statement in all modules.


o  In all the YANG modules

This is minor, but it sticks out:

OLD:

    description "A Network Management Datastore Architecture (NDMA)
                 compatible version of the ietf-interfaces module
                 is required.";


NEW:

    description
      "A Network Management Datastore Architecture (NDMA)
       compatible version of the ietf-interfaces module
       is required.";

There are similar statements in all modules.


o  Section 11

OLD:

   The YANG module specified in this document defines a schedma for data

NEW:

   The YANG modules specified in this document define a schema for data



o  Appendix D

OLD:

   This section contains an example of an instance data tree in the JSON
   encoding [RFC7951], containing both configuration and state data.

NEW:

   This section contains an example of an instance data tree from the
   operational state, in the JSON encoding [RFC7951]



/martin



From nobody Thu Dec 21 13:07:42 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C897912D7E2 for ; Thu, 21 Dec 2017 13:07:40 -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 6mJtTlmO5yrC for ; Thu, 21 Dec 2017 13:07:39 -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 0C3DA1205F1 for ; Thu, 21 Dec 2017 13:07:39 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 84FB7175D46 for ; Thu, 21 Dec 2017 14:07:38 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id ol7a1w00i2SSUrH01l7dgX; Thu, 21 Dec 2017 14:07:38 -0700
X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=c309fuS5OrV3TuQLdlEA: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: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=6+vZCb4qAyxTJ4V4AKXX1K1gSLit/R8QJgRC4kfOReY=; b=QQK6Z9EjqjP1ISLbc7y/HCVprc RczmSiPatIrvNfsTa4GG1N2td3vyTqTKF+HhnaNl2eOl6ri4cG8xdKQXITI/v5ALfpeL+xHjthjPo A/8kbRMJ/KT/3TNAjYz8ebThH;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:36434 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eS83y-0003Jg-Ix; Thu, 21 Dec 2017 14:07:34 -0700
To: joel jaeggli , draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org
References: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com>
From: Lou Berger 
Message-ID: <255ae0d8-6ba4-9bb1-49e3-c23dc42171bc@labn.net>
Date: Thu, 21 Dec 2017 16:07:33 -0500
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: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: 1eS83y-0003Jg-Ix
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]:36434
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2017 21:07:41 -0000

No, I'm not aware of any IPR that applies to this draft

Lou
(co-author)

On 12/19/2017 1:39 PM, joel jaeggli wrote:
> Authors, Contributors, WG,
>
> As part of the preparation for WG Last Call:
>
> 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.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Dec 21 14:22:59 2017
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 99A8F124239; Thu, 21 Dec 2017 14:22: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.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: netmod-chairs@ietf.org, netmod@ietf.org, Lou Berger , bclaise@cisco.com, draft-ietf-netmod-entity@ietf.org, lberger@labn.net
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151389497762.28118.16231694341929195271.idtracker@ietfa.amsl.com>
Date: Thu, 21 Dec 2017 14:22:57 -0800
Archived-At: 
Subject: [netmod] Last Call:  (A YANG Data Model for Hardware Management) 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: Thu, 21 Dec 2017 22:22:58 -0000

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 Dec 21 14:25:43 2017
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 C83FC127867; Thu, 21 Dec 2017 14:25:40 -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.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151389514078.28114.2420164679470774366@ietfa.amsl.com>
Date: Thu, 21 Dec 2017 14:25:40 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-04.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, 21 Dec 2017 22:25:41 -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-04.txt
	Pages           : 13
	Date            : 2017-12-21

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-04
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-04


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Dec 21 14:27:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1F124239 for ; Thu, 21 Dec 2017 14:27:48 -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 C3PeELGWsIDc for ; Thu, 21 Dec 2017 14:27: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 1C258120454 for ; Thu, 21 Dec 2017 14:27: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 E117EED7; Thu, 21 Dec 2017 23:27: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 I41CNkp1E3WP; Thu, 21 Dec 2017 23:27:42 +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, 21 Dec 2017 23:27:43 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD09B20130; Thu, 21 Dec 2017 23:27: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 b0aKnjaVcb_B; Thu, 21 Dec 2017 23:27:42 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8517B20073; Thu, 21 Dec 2017 23:27:42 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5EBB541F752E; Thu, 21 Dec 2017 23:27:42 +0100 (CET)
Date: Thu, 21 Dec 2017 23:27:42 +0100
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Cc: NETMOD Working Group 
Message-ID: <20171221222742.izrmwpbiwgoc7col@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Vladimir Vassilev , 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> 
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] 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: Thu, 21 Dec 2017 22:27:48 -0000

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         


From nobody Thu Dec 21 14:50:07 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D281201F2 for ; Thu, 21 Dec 2017 14:50:06 -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 97wXAtpvCVpG for ; Thu, 21 Dec 2017 14:50:03 -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 800A91200C5 for ; Thu, 21 Dec 2017 14:50:02 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id c19so9722304lfg.3 for ; Thu, 21 Dec 2017 14:50:02 -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=/8gKGoYKheamw9+4sep2/0vmhZ7G2rDIf6aRObibprE=; b=CrS3mKrd1/8IsYtfse2aDZ7bXMmsUqM6qO2xpRksc88wBnIQ9yIhsZiOTFfv7RqQD5 F7tvPCn1EPsspaSRElmPpQXdLuSWI+LL8PzMOqFlsjERgzTYiV3bQAvELHuaN29TkOFk 6OMkrSnWsXaPh0+Id4B5xpYB8QtrQPttRgSaqWp6+Ht7ORtKsgEdbG3E+sHUm2s6rGKa tAI6NxMY6jdMwBU1oxYEWw0Jm3/UVJ7YLUWdAqPGF2Am3XumgRvy3uZTlebmJmXiNwJB 9iRQb4svATfccgUxxL7jFtVjIgJY00ro+9MXkQuOJSvHoxjJ+FWRGaIHKtVvddakGUSJ uXTQ==
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=/8gKGoYKheamw9+4sep2/0vmhZ7G2rDIf6aRObibprE=; b=bqM1LreXiVQ/eXpajNJwSGNcsZz7CjuvN7TLz7iU3+WmJt9p4539OFHNzxQMpIttZk Vjv767kr8X7i3sHHmypBd3URutxcLOeQAGz9g1UTQOV2qd2O8YIU4UBT5mMjpjPIIMsa 0vX563/r8PQ77bMGCyRkwUv/NG59tggQN2ejNA2CNjUNbiK3x7z2VA1d/Ngrgvdd5vKK gz/hfTw+f3E/Qe9/1xpY9BTuTX7XWUvaA6pXsfNPc3tBWCHdJtKg3jWVebs8D4kYQGDZ MISauqMmW45C+VJiz9FuYu4AhPHQinkRKI88rH1W+7TsnUnHDUUf2KkoppxctLPNug6s sc9w==
X-Gm-Message-State: AKGB3mJnf4qUrWh/3yscmtxUeUuUmlA+lqD6Qv6JGO456TlsJ33P8Ku3 MCj+6LkhSAi+/6fdxmSMsl9+XzL/NFY7Z5YDf/R07g==
X-Google-Smtp-Source: ACJfBout+qT7MHxDxl88cYcqMzoZ0sdWQ2A/F33ivoGb7BxVLNX+REmI5p2+mhVUe3vbnJI1Y1ssKDvmAxMwvznT0XY=
X-Received: by 10.46.83.9 with SMTP id h9mr7635819ljb.68.1513896600642; Thu, 21 Dec 2017 14:50:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Thu, 21 Dec 2017 14:49:59 -0800 (PST)
In-Reply-To: <20171221222742.izrmwpbiwgoc7col@elstar.local>
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: Thu, 21 Dec 2017 14:49:59 -0800
Message-ID: 
To: Juergen Schoenwaelder ,  Vladimir Vassilev , NETMOD Working Group 
Content-Type: multipart/alternative; boundary="f4030436096e1bbab90560e185cd"
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: Thu, 21 Dec 2017 22:50:06 -0000

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

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
>

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


Hi,

It should be clear somehow that ser=
ver requirements to provide config=3Dfalse data
that is valid acc=
ording to the YANG definitions is not affected by NMDA.
That is n=
ot being taken away.=C2=A0 The ability to validate operational values
=

of configuration data has never been provided, and therefore is not be=
ing taken away either.

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


Andy



On Thu, De=
c 21, 2017 at 2:27 PM, Juergen Schoenwaelder <j.schoen=
waelder@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 c=
hange in anyway

> > > > depending on whether hardware is present or absent.

> > > >

> > > > The section is only concerned with how the configuratio=
n is applied in

> > > > operational, and basically says that you cannot apply c=
onfiguration for

> > > > resources that are missing (which seems reasonable).=C2=
=A0 E.g. I cannot

> > > > configure an IP address on a physical interface that is=
n't there.=C2=A0 Or if

> > > > the physical interface gets removed then the configurat=
ion associated

> > > > with that interface is also removed from operational.
> > > >

> > > > Operational isn't validated and data model constrai=
nts 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 discrimi=
nation 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 inv=
alid?

> > 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 mod=
el

> can. If not a better model is needed not a hack that breaks the datast=
ore

> conformance to the YANG model. I do not see how

> /interfaces/interface/oper-status=3Dnot-present was not represent=
ing the

> reality of a system with removed line card that is configured and read=
y 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 d=
oes

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 interoperabili=
ty

> > > and a significant portion of the client implementation workl=
oad that can be

> > > automated will need to be coded in hand and tested. Unresolv=
ed leafrefs,

> > > undefined behaviour of different implementations removing di=
fferent

> > > configuration nodes in violation of YANG semantic constraint=
s (which I do

> > > not think can be so clearly separated from the syntactic con=
straints when

> > > one considers types like leafref, instance-identifier etc.) =
and the

> > > corresponding side effects based on the server implementator=
s own creativity

> > > is eventually going to create more problems.

> > >

> > > 1. IMO the only acceptable solution is to have YANG valid op=
erational

> > > 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 le=
ading to any

> > > data transformations. If this is difficult or impossible oth=
er mechanisms to

> > > flag missing resources should be used (e.g.

> > > /interfaces/interface/oper-status=3Dnot-present) This s=
ounds like a useful

> > > contract providing the value of a standard the alternative d=
oes 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 in=
tended

> > > configuration nodes from operational as a solution worth imp=
lementing on our

> > > servers. I do not see a real world plug-and-play scenario th=
at can be

> > > automatically solved without specific additions to the model=
s e.g.

> > > /interfaces/interface/oper-status=3Dnot-present is over=
simplified solution but

> > > it needs to be extended exactly as much as the solution prov=
ided by the

> > > removal of config true; nodes without the sacrifice of YANG =
validity of

> > > operational.

> > Your thinking is likely wrong. <operational> reports the op=
erational

> > state. It may have little in common with <intended>. Trying=
 to derive

> > operational from intended is likely a not well working approach.<=
br>
> The proposal for this solution ("derive operational from intended=
" e.g.

> merge /interfaces-state in /interfaces) comes from the revised datasto=
res

> draft not me.

>

> By definition config true; data represents intent. Reusing the model o=
f 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 m=
odel

> as long as certain conditions are met. I am pointing out that one of t=
he

> conditions is to keep all of the intended configuration data present i=
n

> 'operational' and handle missing resources with conventional m=
eans 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 sto=
p 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 presen=
t 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 supported in a c=
onfiguration datastore

> > >=C2=A0 =C2=A0=C2=A0 MAY be omitted from <operational> i=
f 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 objec=
tions to this

> > > particular part of the NMDA draft earlier.

> > I believe there is a conceptual misunderstanding. I think there n=
ever

> > was a requirement that a server reports the state of hardware tha=
t is

> > not present.

> "Data relevant to hardware that is configured but not present&quo=
t; is different

> from "state of hardware that is not present". For example in=
formation

> indicating when the line card became unavailable, what was the reason,=
 or

> other information like how many packets that had this interface as egr=
ess

> 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 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<http://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--f4030436096e1bbab90560e185cd--


From nobody Fri Dec 22 06:23:53 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D57F12EAB3; Fri, 22 Dec 2017 06:23:49 -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, 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 1B9JPPZc719I; Fri, 22 Dec 2017 06:23:47 -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 E026F12EAB2; Fri, 22 Dec 2017 06:23:46 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E1C7156270B9; Fri, 22 Dec 2017 14:23:42 +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; Fri, 22 Dec 2017 14:23:44 +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;  Fri, 22 Dec 2017 06:23:41 -0800
From: Igor Bryskin 
To: "lberger@labn.net" , "joelja@bogus.com" , "draft-ietf-netmod-yang-tree-diagrams@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
Thread-Index: AQHTePjMSYSuQYfNYUGK68E5pr/EAKNO05qAgACbYls=
Date: Fri, 22 Dec 2017 14:23:40 +0000
Message-ID: 
References: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com>, <255ae0d8-6ba4-9bb1-49e3-c23dc42171bc@labn.net>
In-Reply-To: <255ae0d8-6ba4-9bb1-49e3-c23dc42171bc@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_etPan5a3d15902bde0b8efa1localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Dec 2017 14:23:50 -0000

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

Hi,
I have a question for the authors.
Today a yang-tree-diagram represents extended  YANG groupings , which often=
 makes a tree hard to read/ understand. Do you think there could be a way t=
o represent groupings as collapsed?

Thanks,
Igor
From:Lou Berger
To:joel jaeggli,draft-ietf-netmod-yang-tree-diagrams@ietf.org,netmod@ietf.o=
rg,
Date:2017-12-21 16:07:58
Subject:Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication=
 request

No, I'm not aware of any IPR that applies to this draft

Lou
(co-author)

On 12/19/2017 1:39 PM, joel jaeggli wrote:
> Authors, Contributors, WG,
>
> As part of the preparation for WG Last Call:
>
> 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.
>
>
>
>
> _______________________________________________
> 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

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











Hi,

I have a question for the authors.

Today a yang-tree-diagram represents extended  YANG groupings , which =
often makes a tree hard to read/ understand. Do you think there could be a =
way to represent groupings as collapsed?



Thanks,

Igor






From:Lou Berger


To:joel jaeggli,draft-ietf-netmo=
d-yang-tree-diagrams@ietf.org,netmod@ietf.org,


Date:2017-12-21 16:07:58


Subject:Re: [netmod] draft-ietf-=
netmod-yang-tree-diagrams - IPR verfication request












No, I'm not aware of any IPR that applies to this =
draft



Lou

(co-author)



On 12/19/2017 1:39 PM, joel jaeggli wrote:

> Authors, Contributors, WG,

>

> As part of the preparation for WG Last Call:

>

> 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 rule=
s"

> 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 th=
e

> 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<=
br>
> 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 list=
ed

> 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<=
br>
> 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 abov=
e

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

>

>

>

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.o=
rg/mailman/listinfo/netmod







--_000_etPan5a3d15902bde0b8efa1localhost_--


From nobody Fri Dec 22 06:33:23 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B220212EAC5 for ; Fri, 22 Dec 2017 06:33: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, 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 Xjp1EclU_Utp for ; Fri, 22 Dec 2017 06:33:19 -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 63E8912EAC1 for ; Fri, 22 Dec 2017 06:33:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9722; q=dns/txt; s=iport; t=1513953198; x=1515162798; h=from:subject:to:references:message-id:date:mime-version: in-reply-to; bh=675T4vwjrVEpEj4AExVNkmb0Dd9FkgVJuPcTpQU3Iyo=; b=FJAn97YtwLG5T7OQf3XI+x0b40YHhDtt7YnJoL5CcTRh3kP0ywlzP89S glxXgLR3e5z3ETg10p9ON65OJOXibZ54F/N3tvY9kVx3J0Ee6XuLB6Kjf 5xL5F4KZzkUpx1Wi2eNhW79EYYwVbwHlbxSkAB49hTz0qMT67PgP+AWVG g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQA1Fz1a/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDD4EVdCeEBosYkB+JBohRh2YKGAEKhElPAoURFAEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEBAwEBIUsXAgILEAEEAQEBJwMCAhsGBh8JCAYBDAYCAQEXiXsDF?= =?us-ascii?q?RCkeYInJocSDYMOAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWEB4NogWkpgwWCa0Q?= =?us-ascii?q?Bgg8mglCCZQWjDD2QMYR+jBiHYo1fgRuIBYE7NiKBTzIaCBsVPYIpCYROQTcBi?= =?us-ascii?q?jQBAQE?=
X-IronPort-AV: E=Sophos;i="5.45,441,1508803200"; d="scan'208,217";a="1085196"
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; 22 Dec 2017 14:33:15 +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 vBMEXFP5017872; Fri, 22 Dec 2017 14:33:15 GMT
From: Robert Wilton 
To: Alexander Clemm , Xufeng Liu , NETMOD WG 
References:  <20171219191528.2snk3ahnipxcojtb@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD4D37@sjceml521-mbx.china.huawei.com> <20171219201647.pgywfiws5avnyaul@elstar.local>
Message-ID: 
Date: Fri, 22 Dec 2017 14:33:15 +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: <20171219201647.pgywfiws5avnyaul@elstar.local>
Content-Type: multipart/alternative; boundary="------------0CC632C427D199B999C45F9F"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Augmentation to Groupings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Dec 2017 14:33:21 -0000

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

Some YANG models make very heavy usage of groupings, and in many cases 
where I have seen them used extensively that makes the YANG model far 
less readable.  So one solution here may be to use less groupings. :-)

I agree with the point that others have made that allowing a grouping to 
be augmented globally is probably not a good idea because it could end 
up modifying arbitrary YANG modules.

A couple of other potential solutions could be:

1) Consider a mechanism where a single augment statement can augment 
multiple paths in the schema tree (i.e. reducing repetition of the added 
data nodes, but still keeping the explicitness).
2) Allowing augmentation to a grouping, but have that augmentation only 
apply to "uses" statement within the same YANG module file. This 
approach would seem to have some corner cases that would need to be 
carefully considered (e.g. sub-modules, or if a grouping uses another 
grouping).  It might also be hard to instinctively know or describe 
where the grouping would apply.

Perhaps this issue should be listed on the YANG.next issue tracker, to 
be considered in a future revision of YANG?

Thanks,
Rob


On 19/12/2017 20:16, Juergen Schoenwaelder wrote:
> The question is not why we have groupings, the question is why
> augmentations are restricted to schema node identifiers. I provided an
> answer for the later, namely explicit control of augmentation effects.
>
> It is of course OK to disagree with the design. I am just trying to
> explain that this was an explicit design decision when YANG was
> designed.
>
> /js
>
> On Tue, Dec 19, 2017 at 07:51:05PM +0000, Alexander Clemm wrote:
>> IMHO it would be worth a try.  If you wanted to only augment _some_ uses of a grouping, you could still do the same as today.  Also, I would expect augmentations to only affect servers that support the module defining the augmentation.  If verbosity were not an issue, why were groupings introduced in the first place?
>> --- Alex
>>
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
>>> Schoenwaelder
>>> Sent: Tuesday, December 19, 2017 11:15 AM
>>> To: Xufeng Liu
>>> Cc: NETMOD WG
>>> Subject: Re: [netmod] Augmentation to Groupings
>>>
>>> The current approach may be verbose but it protects users of groupings from
>>> unwanted and uncontrolled side effects. Augmenting a grouping as
>>> suggested affects _all_ uses of a grouping; this can be tricky in situations
>>> where groupings are widely used.
>>>
>>> /js
>>>
>>> On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu wrote:
>>>> During the discussions of TE tunnel and topology models, we have found
>>>> that it is desirable to have the capability of augmenting a grouping.
>>>>
>>>> In our case, there are multiple technology specific models augmenting
>>>> a base generic model. In the base model, some groupings are used
>>>> multiple times, and each augmentation model needs to add more schema
>>>> nodes to the grouping structure. For now, we have to specify an
>>>> “augment” statement for each location where the grouping is used. Such
>>>> an “augment” statement is repeated many times. It would be convenient
>>>> and cleaner if we could augment the grouping.
>>>>
>>>> We’d like to hear opinions on the feasibility of such a capability.
>>>>
>>>> Thanks,
>>>>
>>>> - Xufeng
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod


--------------0CC632C427D199B999C45F9F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Some YANG models make very heavy usage of groupings, and in many
      cases where I have seen them used extensively that makes the YANG
      model far less readable.  So one solution here may be to use less
      groupings. :-)

    

    
I agree with the point that others have made that allowing a
      grouping to be augmented globally is probably not a good idea
      because it could end up modifying arbitrary YANG modules.

    

    
A couple of other potential solutions could be:

    

    
1) Consider a mechanism where a single augment statement can
      augment multiple paths in the schema tree (i.e. reducing
      repetition of the added data nodes, but still keeping the
      explicitness).

      2) Allowing augmentation to a grouping, but have that augmentation
      only apply to "uses" statement within the same YANG module file. 
      This approach would seem to have some corner cases that would need
      to be carefully considered (e.g. sub-modules, or if a grouping
      uses another grouping).  It might also be hard to instinctively
      know or describe where the grouping would apply.

    
Perhaps this issue should be listed on the YANG.next issue
      tracker, to be considered in a future revision of YANG?

    

    Thanks,

    Rob

    

    

    
On 19/12/2017 20:16, Juergen
      Schoenwaelder wrote:

    

    

      
The question is not why we have groupings, the question is why
augmentations are restricted to schema node identifiers. I provided an
answer for the later, namely explicit control of augmentation effects.

It is of course OK to disagree with the design. I am just trying to
explain that this was an explicit design decision when YANG was
designed.

/js

On Tue, Dec 19, 2017 at 07:51:05PM +0000, Alexander Clemm wrote:


      

        
IMHO it would be worth a try.  If you wanted to only augment _some_ uses of a grouping, you could still do the same as today.  Also, I would expect augmentations to only affect servers that support the module defining the augmentation.  If verbosity were not an issue, why were groupings introduced in the first place?
--- Alex



        

          
-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
Schoenwaelder
Sent: Tuesday, December 19, 2017 11:15 AM
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Cc: NETMOD WG <netmod@ietf.org>
Subject: Re: [netmod] Augmentation to Groupings

The current approach may be verbose but it protects users of groupings from
unwanted and uncontrolled side effects. Augmenting a grouping as
suggested affects _all_ uses of a grouping; this can be tricky in situations
where groupings are widely used.

/js

On Tue, Dec 19, 2017 at 11:45:06AM -0500, Xufeng Liu wrote:


          

            
During the discussions of TE tunnel and topology models, we have found
that it is desirable to have the capability of augmenting a grouping.

In our case, there are multiple technology specific models augmenting
a base generic model. In the base model, some groupings are used
multiple times, and each augmentation model needs to add more schema
nodes to the grouping structure. For now, we have to specify an
“augment” statement for each location where the grouping is used. Such
an “augment” statement is repeated many times. It would be convenient
and cleaner if we could augment the grouping.

We’d like to hear opinions on the feasibility of such a capability.

Thanks,

- Xufeng


          

          

            
_______________________________________________
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         <http://www.jacobs-university.de/>

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


        

      

    

    

  


--------------0CC632C427D199B999C45F9F--


From nobody Fri Dec 22 06:33:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64DC12EAC9; Fri, 22 Dec 2017 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 5Q202g_BjoJz; Fri, 22 Dec 2017 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 04E9212EAC8; Fri, 22 Dec 2017 06:33:53 -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 119411AE02BD; Fri, 22 Dec 2017 15:33:51 +0100 (CET)
Date: Fri, 22 Dec 2017 15:33:49 +0100 (CET)
Message-Id: <20171222.153349.958796853977057436.mbj@tail-f.com>
To: Igor.Bryskin@huawei.com
Cc: lberger@labn.net, joelja@bogus.com, draft-ietf-netmod-yang-tree-diagrams@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com> <255ae0d8-6ba4-9bb1-49e3-c23dc42171bc@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] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Dec 2017 14:33:56 -0000

Igor Bryskin  wrote:
> Hi,
> I have a question for the authors.
> Today a yang-tree-diagram represents extended YANG groupings , which
> often makes a tree hard to read/ understand. Do you think there could
> be a way to represent groupings as collapsed?

In draft -03, we added the option of printing the "uses statement",
e.g.:

    |        +---x active-route
    |        |  +--ro output
    |        |     +--ro route
    |        |        +--ro next-hop
    |        |        |  +---u next-hop-state-content
    |        |        +---u route-metadata


instead of:


    |        +---x active-route
    |        |  +--ro output
    |        |     +--ro route
    |        |        +--ro next-hop
    |        |        |  +--ro (next-hop-options)
    |        |        |     +--:(simple-next-hop)
    |        |        |     |  +--ro outgoing-interface?   if:interface-ref
    |        |        |     +--:(special-next-hop)
    |        |        |     |  +--ro special-next-hop?     enumeration
    |        |        |     +--:(next-hop-list)
    |        |        |        +--ro next-hop-list
    |        |        |           +--ro next-hop*
    |        |        |              +--ro outgoing-interface?   if:interface-ref
    |        |        +--ro source-protocol    identityref
    |        |        +--ro active?            empty
    |        |        +--ro last-updated?      yang:date-and-time



/martin

> 
> Thanks,
> Igor
> From:Lou Berger
> To:joel
> jaeggli,draft-ietf-netmod-yang-tree-diagrams@ietf.org,netmod@ietf.org,
> Date:2017-12-21 16:07:58
> Subject:Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR
> verfication request
> 
> No, I'm not aware of any IPR that applies to this draft
> 
> Lou
> (co-author)
> 
> On 12/19/2017 1:39 PM, joel jaeggli wrote:
> > Authors, Contributors, WG,
> >
> > As part of the preparation for WG Last Call:
> >
> > 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.
> >
> >
> >
> >
> > _______________________________________________
> > 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 Dec 22 06:34:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AC812EAC9; Fri, 22 Dec 2017 06:34:47 -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 TRE-3CwKdqwc; Fri, 22 Dec 2017 06:34: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 CED7012EAC8; Fri, 22 Dec 2017 06:34:44 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 049B977; Fri, 22 Dec 2017 15:34: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 Tc9Uwc2orDCA; Fri, 22 Dec 2017 15:34:41 +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, 22 Dec 2017 15:34:42 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E398120130; Fri, 22 Dec 2017 15:34:42 +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 qrDLnFpWsjp4; Fri, 22 Dec 2017 15:34:42 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20C4220073; Fri, 22 Dec 2017 15:34:41 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D482841F9797; Fri, 22 Dec 2017 15:34:41 +0100 (CET)
Date: Fri, 22 Dec 2017 15:34:41 +0100
From: Juergen Schoenwaelder 
To: Igor Bryskin 
Cc: "lberger@labn.net" , "joelja@bogus.com" , "draft-ietf-netmod-yang-tree-diagrams@ietf.org" ,  "netmod@ietf.org" 
Message-ID: <20171222143441.2h2adb43kbmrpkmj@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Igor Bryskin , "lberger@labn.net" , "joelja@bogus.com" , "draft-ietf-netmod-yang-tree-diagrams@ietf.org" ,  "netmod@ietf.org" 
References: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com> <255ae0d8-6ba4-9bb1-49e3-c23dc42171bc@labn.net> 
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] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Dec 2017 14:34:48 -0000

Hi,

this got added in the latest version:

         -u  for uses of a grouping

2.2.  Groupings

   Nodes within a used grouping are normally expanded as if the nodes
   were defined at the location of the "uses" statement.  However, it is
   also possible to not expand the "uses" statement, but instead print
   the name of the grouping.

/js

On Fri, Dec 22, 2017 at 02:23:40PM +0000, Igor Bryskin wrote:
> Hi,
> I have a question for the authors.
> Today a yang-tree-diagram represents extended  YANG groupings , which often makes a tree hard to read/ understand. Do you think there could be a way to represent groupings as collapsed?
> 
> Thanks,
> Igor
> From:Lou Berger
> To:joel jaeggli,draft-ietf-netmod-yang-tree-diagrams@ietf.org,netmod@ietf.org,
> Date:2017-12-21 16:07:58
> Subject:Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
> 
> No, I'm not aware of any IPR that applies to this draft
> 
> Lou
> (co-author)
> 
> On 12/19/2017 1:39 PM, joel jaeggli wrote:
> > Authors, Contributors, WG,
> >
> > As part of the preparation for WG Last Call:
> >
> > 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.
> >
> >
> >
> >
> > _______________________________________________
> > 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


-- 
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 Dec 22 07:07:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0087512EAEF; Fri, 22 Dec 2017 07:07:51 -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, 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 6PRjpNaO1H89; Fri, 22 Dec 2017 07:07:43 -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 70AA012EAEA; Fri, 22 Dec 2017 07:07:43 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 28E7CE04265E3; Fri, 22 Dec 2017 15:07:39 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 22 Dec 2017 15:07:40 +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;  Fri, 22 Dec 2017 07:07:31 -0800
From: Igor Bryskin 
To: "mbj@tail-f.com" , Igor Bryskin 
CC: "lberger@labn.net" , "joelja@bogus.com" , "draft-ietf-netmod-yang-tree-diagrams@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
Thread-Index: AQHTePjMSYSuQYfNYUGK68E5pr/EAKNO05qAgACbYluAAIjxgP//g02T
Date: Fri, 22 Dec 2017 15:07:30 +0000
Message-ID: 
References: <780f5479-6f7b-21b8-e9c7-741ae0063c3f@bogus.com> <255ae0d8-6ba4-9bb1-49e3-c23dc42171bc@labn.net> , <20171222.153349.958796853977057436.mbj@tail-f.com>
In-Reply-To: <20171222.153349.958796853977057436.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_etPan5a3d1fd33fedf81efa1localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication request
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Dec 2017 15:07:51 -0000

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

Great, this works,

Igor
From:Martin Bjorklund
To:Igor Bryskin,
Cc:lberger@labn.net,joelja@bogus.com,draft-ietf-netmod-yang-tree-diagrams@i=
etf.org,netmod@ietf.org,
Date:2017-12-22 09:34:04
Subject:Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR verfication=
 request

Igor Bryskin  wrote:
> Hi,
> I have a question for the authors.
> Today a yang-tree-diagram represents extended YANG groupings , which
> often makes a tree hard to read/ understand. Do you think there could
> be a way to represent groupings as collapsed?

In draft -03, we added the option of printing the "uses statement",
e.g.:

    |        +---x active-route
    |        |  +--ro output
    |        |     +--ro route
    |        |        +--ro next-hop
    |        |        |  +---u next-hop-state-content
    |        |        +---u route-metadata


instead of:


    |        +---x active-route
    |        |  +--ro output
    |        |     +--ro route
    |        |        +--ro next-hop
    |        |        |  +--ro (next-hop-options)
    |        |        |     +--:(simple-next-hop)
    |        |        |     |  +--ro outgoing-interface?   if:interface-ref
    |        |        |     +--:(special-next-hop)
    |        |        |     |  +--ro special-next-hop?     enumeration
    |        |        |     +--:(next-hop-list)
    |        |        |        +--ro next-hop-list
    |        |        |           +--ro next-hop*
    |        |        |              +--ro outgoing-interface?   if:interfa=
ce-ref
    |        |        +--ro source-protocol    identityref
    |        |        +--ro active?            empty
    |        |        +--ro last-updated?      yang:date-and-time



/martin

>
> Thanks,
> Igor
> From:Lou Berger
> To:joel
> jaeggli,draft-ietf-netmod-yang-tree-diagrams@ietf.org,netmod@ietf.org,
> Date:2017-12-21 16:07:58
> Subject:Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR
> verfication request
>
> No, I'm not aware of any IPR that applies to this draft
>
> Lou
> (co-author)
>
> On 12/19/2017 1:39 PM, joel jaeggli wrote:
> > Authors, Contributors, WG,
> >
> > As part of the preparation for WG Last Call:
> >
> > 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.
> >
> >
> >
> >
> > _______________________________________________
> > 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

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











Great, this works,



Igor






From:Martin Bjorklund


To:Igor Bryskin,


Cc:lberger@labn.net,joelja@bogus=
.com,draft-ietf-netmod-yang-tree-diagrams@ietf.org,netmod@ietf.org,


Date:2017-12-22 09:34:04


Subject:Re: [netmod] draft-ietf-=
netmod-yang-tree-diagrams - IPR verfication request












Igor Bryskin <Igor.Bryskin@huawei.com> wrote=
:

> Hi,

> I have a question for the authors.

> Today a yang-tree-diagram represents extended YANG groupings , which
> often makes a tree hard to read/ understand. Do you think there could<=
br>
> be a way to represent groupings as collapsed?



In draft -03, we added the option of printing the "uses statement"=
;,

e.g.:



    |        +---x ac=
tive-route

    |        |  +=
;--ro output

    |        |  =
;   +--ro route

    |        |  =
;      +--ro next-hop

    |        |  =
;      |  +---u next-hop-state-content
    |        |  =
;      +---u route-metadata





instead of:





    |        +---x ac=
tive-route

    |        |  +=
;--ro output

    |        |  =
;   +--ro route

    |        |  =
;      +--ro next-hop

    |        |  =
;      |  +--ro (next-hop-options)

    |        |  =
;      |     +--:(simple-n=
ext-hop)

    |        |  =
;      |     |  +--ro=
 outgoing-interface?   if:interface-ref

    |        |  =
;      |     +--:(special-=
next-hop)

    |        |  =
;      |     |  +--ro=
 special-next-hop?     enumeration

    |        |  =
;      |     +--:(next-hop=
-list)

    |        |  =
;      |       =
 +--ro next-hop-list

    |        |  =
;      |       =
    +--ro next-hop*

    |        |  =
;      |       =
       +--ro outgoing-interface? &nb=
sp; if:interface-ref

    |        |  =
;      +--ro source-protocol   =
 identityref

    |        |  =
;      +--ro active?    &n=
bsp;       empty

    |        |  =
;      +--ro last-updated?   &n=
bsp;  yang:date-and-time







/martin



> 

> Thanks,

> Igor

> From:Lou Berger

> To:joel

> jaeggli,draft-ietf-netmod-yang-tree-diagrams@ietf.org,netmod@ietf.org,=


> Date:2017-12-21 16:07:58

> Subject:Re: [netmod] draft-ietf-netmod-yang-tree-diagrams - IPR

> verfication request

> 

> No, I'm not aware of any IPR that applies to this draft

> 

> Lou

> (co-author)

> 

> On 12/19/2017 1:39 PM, joel jaeggli wrote:

> > Authors, Contributors, WG,

> >

> > As part of the preparation for WG Last Call:

> >

> > 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&quo=
t;

> > or

> > "Yes, I'm aware of IPR that applies to this draft"

> >

> > If so, has this IPR been disclosed in compliance with IETF IPR ru=
les

> > (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 answ=
er

> > the

> > above by responding to this email regardless of whether or not yo=
u 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 lis=
ted

> > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESS=
AGE'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 un=
der

> > 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 fro=
m

> > 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 yo=
ur

> > response.

> >

> >

> >

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

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

> 

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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







--_000_etPan5a3d1fd33fedf81efa1localhost_--


From nobody Fri Dec 22 10:28:59 2017
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 B333D126C26; Fri, 22 Dec 2017 10:28:52 -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.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151396733267.27997.4142470279197260306@ietfa.amsl.com>
Date: Fri, 22 Dec 2017 10:28:52 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-06.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, 22 Dec 2017 18:28:53 -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-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/


From nobody Fri Dec 22 10:31:03 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC95124B17 for ; Fri, 22 Dec 2017 10:31:02 -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 mo_cpFDXqK2W for ; Fri, 22 Dec 2017 10:31:00 -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 B051B1200B9 for ; Fri, 22 Dec 2017 10:31:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3194; q=dns/txt; s=iport; t=1513967460; x=1515177060; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cccDSe5OfykRisRjJghMB+O0CXZ/UyDRHVB6lYtATfU=; b=Mx18Kllg9DM/43Tr7aLXLi/nqDiXGqWJnW4TRgwe2BJJK3esanpTk1c/ Kxn63HM2Db90pwYbEaEARJzK9N/m7cEpUko3yaJEngQRx/JeXqSPMgPK8 nJc+WhXYhDeB1Wyjpf+kZvRgOAdNhjhlnko2YzEfpSV2WEPIqRG44RKDW Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAADjTj1a/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N/iiSPEpkpghUKGAuESU8CGoQ0PxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUkAgEDAQEhETobAgEIEggCJgICAiULFQIEAQYDAgQTii4QpSiCJ4pRAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR+BD4J9ghKDP4Mugy8BAReEbYJlBaNJAod/jS6CF2W?= =?us-ascii?q?FMItOjSGJMQIRGQGBOgEfOYFPbxUZJIIpCYROeIkfgRYBAQE?=
X-IronPort-AV: E=Sophos;i="5.45,442,1508803200"; d="scan'208";a="325193914"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2017 18:30:59 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vBMIUxAj001653 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Dec 2017 18:30:59 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 22 Dec 2017 13:30:58 -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, 22 Dec 2017 13:30:58 -0500
From: "Acee Lindem (acee)" 
To: NetMod WG 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-06.txt
Thread-Index: AQHTe1MD/GnssEOCd0eW/uuL2zO61g==
Date: Fri, 22 Dec 2017 18:30:58 +0000
Message-ID: 
References: <151396733267.27997.4142470279197260306@ietfa.amsl.com>
In-Reply-To: <151396733267.27997.4142470279197260306@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: <2FF0AAB51244424AB31A87A65EB3B0CE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [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: Fri, 22 Dec 2017 18:31:02 -0000

VGhpcyB2ZXJzaW9uIGluY2x1ZGVzIE1hcnRpbuKAmXMgWUFORyBkb2N0b3IgY29tbWVudHMgYW5k
IHNvbWUgdXBkYXRlcyB0bw0KdGhlIGV4YW1wbGVzIChlLmcuLCBZQU5HIExpYnJhcnkgZGF0YSkg
ZnJvbSBMYWRhLg0KDQpUaGFua3MsDQpBY2VlIA0KDQpPbiAxMi8yMi8xNywgMToyOCBQTSwgIm5l
dG1vZCBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3Rl
Og0KDQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp
bmUgSW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsg
aXRlbSBvZiB0aGUgTmV0d29yayBNb2RlbGluZyBXRyBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAg
IFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIE1hbmFnZW1l
bnQgKE5ETUENCj5WZXJzaW9uKQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTGFkaXNsYXYg
TGhvdGthDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBBY2VlIExpbmRlbQ0KPiAgICAgICAg
ICAgICAgICAgICAgICAgICAgWWluZ3poZW4gUXUNCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQt
aWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0wNi50eHQNCj4JUGFnZXMgICAgICAgICAgIDogNzcNCj4J
RGF0ZSAgICAgICAgICAgIDogMjAxNy0xMi0yMg0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9j
dW1lbnQgY29udGFpbnMgYSBzcGVjaWZpY2F0aW9uIG9mIHRocmVlIFlBTkcgbW9kdWxlcyBhbmQg
b25lDQo+ICAgc3VibW9kdWxlLiAgVG9nZXRoZXIgdGhleSBmb3JtIHRoZSBjb3JlIHJvdXRpbmcg
ZGF0YSBtb2RlbCB0aGF0DQo+ICAgc2VydmVzIGFzIGEgZnJhbWV3b3JrIGZvciBjb25maWd1cmlu
ZyBhbmQgbWFuYWdpbmcgYSByb3V0aW5nDQo+ICAgc3Vic3lzdGVtLiAgSXQgaXMgZXhwZWN0ZWQg
dGhhdCB0aGVzZSBtb2R1bGVzIHdpbGwgYmUgYXVnbWVudGVkIGJ5DQo+ICAgYWRkaXRpb25hbCBZ
QU5HIG1vZHVsZXMgZGVmaW5pbmcgZGF0YSBtb2RlbHMgZm9yIGNvbnRyb2wtcGxhbmUNCj4gICBw
cm90b2NvbHMsIHJvdXRlIGZpbHRlcnMsIGFuZCBvdGhlciBmdW5jdGlvbnMuICBUaGUgY29yZSBy
b3V0aW5nIGRhdGENCj4gICBtb2RlbCBwcm92aWRlcyBjb21tb24gYnVpbGRpbmcgYmxvY2tzIGZv
ciBzdWNoIGV4dGVuc2lvbnMgLS0gcm91dGVzLA0KPiAgIFJvdXRpbmcgSW5mb3JtYXRpb24gQmFz
ZXMgKFJJQnMpLCBhbmQgY29udHJvbC1wbGFuZSBwcm90b2NvbHMuDQo+DQo+ICAgVGhlIFlBTkcg
bW9kdWxlcyBpbiB0aGlzIGRvY3VtZW50IGNvbmZvcm0gdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVu
dA0KPiAgIERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpLiAgVGhpcyBkb2N1bWVudCBvYnNv
bGV0ZXMgUkZDIDgwMjIuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug
Zm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy8NCj4NCj5UaGVyZSBhcmUgYWxzbyBodG1saXplZCB2
ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDYNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDYNCj4NCj5BIGRpZmYgZnJv
bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDYNCj4NCj4N
Cj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0
aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg
ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0
cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0
Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9y
Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Tue Dec 26 18:41:03 2017
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 7B3C7127735; Tue, 26 Dec 2017 18:41:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern 
To: 
Cc: draft-ietf-netmod-rfc7277bis.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.68.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151434246145.29746.11537961707775609357@ietfa.amsl.com>
Date: Tue, 26 Dec 2017 18:41:01 -0800
Archived-At: 
Subject: [netmod] Rtgdir 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: Wed, 27 Dec 2017 02:41:01 -0000

Reviewer: Joel Halpern
Review result: Ready

This is a rtg-dir review of draft-ietf-netmod-rfc7277bis-01.
While primarily intended for the Routing Area directors, the comments are for
consideration by all parties.

This document is Ready for publication as a Proposed Standard RFC.

Comments: None


From nobody Wed Dec 27 03:18:21 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DBE126DFE; Wed, 27 Dec 2017 03:18:19 -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 DDgOdTgZquyn; Wed, 27 Dec 2017 03:18:18 -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 C52EF126D46; Wed, 27 Dec 2017 03:18:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3086; q=dns/txt; s=iport; t=1514373498; x=1515583098; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DTgUdY0Ap8BW0kMSqNXheg+Arltog9CBE3LOUr4w5v8=; b=IVYuBZsPMLDyKDsKojoewCtK3dhMPNJ/IaI4e7bxRfovZiZX7WtA9jj0 /2jG3Q62pHUG72Z7pkz61pskOd1ZryG3keY+10bQ6fhNrZC8avkadIcHy +CHIwAYIaz996XA2tSIul4a6Tq8pGZwN7F9nwsL30Oh8EU1WNDWyqiZ3W Y=;
X-IronPort-AV: E=Sophos;i="5.45,464,1508803200";  d="scan'208";a="1092655"
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; 27 Dec 2017 11:18:16 +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 vBRBIFV2017037; Wed, 27 Dec 2017 11:18:16 GMT
To: "Acee Lindem (acee)" , NetMod WG , "draft-ietf-rtgwg-yang-rip@ietf.org" 
References: <151396733267.27997.4142470279197260306@ietfa.amsl.com> 
From: Benoit Claise 
Message-ID: <9019c1c5-ea86-5620-5421-749b4aee35d9@cisco.com>
Date: Wed, 27 Dec 2017 12:18:15 +0100
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] 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: Wed, 27 Dec 2017 11:18:20 -0000

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?

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


From nobody Wed Dec 27 08:40:59 2017
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 A5EAF12D7EE; Wed, 27 Dec 2017 08:40:57 -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.68.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, joelja@bogus.com, Joel Jaeggli ,  iesg-secretary@ietf.org, netmod@ietf.org
Message-ID: <151439285767.29709.6445997198095095728.idtracker@ietfa.amsl.com>
Date: Wed, 27 Dec 2017 08:40:57 -0800
Archived-At: 
Subject: [netmod] Publication has been requested for 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: Wed, 27 Dec 2017 16:40:58 -0000

Joel Jaeggli has requested publication of draft-ietf-netmod-rfc8022bis-06 as Proposed Standard on behalf of the NETMOD working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/


From nobody Wed Dec 27 09:25:53 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FABE1242EA; Wed, 27 Dec 2017 09:25:51 -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 BpMg_aNyYHsu; Wed, 27 Dec 2017 09:25:49 -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 844D81271DF; Wed, 27 Dec 2017 09:25:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4616; q=dns/txt; s=iport; t=1514395549; x=1515605149; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ONvJdpvJ6g3WZJiHiQbz4HRefYq41L0Q0E4XpZ9vco8=; b=AwJgbt+IzO2WXtTLLMxm/C+FIA8aNKESyogGURaasvp5U8TtoONqS2df sg5a0cdvEK9bmOcwV7gdbtJ9wpzsyluMQKSBwdKkj9jpOU/hGdRDiHooq Kc+/n1UFOvLBSmodIUne/FAIC/JDJYCnMun1JI11UeXTZyhGjVTELqmKx A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBg1kNa/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4N/iiSPFYIBlymCFQoYC4RJTwIahDs/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSQBAQEDAQEhETobAgEIEgYCAiYCAgIlCxUCDgIEARKKLhCmPIInik0BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQ+CfYISgz+DLoMvAQEXhG2CZQWjTAKIAY0?= =?us-ascii?q?yghdlhTGLUI0kiTICERkBgTsBHzmBT28VGSSCKQmETniIaoEWAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,466,1508803200"; d="scan'208";a="49092644"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Dec 2017 17:25:48 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBRHPmvL001538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Dec 2017 17:25:48 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; Wed, 27 Dec 2017 12:25:47 -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, 27 Dec 2017 12:25:47 -0500
From: "Acee Lindem (acee)" 
To: "Benoit Claise (bclaise)" , NetMod WG , "draft-ietf-rtgwg-yang-rip@ietf.org" 
Thread-Topic: [netmod] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt
Thread-Index: AQHTfwRmtyMCVakw5E6pebB4gVVRlKNXcWeA
Date: Wed, 27 Dec 2017 17:25:47 +0000
Message-ID: 
References: <151396733267.27997.4142470279197260306@ietfa.amsl.com>  <9019c1c5-ea86-5620-5421-749b4aee35d9@cisco.com>
In-Reply-To: <9019c1c5-ea86-5620-5421-749b4aee35d9@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: <0079E822C676A0488EEBA97927DD99DA@emea.cisco.com>
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: Wed, 27 Dec 2017 17:25:51 -0000

SGkgQmVub2l0LCANCg0KT24gMTIvMjcvMTcsIDY6MTggQU0sICJCZW5vaXQgQ2xhaXNlIChiY2xh
aXNlKSIgPGJjbGFpc2VAY2lzY28uY29tPiB3cm90ZToNCg0KPlRoYW5rcyBBY2VlLA0KPg0KPk1p
bm9yIHF1ZXN0aW9uIGZvciB0aGUgd29ya2luZyBncm91cCBhbmQgdGhlIGRyYWZ0LWlldGYtcnRn
d2cteWFuZy1yaXANCj5hdXRob3JzLg0KPg0KPlRoZSBhcHBlbmRpeCBpcyBhYm91dCBhZGRpbmcg
YSBuZXcgY29udHJvbC1wbGFuZSBwcm90b2NvbC4gSXQgdGFrZXMgYXMNCj5hbiBleGFtcGxlIFJJ
UC4NCj5Ib3dldmVyLCBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctcmlwIGlzIGJlaW5nIGZpbmFsaXpl
ZCAob24gdGhlIElFU0cNCj50ZWxlY2hhdCBvbiBKYW4gMTF0aCkuDQo+RG9lcyBpdCBtYWtlIHNl
bnNlIHRvIGtlZXAgdGhlIFJJUCBleGFtcGxlPyBJZiBzbywgaXMgdGhlIGV4YW1wbGUNCj5jb25z
aXN0ZW50IHdpdGggZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLXJpcD8NCj5PciBzaG91bGQgd2UganVz
dCBwb2ludCB0byBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctcmlwIGFzIHRoZSBleGFtcGxlPw0KDQpJ
dCBpcyBwcm9iYWJseSBiZXR0ZXIganVzdCB0byByZWZlcmVuY2UgdGhlIFJJUCBtb2R1bGUgZHJh
ZnQuIERvZXMgYW55b25lDQpkaXNhZ3JlZT8NCg0KVGhhbmtzLA0KQWNlZSANCj4NCj5Ob3Qgc3Ry
b25nIHZpZXdzIG9uIG15IHNpZGUuDQo+DQo+UmVnYXJkcywgQmVub2l0DQo+PiBUaGlzIHZlcnNp
b24gaW5jbHVkZXMgTWFydGlu4oCZcyBZQU5HIGRvY3RvciBjb21tZW50cyBhbmQgc29tZSB1cGRh
dGVzIHRvDQo+PiB0aGUgZXhhbXBsZXMgKGUuZy4sIFlBTkcgTGlicmFyeSBkYXRhKSBmcm9tIExh
ZGEuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gQWNlZQ0KPj4NCj4+IE9uIDEyLzIyLzE3LCAxOjI4IFBN
LCAibmV0bW9kIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo+PiA8bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y
Zz4gd3JvdGU6DQo+Pg0KPj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t
IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+IGRpcmVjdG9yaWVzLg0KPj4+IFRoaXMg
ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgTW9kZWxpbmcgV0cgb2YgdGhlIElF
VEYuDQo+Pj4NCj4+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVs
IGZvciBSb3V0aW5nIE1hbmFnZW1lbnQNCj4+PihORE1BDQo+Pj4gVmVyc2lvbikNCj4+PiAgICAg
ICAgIEF1dGhvcnMgICAgICAgICA6IExhZGlzbGF2IExob3RrYQ0KPj4+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgQWNlZSBMaW5kZW0NCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFlp
bmd6aGVuIFF1DQo+Pj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzgw
MjJiaXMtMDYudHh0DQo+Pj4gCVBhZ2VzICAgICAgICAgICA6IDc3DQo+Pj4gCURhdGUgICAgICAg
ICAgICA6IDIwMTctMTItMjINCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+ICAgIFRoaXMgZG9jdW1l
bnQgY29udGFpbnMgYSBzcGVjaWZpY2F0aW9uIG9mIHRocmVlIFlBTkcgbW9kdWxlcyBhbmQgb25l
DQo+Pj4gICAgc3VibW9kdWxlLiAgVG9nZXRoZXIgdGhleSBmb3JtIHRoZSBjb3JlIHJvdXRpbmcg
ZGF0YSBtb2RlbCB0aGF0DQo+Pj4gICAgc2VydmVzIGFzIGEgZnJhbWV3b3JrIGZvciBjb25maWd1
cmluZyBhbmQgbWFuYWdpbmcgYSByb3V0aW5nDQo+Pj4gICAgc3Vic3lzdGVtLiAgSXQgaXMgZXhw
ZWN0ZWQgdGhhdCB0aGVzZSBtb2R1bGVzIHdpbGwgYmUgYXVnbWVudGVkIGJ5DQo+Pj4gICAgYWRk
aXRpb25hbCBZQU5HIG1vZHVsZXMgZGVmaW5pbmcgZGF0YSBtb2RlbHMgZm9yIGNvbnRyb2wtcGxh
bmUNCj4+PiAgICBwcm90b2NvbHMsIHJvdXRlIGZpbHRlcnMsIGFuZCBvdGhlciBmdW5jdGlvbnMu
ICBUaGUgY29yZSByb3V0aW5nDQo+Pj5kYXRhDQo+Pj4gICAgbW9kZWwgcHJvdmlkZXMgY29tbW9u
IGJ1aWxkaW5nIGJsb2NrcyBmb3Igc3VjaCBleHRlbnNpb25zIC0tIHJvdXRlcywNCj4+PiAgICBS
b3V0aW5nIEluZm9ybWF0aW9uIEJhc2VzIChSSUJzKSwgYW5kIGNvbnRyb2wtcGxhbmUgcHJvdG9j
b2xzLg0KPj4+DQo+Pj4gICAgVGhlIFlBTkcgbW9kdWxlcyBpbiB0aGlzIGRvY3VtZW50IGNvbmZv
cm0gdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudA0KPj4+ICAgIERhdGFzdG9yZSBBcmNoaXRlY3R1
cmUgKE5NREEpLiAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDgwMjIuDQo+Pj4NCj4+Pg0K
Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K
Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJm
YzgwMjJiaXMvDQo+Pj4NCj4+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFp
bGFibGUgYXQ6DQo+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0
bW9kLXJmYzgwMjJiaXMtMDYNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o
dG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzgwMjJiaXMtMDYNCj4+Pg0KPj4+IEEgZGlmZiBmcm9t
IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy0wNg0KPj4+
DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0
ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+IHN1Ym1pc3Npb24NCj4+PiB1bnRpbCB0aGUgaHRtbGl6
ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4+
DQo+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ
IGF0Og0KPj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4NCj4+PiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5ldG1v
ZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1v
ZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QNCj4NCg0K


From nobody Sun Dec 31 07:52:23 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754261241FC; Sun, 31 Dec 2017 07:52: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 HPrsIPKlElRW; Sun, 31 Dec 2017 07:52:15 -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 B4F591200F3; Sun, 31 Dec 2017 07:52:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7238; q=dns/txt; s=iport; t=1514735535; x=1515945135; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=VGoPDBdaXWunjacJhNHaLnh0ioYqh5uG26kxwWUqCPs=; b=KOcmh+gxCS9YzoZH0PJ6d4kb27mmRfK2PZntOtoD2fxHTtU7w0OR2NU4 0NE0fLMGr/Sudqnpa9PZOVW74EC3QQS0jsAom0GZePKaUs3L/mZmh47AD M8E/Qb7htnHeYxTIxgKxHIzg8vDgBHiQursv4FL60W6MjQNy9oPTNzh5y o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgB3B0la/xbLJq1cGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQkdCePH499J5FZhWWCAQojhRgChHMUAQEBAQEBAQEBayiFIwEDA3A?= =?us-ascii?q?CFxwDAQIvTQIIBgEMBgIBAYoqEK4HJooJAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YQMg2iCEgyCeYMvAQGBNQQNR4VcBYd0hQiMZYlriAOHYYVRjBmHZI0kgVqIBYE?= =?us-ascii?q?8NiIlGoEQMhoIGxWCZgmET0A3AQEBAYZjgkoBAQE?=
X-IronPort-AV: E=Sophos;i="5.45,486,1508803200"; d="scan'208,217";a="1193968"
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; 31 Dec 2017 15:52:11 +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 vBVFqArw004784; Sun, 31 Dec 2017 15:52:11 GMT
References: <33e9be3a-2f32-74bc-17dc-d8b667e04c91@cisco.com>
To: NETMOD Working Group , YANG Doctors 
From: Benoit Claise 
X-Forwarded-Message-Id: <33e9be3a-2f32-74bc-17dc-d8b667e04c91@cisco.com>
Message-ID: <687790d0-46bf-5682-9fff-77a661383169@cisco.com>
Date: Sun, 31 Dec 2017 16:52:10 +0100
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: <33e9be3a-2f32-74bc-17dc-d8b667e04c91@cisco.com>
Content-Type: multipart/alternative; boundary="------------8F96E0671DA5C38DBA7C9FD6"
Content-Language: en-US
Archived-At: 
Subject: [netmod] Fwd: New datatracker release: v6.68.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: Sun, 31 Dec 2017 15:52:17 -0000

This is a multi-part message in MIME format.
--------------8F96E0671DA5C38DBA7C9FD6
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I want to draw your attention to this entry below:

   * Added a data migration to create yang catalog links for yang documents
     published before the yang catalog link feature was introduced in the
     datatracker.

Ex: https://datatracker.ietf.org/doc/rfc7223/

Happy New Year to all of you.

Regards, Benoit

-------- Forwarded Message --------
Subject: 	New datatracker release: v6.68.1
Date: 	Sat, 23 Dec 2017 13:53:59 -0800
From: 	Henrik Levkowetz 
To: 	codesprints@ietf.org, iesg@ietf.org, wgchairs@ietf.org



Hi,

This is an automatic notification about a new datatracker release,
v6.68.1, generated when running the mkrelease script.

Release notes:

ietfdb (6.68.1) ietf; urgency=medium

   This is a bugfix release, with a number of minor fixes, as follows:

   * Tweaked the query filter for 'latest' meetings in the
     fetch_meeting_attendance management command to deal with future meetings
     beyond the current meeting in the database.

   * Added a guard against infinite recursion in document replacement listing
     methods to deal better with circular relationships.

   * Enhanced doc event notification emails with who and when.  Fixes issue
     #2428.

   * Added a data migration to create yang catalog links for yang documents
     published before the yang catalog link feature was introduced in the
     datatracker.

   * Fixed an ungarded object attribute access.

   * Updated the API notes page with improved descriptions and information.

   * Limited the iesg ballot position API to ADs (excluding secretariat).

   * Modified the run_yang_model_checks management command to accept
     document aliases (not only canonical names) on the command line.

   * Reverted an inadvertently included patch version.

   * Fixed some reStructuredText issues in the changelog

  -- Henrik Levkowetz   22 Dec 2017 11:29:14 -0800

The new version is available for installation through SVN checkout, with
   'svn checkouthttps://svn.tools.ietf.org/svn/tools/ietfdb/tags/6.68.1'

For development, copy the new development version instead:
   'svn copyhttps://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.68.2.dev0' 

Regards,

	Henrik
	(via the mkrelease script)

.


--------------8F96E0671DA5C38DBA7C9FD6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    
 

      I want to draw your attention to this entry below:

       

      
  * Added a data migration to create yang catalog links for yang documents 
    published before the yang catalog link feature was introduced in the 
    datatracker.

      
Ex: https://datatracker.ietf.org/doc/rfc7223/

        

        Happy New Year to all of you.

        

        Regards, Benoit

        

        -------- Forwarded Message --------
        

          
            

              Subject:
              
              New datatracker release: v6.68.1
            

            

              Date:
              
              Sat, 23 Dec 2017 13:53:59 -0800
            

            

              From:
              
              Henrik Levkowetz <henrik@levkowetz.com>
            

            

              To: 
              codesprints@ietf.org, iesg@ietf.org,
                wgchairs@ietf.org
            

          
        

        

        

        
Hi,

This is an automatic notification about a new datatracker release, 
v6.68.1, generated when running the mkrelease script.

Release notes:

ietfdb (6.68.1) ietf; urgency=medium

  This is a bugfix release, with a number of minor fixes, as follows:

  * Tweaked the query filter for 'latest' meetings in the
    fetch_meeting_attendance management command to deal with future meetings
    beyond the current meeting in the database.

  * Added a guard against infinite recursion in document replacement listing
    methods to deal better with circular relationships.

  * Enhanced doc event notification emails with who and when.  Fixes issue 
    #2428.

  * Added a data migration to create yang catalog links for yang documents 
    published before the yang catalog link feature was introduced in the 
    datatracker.

  * Fixed an ungarded object attribute access.

  * Updated the API notes page with improved descriptions and information.

  * Limited the iesg ballot position API to ADs (excluding secretariat).

  * Modified the run_yang_model_checks management command to accept 
    document aliases (not only canonical names) on the command line.

  * Reverted an inadvertently included patch version.

  * Fixed some reStructuredText issues in the changelog

 -- Henrik Levkowetz <henrik@levkowetz.com>  22 Dec 2017 11:29:14 -0800

The new version is available for installation through SVN checkout, with
  'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/6.68.1'

For development, copy the new development version instead:
  'svn copy https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.68.2.dev0' <YOURBRANCH>

Regards,

	Henrik
	(via the mkrelease script)

.



      

    

  


--------------8F96E0671DA5C38DBA7C9FD6--