From nobody Wed Dec 3 09:48:16 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800231A3BA5 for ; Wed, 3 Dec 2014 09:48:14 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F-uyf61DVYc for ; Wed, 3 Dec 2014 09:48:12 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA561A1B98 for ; Wed, 3 Dec 2014 09:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1982; q=dns/txt; s=iport; t=1417628892; x=1418838492; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=S+NmBr5oY/ezoPbIK/l380Um3IyyqN6W5k3vqa8lkQ0=; b=Q8j/6/6deVdNVJejG1roYhnZCJiky/4UpZSIadaPNUt7QKNoqXx+3ziJ l+2AlZIa0mTTfi/9APgY8JHYp8fh7JgCU6mXC0JQSt+l8VHH7vpML0n/O Pl9Ici0loJTijk9abO+62mLDhvxXcjIQQrt3WbdhggtD+wU+e+O08xJBk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAJtMf1StJA2D/2dsb2JhbABagwZSWATGR4YVAoEUFgEBAQEBfYQCAQEBBHcSAgEIGC4yGwEGAwIEEwmINQ3WPgEBAQEBAQQBAQEBAQEBG5BthEIFkA+EFoY0gSI4gnWPR4N4bwGBRIEAAQEB X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="374164089" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 03 Dec 2014 17:48:12 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB3HmBx2026025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Dec 2014 17:48:11 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 11:48:11 -0600 From: "Acee Lindem (acee)" To: "rtg-yang-coord@ietf.org" Thread-Topic: New Version Notification for draft-acee-rtg-yang-key-chain-00.txt Thread-Index: AQHQDXlppJIGOHb3MkOOLU0Jn1KW1Jx9I3EAgAEU+YA= Date: Wed, 3 Dec 2014 17:48:10 +0000 Message-ID: References: <20141201151342.4614.49312.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2DAA57FCF255684FBF8E90F0C20838D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/9EZ1ncrOgEgVWAfJWLYnvguILU4 Subject: [Rtg-yang-coord] FW: New Version Notification for draft-acee-rtg-yang-key-chain-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 17:48:14 -0000 FYI=8A On 12/2/14, 8:16 PM, "Acee Lindem (acee)" wrote: >FYI - This draft describes the key-chain YANG data model. Key-chains have >been implemented by most networking vendors and are used for routing >protocol authentication. One of the authors will be presenting the draft >in Dallas.=20 >Thanks, >Acee > >On 12/1/14, 10:13 AM, "internet-drafts@ietf.org" > wrote: > >> >>A new version of I-D, draft-acee-rtg-yang-key-chain-00.txt >>has been successfully submitted by Acee Lindem and posted to the >>IETF repository. >> >>Name: draft-acee-rtg-yang-key-chain >>Revision: 00 >>Title: Key Chain YANG Data Model >>Document date: 2014-12-01 >>Group: Individual Submission >>Pages: 17 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-acee-rtg-yang-key-chain-00.txt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-acee-rtg-yang-key-chain/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-acee-rtg-yang-key-chain-00 >> >> >>Abstract: >> This document describes the key chain YANG data model. Industry >> standard key chains are lists of keys, send lifetimes, accept >> lifetimes, and algorithms. By properly overlapping the send and >> accept lifetimes of multiple key chain entries, keys and algorithms >> may be gracefully updated. By representing them in a YANG data >> model, key distribution can be automated. Key chains are commonly >> used for routing protocol authentication and other applications. In >> some applications, the protocols do not directly use the key chain >> entry keys, but rather a key derivation function is used to derive a >> short-lived key from the key-chain key. >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > From nobody Wed Dec 3 13:09:47 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEB91A7001 for ; Wed, 3 Dec 2014 13:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8TIEeEF6joS for ; Wed, 3 Dec 2014 13:09:25 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id AADE11A802F for ; Wed, 3 Dec 2014 13:09:16 -0800 (PST) Received: (qmail 8238 invoked by uid 0); 3 Dec 2014 21:09:02 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 3 Dec 2014 21:09:02 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id P98z1p00M2SSUrH01992Eq; Wed, 03 Dec 2014 14:09:02 -0700 X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=dnVcXgwgJT006LKN9p8A:9 a=Ztx-izuSjQf6F9eZ:21 a=eO9iTE163LBcfmPy:21 a=QEXdDO2ut3YA:10 a=k0LuJNu7CxwA: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:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PhgjQ58GhojiS4Shcg6Q88HKWTaKRumtFHfsbZMAfG4=; b=zNVdVCDrEOLro46ogNDEnt4iwLuBAOrE7OhmnwieDwKIAhiWOvV+45/W+wnuhdDhJ6rrdhpInJVG7LlM+f2LaWDGtiF4615VmYLikjyLgbnDdY+nSLWpSwMO4xSQcK2J; Received: from box313.bluehost.com ([69.89.31.113]:34073 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XwHAR-0002sm-3Y; Wed, 03 Dec 2014 14:08:59 -0700 Message-ID: <547F7BFE.2040705@labn.net> Date: Wed, 03 Dec 2014 16:09:18 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtg-yang-coord@ietf.org" , teas@ietf.org References: <20141203202653.18771.95322.idtracker@ietfa.amsl.com> In-Reply-To: <20141203202653.18771.95322.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141203202653.18771.95322.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/DCV79PFcNXpJUhoA0GKKixdN-bg Cc: "BRUNGARD, DEBORAH A \(ATTLABS\)" Subject: [Rtg-yang-coord] Fwd: CCAMP WG Virtual Interim Meeting: December 18, starting at 20:00 UTC X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 21:09:25 -0000 FYI - agenda is being worked and will be posted to both the CCAMP and TEAS lists. Please feel free to send us (me and Deborah) if you have an agenda request. -------- Original Message -------- Subject: CCAMP WG Virtual Interim Meeting: December 18, starting at 20:00 UTC Date: Wed, 03 Dec 2014 12:26:53 -0800 From: IESG Secretary Reply-To: ietf@ietf.org To: IETF Announcement List CC: ccamp@ietf.org TE Topology Yang Model Virtual Interim (CCAMP) There is a cluster of work around YANG models for topology and the TED (TE Topology Database). The Routing ADs are planning to have the TEAS working group formalized soon and the group is expected to have an explicit deliverable of a YANG model for the TED. We, the current CCAMP chairs, have been asked to get this effort moving by arranging a virtual interim meeting on the topic. The primary objectives of the meeting are to (a) get some basic agreement on TE topology model 'use cases' (e.g., driven by I2RS, PCE, ALTO, TEAS), (b) establish the dependencies/relationships of a TE topology model to other models (e.g., router, topology, routing protocols, ...) and finally, (c) to provide the needed foundation for a TEAS design team to be formed and deliver a TE Topology Yang Model draft by Dallas. A related activity has also started in the MPLS WG on a TE LSP Yang Model. This topic will *not* be the focus of this interim and we expect that work to continue concurrently. The Virtual interim is scheduled for 2-3 hours on December 18, starting at 20:00 UTC. The agenda and other logistic information for the meeting will be posted & discussed on the CCAMP and new TEAS mailing list (ccamp@ietf.org and teas@ietf.org). The existing set of related drafts includes: draft-liu-yang-abstract-te-topo draft-clemm-i2rs-yang-l3-topo draft-clemm-i2rs-yang-network-topo draft-amante-i2rs-topology-use-cases draft-chen-mpls-te-yang-cfg (LSP focused) draft-gandhi-mpls-te-yang-model (LSP focused) draft-ietf-netmod-routing-cfg (Foundational work, not topology specific) Deborah and Lou From nobody Mon Dec 8 10:32:34 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A371A87BC for ; Mon, 8 Dec 2014 10:32:31 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFuzr8g9vgrj for ; Mon, 8 Dec 2014 10:32:29 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD1E1A87B3 for ; Mon, 8 Dec 2014 10:32:28 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-e9-54859e70f26e Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 48.D5.03307.07E95845; Mon, 8 Dec 2014 13:49:52 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 13:32:26 -0500 From: Xufeng Liu To: "Rtg-yang-coord@ietf.org" Thread-Topic: New Version Notification for draft-liu-rtgwg-yang-vrrp-00.txt Thread-Index: AQHQEArL9ecTkExqVUuxoAx41L6fg5yGCnZA Date: Mon, 8 Dec 2014 18:32:25 +0000 Message-ID: References: <20141204213925.24134.22081.idtracker@ietfa.amsl.com> In-Reply-To: <20141204213925.24134.22081.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyuXRPrG7BvNYQg7s/jS1+P7/N7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBX/9Asu8Vacff6HuYFxCW8XIyeHhICJxPprh5khbDGJC/fW s3UxcnEICRxhlHi++D0jhLOMUaLp5T2mLkYODjYBLYnLTx1BGkQEzCWaZ58BaxYW8JKYv3Ur C0TcW+LN8+1sELaRxI6b+8FsFgEViW1975lAbF6gmoWPH7CAjBQScJR4tsgCJMwp4CTxbkEz 2BhGoHu+n1oDVs4sIC5x68l8Jog7BSSW7DkPdbOoxMvH/1ghbCWJSUvPsYKMZBbQlFi/Sx+i VVFiSvdDdoitghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVI0dpcWpZbrqRwSZGYMAfk2DT 3cG456XlIUYBDkYlHt4Ni1tChFgTy4orcw8xSnOwKInzzqqdFywkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBcemnWReFEvstJoWl79uwm0PKYIZ/2xrN2c/YHq2pdfGf5q/uGXxx9fNA8/Vc XSmt1xT1Jl4z6Pvd+fjTeR63GZdmLX2pqrimqkFUt1Nw/b369f/SHbkkzLO7dx9tljgzUVDL zFYm9OryFdFpbE9tDHhlJ4Qut3BL7l4frrXbw+M3q+CTR4tjlFiKMxINtZiLihMBKy0t7FkC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/CO10WRohVvGVlgLjwpxYYfXzt_w Subject: [Rtg-yang-coord] FW: New Version Notification for draft-liu-rtgwg-yang-vrrp-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 18:32:32 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXks IERlY2VtYmVyIDA0LCAyMDE0IDQ6MzkgUE0NClRvOiBYdWZlbmcgTGl1OyBBdGhhbmFzaW9zIEt5 cGFybGlzOyBYdWZlbmcgTGl1OyBBdGhhbmFzaW9zIEt5cGFybGlzDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1ydGd3Zy15YW5nLXZycnAtMDAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS1ydGd3Zy15YW5nLXZycnAtMDAudHh0 IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWHVmZW5nIExpdSBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1saXUtcnRnd2cteWFuZy12 cnJwDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJQSBZQU5HIERhdGEgTW9kZWwgZm9yIFZpcnR1YWwg Um91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wgKFZSUlApDQpEb2N1bWVudCBkYXRlOgkyMDE0LTEy LTAzDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMg0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1ydGd3 Zy15YW5nLXZycnAtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXJ0Z3dnLXlhbmctdnJycC8NCkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtcnRnd2cteWFuZy12cnJwLTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9kZWwgZm9y IFZpcnR1YWwgUm91dGVyIFJlZHVuZGFuY3kNCiAgIFByb3RvY29sIChWUlJQKS4gQm90aCB2ZXJz aW9uIDIgYW5kIHZlcnNpb24gMyBvZiBWUlJQIGFyZSBjb3ZlcmVkLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Dec 8 15:59:13 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF931A1A2A for ; Mon, 8 Dec 2014 15:59:11 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLfu2Uie-det for ; Mon, 8 Dec 2014 15:59:09 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DEC1A03A5 for ; Mon, 8 Dec 2014 15:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1418083150; x=1419292750; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=19eP58cvReq/Smp/NEbahhm9+8fM4LEmyyZJc4Kv1H8=; b=UsDYdu1GxCrWbnu9L9+NgPly4PClkKmAxF9UOMXxnBAgKQd6NMUwtD0l 1aBQGK0gjhXyCQoScQtSQ7TNjgUSY42IvlW630lCK0LXmCxRJAH8Z7boo sRiizCancCTiM3D+Wkg2mQcOFUx6CKR3WX5fcFClsWPn+2kuFxLlLJeop 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPc6hlStJV2R/2dsb2JhbABZgwZSXMVpCoYJAoEoFgEBAQEBfYQCAQEBAwEBAQE3NAsFBwYBCBEEAQELFAUELgsUCAEJAQQOBQgBiCcIDdY3AQEBAQEBAQEBAQEBAQEBAQEBAQEYj2QnMQ2DG4EVBY4Ng1mGSTCCL4ogg16CMIE+bwGBAkJ+AQEB X-IronPort-AV: E=Sophos;i="5.07,541,1413244800"; d="scan'208";a="375478440" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 08 Dec 2014 23:58:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sB8NwkUZ001816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 23:58:46 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.205]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 17:58:46 -0600 From: "Eric Voit (evoit)" To: Xufeng Liu Thread-Topic: [Rtg-yang-coord] FW: New Version NRtg-yang-coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt Thread-Index: AdATQt6O9PjEH8VhQmap0Mi7ROwm1g== Date: Mon, 8 Dec 2014 23:58:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/cyhZa2og8HgvZds209N-EA8Tolk Cc: "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] FW: New Version NRtg-yang-coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 23:59:11 -0000 Hi Xufeng, In your draft vrid is the key to vrrp-instance. vrid is limited to the = range of 0...255. This is consistent with RFC5798 and other RFCs, local un= iqueness is fine because you are augmenting a specific device interface. Let's say I want to know all the participating hosts which make up the set = of routers in VRRP instance. How would I get that info? Eric > From: Rtg-yang-coord, December 08, 2014 1:32 PM >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, December 04, 2014 4:39 PM > To: Xufeng Liu; Athanasios Kyparlis; Xufeng Liu; Athanasios Kyparlis > Subject: New Version Notification for draft-liu-rtgwg-yang-vrrp-00.txt >=20 >=20 > A new version of I-D, draft-liu-rtgwg-yang-vrrp-00.txt has been successfu= lly > submitted by Xufeng Liu and posted to the IETF repository. >=20 > Name: draft-liu-rtgwg-yang-vrrp > Revision: 00 > Title: A YANG Data Model for Virtual Router Redundancy Protocol > (VRRP) > Document date: 2014-12-03 > Group: Individual Submission > Pages: 22 > URL: http://www.ietf.org/internet-drafts/draft-liu-rtgwg-yang-= vrrp-00.txt > Status: https://datatracker.ietf.org/doc/draft-liu-rtgwg-yang-vrr= p/ > Htmlized: http://tools.ietf.org/html/draft-liu-rtgwg-yang-vrrp-00 >=20 >=20 > Abstract: > This document describes a data model for Virtual Router Redundancy > Protocol (VRRP). Both version 2 and version 3 of VRRP are covered. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Dec 9 11:01:18 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8E1A8AF9 for ; Tue, 9 Dec 2014 11:01:17 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDbeYv4vt95k for ; Tue, 9 Dec 2014 11:01:15 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583BF1A8AF7 for ; Tue, 9 Dec 2014 11:01:14 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-d5-5486f6a0dc21 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.0C.03307.0A6F6845; Tue, 9 Dec 2014 14:18:24 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 14:01:11 -0500 From: Xufeng Liu To: "Eric Voit (evoit)" Thread-Topic: [Rtg-yang-coord] FW: New Version NRtg-yang-coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt Thread-Index: AdATQt6O9PjEH8VhQmap0Mi7ROwm1gAnK3sg Date: Tue, 9 Dec 2014 19:01:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXRPuO6Cb20hBtum61m8WL2ayeL389vM DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGg87VbAWTxCvubtnH0sC4RqiLkZNDQsBE 4sfjw8wQtpjEhXvr2boYuTiEBI4wSkw7soIRwlnGKPHy/Qsgh4ODTUBL4vJTR5AGEQFNia1v 17KB2MwC5hJrFq1jBLGFBSok1m1azQxSLiJQKTFvaS5EuZHE5bMv2EFsFgEViRtnf4K18gp4 S3z6uo4VxBYS8JG4uGAD2D2cAr4SO38fA6thBLrt+6k1TBCrxCVuPZnPBHGzgMSSPeeh7heV ePn4HyuErSQxaek5Voh6HYkFuz9BnaktsWzha2aIvYISJ2c+YZnAKDYLydhZSFpmIWmZhaRl ASPLKkaO0uLUstx0I4NNjMAYOSbBpruDcc9Ly0OMAhyMSjy8Bl9bQ4RYE8uKK3MPMUpzsCiJ 886qnRcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbFtwcEO2f4Vl/ZvDfEucT3/u1z/4IJL 72T/rOp3qF7Huz1VsvVW6m+jUk2mT9FdU4KM2FKjkn7abIpdtyfNPWv/vO+HDzg+LFYX6L97 3LsgWW4i9wPj73Z+dw6o55RFqBjteiblqdOs8tuebdu+5q/yzIwzP6T8kHhoqqkqlnY0jWsp l2pHnxJLcUaioRZzUXEiAAInZpByAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/G37ey5osjYPAlc8f4mKFNeLogmA Cc: "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] FW: New Version NRtg-yang-coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 19:01:17 -0000 Hi Eric, Thanks for looking at it.=20 Do you mean "find all the participating routers which make up the set of ro= uters in the VRRP instance"?=20 In the corresponding state branch: augment /if:interfaces-state/if:interface/ip:ipv4: +--ro vrrp +--ro vrrp-instance* [vrid] ... +--ro virtual-ipv4-addresses | +--ro virtual-ipv4-address* [ipv4-address] | +--ro ipv4-address inet:ipv4-address The list of ipv4-addresses contains not only the addresses configured on th= is router, but also addresses learned from participating routers. Do you think that this approach is ok? Thanks, - Xufeng > -----Original Message----- > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > Sent: Monday, December 08, 2014 6:59 PM > To: Xufeng Liu > Cc: Rtg-yang-coord@ietf.org > Subject: RE: [Rtg-yang-coord] FW: New Version NRtg-yang- > coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt >=20 > Hi Xufeng, >=20 > In your draft vrid is the key to vrrp-instance. vrid is limited to th= e range of > 0...255. This is consistent with RFC5798 and other RFCs, local uniquenes= s is fine > because you are augmenting a specific device interface. >=20 > Let's say I want to know all the participating hosts which make up the se= t of > routers in VRRP instance. How would I get that info? >=20 > Eric >=20 > > From: Rtg-yang-coord, December 08, 2014 1:32 PM > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Thursday, December 04, 2014 4:39 PM > > To: Xufeng Liu; Athanasios Kyparlis; Xufeng Liu; Athanasios Kyparlis > > Subject: New Version Notification for draft-liu-rtgwg-yang-vrrp-00.txt > > > > > > A new version of I-D, draft-liu-rtgwg-yang-vrrp-00.txt has been > > successfully submitted by Xufeng Liu and posted to the IETF repository. > > > > Name: draft-liu-rtgwg-yang-vrrp > > Revision: 00 > > Title: A YANG Data Model for Virtual Router Redundancy Protocol > > (VRRP) > > Document date: 2014-12-03 > > Group: Individual Submission > > Pages: 22 > > URL: http://www.ietf.org/internet-drafts/draft-liu-rtgwg-yan= g-vrrp- > 00.txt > > Status: https://datatracker.ietf.org/doc/draft-liu-rtgwg-yang-v= rrp/ > > Htmlized: http://tools.ietf.org/html/draft-liu-rtgwg-yang-vrrp-00 > > > > > > Abstract: > > This document describes a data model for Virtual Router Redundancy > > Protocol (VRRP). Both version 2 and version 3 of VRRP are covered. > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Dec 9 12:50:01 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AD71A01F6 for ; Tue, 9 Dec 2014 12:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec_qkRvQpJi6 for ; Tue, 9 Dec 2014 12:49:57 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id F19BD1A01CB for ; Tue, 9 Dec 2014 12:49:56 -0800 (PST) Received: (qmail 21583 invoked by uid 0); 9 Dec 2014 20:49:55 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 9 Dec 2014 20:49:55 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id RYps1p00e2SSUrH01YpvwC; Tue, 09 Dec 2014 13:49:55 -0700 X-Authority-Analysis: v=2.1 cv=dfgTgxne c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=zQP7CpKOAAAA:8 a=RWIhyqvsOIb-bm_tU_EA:9 a=wPNLvfGTeEIA: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:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=/vZ4Abpu/Spj+gs6HqyCmwe3vrQe+Bh5kxwa9jvrZOA=; b=RT7I3CCksM55HY4yHNPqe/5k14BgKerz+9KsEZJMtEM86SdRmud+Mjbd0tCfbVOrJYAiN7AfAtHVza4ZUebkVvwmus4719ZaiHKwGHSCBNbsGB+vzf2mf+/HtzGTE5k5; Received: from box313.bluehost.com ([69.89.31.113]:43556 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XyRjE-0007BS-9T for rtg-yang-coord@ietf.org; Tue, 09 Dec 2014 13:49:52 -0700 Message-ID: <5487606F.2070809@labn.net> Date: Tue, 09 Dec 2014 15:49:51 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Yang Coordination References: <54875F93.5050803@labn.net> In-Reply-To: <54875F93.5050803@labn.net> X-Forwarded-Message-Id: <54875F93.5050803@labn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/hvPcp6CSPG9MeLCZEE-FBHu6xvk Subject: [Rtg-yang-coord] Fwd: [Teas] Call for virtual interim meeting agenda items X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 20:49:59 -0000 FYI -------- Original Message -------- Subject: [Teas] Call for virtual interim meeting agenda items Date: Tue, 09 Dec 2014 15:46:11 -0500 From: Lou Berger To: TEAS WG CC: Matt Hartley , "BRUNGARD, DEBORAH A \(ATTLABS\)" Hello, As previously announced, the TEAS WG will be holding a virtual interim meeting Thursday, Dec. 18, on the topic of the TE Topology Yang Model. The objective of the meeting is to discuss what this model covers and how it relates/ties-in to other work. If you'd like to present or discuss a particular topic, please let us (TEAS Chairs and Secretary) know by the end of the weekend, Dec. 14. We know the time isn't perfect for all, particularly those in Asia, and this will be considered when scheduling future virtual interim meetings. Thank you, Lou and Deborah _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Dec 9 12:59:07 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F8E1A00FF for ; Tue, 9 Dec 2014 12:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxPuhusbsrHk for ; Tue, 9 Dec 2014 12:59:03 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9137A1A8826 for ; Tue, 9 Dec 2014 12:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4157; q=dns/txt; s=iport; t=1418158743; x=1419368343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3kp5sG1Trgm1QNLnpm7j1bCdrh3sSHUZEM6SGSEdSyI=; b=GeqycJ75Jbb4x2lWOMtTlDRiLdoua+3DUtnk1N+uBBTRElWVWat8hY4G xfkBx5uDlT8VcHr5L/neqXJXOmx7bKNzliZNha1TAs0rcFpeQXdB0WtFw xxvyJGjPVHdrNKBS2RFnLJBfhC2YxWLklk9+6Nt9/4RJ1o9D9vvucWQoC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAHphh1StJA2M/2dsb2JhbABZgwZSWATGFQqGCQKBLRYBAQEBAX2EAgEBAQMBAQEBawsFBwQCAQgRBAEBJAQHJwsUCQgCBA4FCYgnCA3XNwEBAQEBAQEBAQEBAQEBAQEBAQEBARePZCUzBwaDG4EVBY4Ng1mFPIENMIIviiCDXoIwgT5vgQNCfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,547,1413244800"; d="scan'208";a="379225343" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 09 Dec 2014 20:59:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB9Kx2Y3010985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 20:59:02 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 14:59:02 -0600 From: "Acee Lindem (acee)" To: Xufeng Liu Thread-Topic: [Rtg-yang-coord] New Version NRtg-yang-coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt Thread-Index: AQHQE/L1bwKIji5uWEuRIs4Hdqn06g== Date: Tue, 9 Dec 2014 20:59:02 +0000 Message-ID: <021C9CFC-72C2-4FEE-8867-5711575E2BBC@cisco.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.116.152.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9B4D7CCE7F9EE2438E982C50BD4E0CBA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Pxf_5JuxNPwvjh3_rVSt0YI5GoM Cc: "Rtg-yang-coord@ietf.org" , "Eric Voit \(evoit\)" Subject: Re: [Rtg-yang-coord] New Version NRtg-yang-coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 20:59:05 -0000 Hi Xufeng, On Dec 9, 2014, at 2:01 PM, Xufeng Liu wrote: > Hi Eric, >=20 > Thanks for looking at it.=20 >=20 > Do you mean "find all the participating routers which make up the set of = routers in the VRRP instance"?=20 > In the corresponding state branch: > augment /if:interfaces-state/if:interface/ip:ipv4: > +--ro vrrp > +--ro vrrp-instance* [vrid] > ... > +--ro virtual-ipv4-addresses > | +--ro virtual-ipv4-address* [ipv4-address] > | +--ro ipv4-address inet:ipv4-address >=20 > The list of ipv4-addresses contains not only the addresses configured on = this router, but also addresses learned from participating routers. As per RFC 5798, section 7.1, the routers should agree on the virtual addre= sses (see excerpt below):=20 If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event, and MAY indicate via network management that an error occurred. - MAY verify that "Count IPvX Addrs" and the list of IPvX address(es) match the IPvX Address(es) configured for the VRID. If the above check fails, the receiver SHOULD log the event and MAY indicate via network management that a misconfiguration was detected. I think what Eric asked for is a list of routers participating in the VRRP = protocol for the VRRP Instance. However, the protocol doesn=92t provide thi= s state - the only thing you know for certain is the current master.=20 Thanks, Acee=20 >=20 > Do you think that this approach is ok? >=20 > Thanks, >=20 > - Xufeng >=20 >> -----Original Message----- >> From: Eric Voit (evoit) [mailto:evoit@cisco.com] >> Sent: Monday, December 08, 2014 6:59 PM >> To: Xufeng Liu >> Cc: Rtg-yang-coord@ietf.org >> Subject: RE: [Rtg-yang-coord] FW: New Version NRtg-yang- >> coord@ietf.orgotification for draft-liu-rtgwg-yang-vrrp-00.txt >>=20 >> Hi Xufeng, >>=20 >> In your draft vrid is the key to vrrp-instance. vrid is limited to t= he range of >> 0...255. This is consistent with RFC5798 and other RFCs, local uniquene= ss is fine >> because you are augmenting a specific device interface. >>=20 >> Let's say I want to know all the participating hosts which make up the s= et of >> routers in VRRP instance. How would I get that info? >>=20 >> Eric >>=20 >>> From: Rtg-yang-coord, December 08, 2014 1:32 PM >>>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Thursday, December 04, 2014 4:39 PM >>> To: Xufeng Liu; Athanasios Kyparlis; Xufeng Liu; Athanasios Kyparlis >>> Subject: New Version Notification for draft-liu-rtgwg-yang-vrrp-00.txt >>>=20 >>>=20 >>> A new version of I-D, draft-liu-rtgwg-yang-vrrp-00.txt has been >>> successfully submitted by Xufeng Liu and posted to the IETF repository. >>>=20 >>> Name: draft-liu-rtgwg-yang-vrrp >>> Revision: 00 >>> Title: A YANG Data Model for Virtual Router Redundancy Protocol >>> (VRRP) >>> Document date: 2014-12-03 >>> Group: Individual Submission >>> Pages: 22 >>> URL: http://www.ietf.org/internet-drafts/draft-liu-rtgwg-yan= g-vrrp- >> 00.txt >>> Status: https://datatracker.ietf.org/doc/draft-liu-rtgwg-yang-v= rrp/ >>> Htmlized: http://tools.ietf.org/html/draft-liu-rtgwg-yang-vrrp-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes a data model for Virtual Router Redundancy >>> Protocol (VRRP). Both version 2 and version 3 of VRRP are covered. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.i= etf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Dec 10 12:41:59 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E021A907D for ; Mon, 8 Dec 2014 07:43:23 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmBeaqA2WwwT for ; Mon, 8 Dec 2014 07:43:17 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E4C1A6FFE for ; Mon, 8 Dec 2014 07:43:17 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-94-54856a9d2e31 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 57.8A.25146.D9A65845; Mon, 8 Dec 2014 10:08:45 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 10:43:15 -0500 From: Xufeng Liu To: "Rtg-yang-coord@ietf.org" Thread-Topic: New Version Notification for draft-liu-rtgwg-yang-vrrp-00.txt Thread-Index: AQHQEArL9ecTkExqVUuxoAx41L6fg5yF2yxg Date: Mon, 8 Dec 2014 15:43:14 +0000 Message-ID: References: <20141204213925.24134.22081.idtracker@ietfa.amsl.com> In-Reply-To: <20141204213925.24134.22081.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyuXSPn+7crNYQg+NXrC1+P7/N7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBX/9Asu8Vacff6HuYFxCW8XIyeHhICJxOEz85khbDGJC/fW s3UxcnEICRxhlJjc9psRwlnGKDF352f2LkYODjYBLYnLTx1BGkQEzCWaZ58BaxYW8JKYv3Ur C0TcW+LN8+1sELaRRMemDlYQm0VARWLNxLWMIDYvUE37gmOMICOFBBwlni2yAAlzCjhJvFvQ DDaGEeie76fWMIHYzALiEreezGeCuFNAYsme81A3i0q8fPyPFcJWkpi09BwryEhmAU2J9bv0 IVoVJaZ0P2SH2CoocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjFylBanluWmGxluYgQG/DEJ NscdjAs+WR5iFOBgVOLh3bC4JUSINbGsuDL3EKM0B4uSOK9m9bxgIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYx+/9k7br7VkCy4IOi0lKW4iuvvd/V5Jw4vn8f65PLUefy7r9ikz3oh+3Nm YKfX+8eTZn4yVV/olpe16Piz1c9Cpy+xKT+a9Yn1wJ+Dwj5HtF5YPIh9kMp1/dPZVIY2B65W Nitmq9RVb0PmWE6/yXXSUP9v+PXCkjSFj3PmbbnnyqwSkXyOd+saJZbijERDLeai4kQAOa90 2FkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/6vpxuPQqLDWvx_dSFBdkR8J1FHI X-Mailman-Approved-At: Wed, 10 Dec 2014 12:41:58 -0800 Subject: [Rtg-yang-coord] FW: New Version Notification for draft-liu-rtgwg-yang-vrrp-00.txt X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 15:43:24 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXks IERlY2VtYmVyIDA0LCAyMDE0IDQ6MzkgUE0NClRvOiBYdWZlbmcgTGl1OyBBdGhhbmFzaW9zIEt5 cGFybGlzOyBYdWZlbmcgTGl1OyBBdGhhbmFzaW9zIEt5cGFybGlzDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1ydGd3Zy15YW5nLXZycnAtMDAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxpdS1ydGd3Zy15YW5nLXZycnAtMDAudHh0 IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWHVmZW5nIExpdSBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1saXUtcnRnd2cteWFuZy12 cnJwDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJQSBZQU5HIERhdGEgTW9kZWwgZm9yIFZpcnR1YWwg Um91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wgKFZSUlApDQpEb2N1bWVudCBkYXRlOgkyMDE0LTEy LTAzDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMg0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1ydGd3 Zy15YW5nLXZycnAtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbGl1LXJ0Z3dnLXlhbmctdnJycC8NCkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtcnRnd2cteWFuZy12cnJwLTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9kZWwgZm9y IFZpcnR1YWwgUm91dGVyIFJlZHVuZGFuY3kNCiAgIFByb3RvY29sIChWUlJQKS4gQm90aCB2ZXJz aW9uIDIgYW5kIHZlcnNpb24gMyBvZiBWUlJQIGFyZSBjb3ZlcmVkLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Dec 10 13:22:58 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6296E1A0171 for ; Wed, 10 Dec 2014 13:22: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9EeHUTK0E6V for ; Wed, 10 Dec 2014 13:22:53 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672C11A00A3 for ; Wed, 10 Dec 2014 13:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=694; q=dns/txt; s=iport; t=1418246573; x=1419456173; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=6jTTM2zItN81BJoV03/JKorFQQhUl154cEfT8ptnJvs=; b=kKtA8moBzjZLNmTgpcGy2+OuohTvMVSF9re7rgXVo68uAnom0ksGEBp7 qm0QYdR9CKwnppg/ed/kQDbY3QhCs5LruBvgJXAc+Dt6H6Hmr5jvAPiE7 5hAB/8cbFucSot/GSSRSiFdvVGS7VGb2LVIXDqjJFWcb83QVKWSKqNGBL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIIAIO5iFStJA2K/2dsb2JhbABZgwZSWASDAcBSgj2GDIECFgEBAQEBfYQNAgQ0VwEIHCgEMBsBBgUEEwmILw2kG40kjzoGlz4BK4EgkVOBTQWOAohxgQyCXIoTg1+Dbm4BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,553,1413244800"; d="scan'208";a="379568524" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 10 Dec 2014 21:22:39 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBALMcR5007967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Dec 2014 21:22:38 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 15:22:38 -0600 From: "Acee Lindem (acee)" To: Routing YANG Thread-Topic: OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" Thread-Index: AQHQFL9sZI6jJnSBTkWiIGV9XoGXjg== Date: Wed, 10 Dec 2014 21:22:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.199] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/HR0IsERHGlBGtyxBGZuC4jdWcsg Subject: [Rtg-yang-coord] FW: OSPF WG Poll for adoption of "Yang Data Model for OSPF Protocol" X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 21:22:55 -0000 RllJIC0gV2UgYXJlIHBvbGxpbmcgZm9yIGFjY2VwdGFuY2Ugb2YgdGhlIE9TUEYgWUFORyBtb2Rl bCBkcmFmdC4NClRoYW5rcywNCkFjZWUNCk9uIDEyLzIvMTQsIDc6NTEgUE0sICJBY2VlIExpbmRl bSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5XZan2dmUgYmVlbiB3b3JraW5n IG9uIHRoaXMgZm9yIHNldmVyYWwgSUVURnMgbm93IGFuZCB0aGUgY2hhaXJzIGJlbGlldmUgaXQN Cj5pcyB0aW1lIGZvciBXRyBhZG9wdGlvbi4gTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQgc3RhcnRl ZCBpbiB0aGUgTkVUTU9EIFdHLg0KPlBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb2Ygb3Bw b3NpdGlvbiBvZiBXRyBhZG9wdGlvbnMuIEhlcmUgaXMgYSBVUkwNCj5mb3IgeW91ciBjb252ZW5p ZW5jZToNCj4NCj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXlldW5nLW5ldG1vZC1vc3Bm LTAyLnR4dA0KPg0KPlRoYW5rcywNCj5BY2VlIGFuZCBBYmhheQ0KPiANCj4NCg0KDQo= From nobody Thu Dec 11 05:58:58 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529231A3B9F for ; Thu, 11 Dec 2014 05:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiVccEftenib for ; Thu, 11 Dec 2014 05:58:56 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id E815C1A1A20 for ; Thu, 11 Dec 2014 05:58:55 -0800 (PST) Received: (qmail 20033 invoked by uid 0); 11 Dec 2014 13:58:55 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 11 Dec 2014 13:58:55 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id SDyr1p00T2SSUrH01DyupM; Thu, 11 Dec 2014 06:58:55 -0700 X-Authority-Analysis: v=2.1 cv=OLu0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=pmb6BNNbAAAA:8 a=OTfaxyS_AAAA:8 a=0FD05c-RAAAA:8 a=AUd_NHdVAAAA:8 a=FmoMKUsJAAAA:8 a=U1k2Jpg8bEbLqpgLyY0A:9 a=wPNLvfGTeEIA: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:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=mlQKVOomwRZ/hMVa25F2IBR0xPvy/9RJv0bdokRtC/E=; b=0nofStg1HoeP3lSdJpmi+9LX1BHYzmoFGnaDIryjboRF0zCk/lbbNadqaRKI/A6DY7eQ9VqIkh9ORJURAkDdEf09C2T97EG+hin1aqSV12L4jQ1LE/hz/7477qWkb7Sk; Received: from box313.bluehost.com ([69.89.31.113]:43223 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Xz4GZ-00082d-Do for rtg-yang-coord@ietf.org; Thu, 11 Dec 2014 06:58:51 -0700 Message-ID: <5489A320.80506@labn.net> Date: Thu, 11 Dec 2014 08:58:56 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing YANG Coordination References: <5489970B.7070108@labn.net> In-Reply-To: <5489970B.7070108@labn.net> X-Forwarded-Message-Id: <5489970B.7070108@labn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/6NyPp2RxlghRZWLCjF8Mju8Ru0Y Subject: [Rtg-yang-coord] Fwd: [Teas] TE Topology YANG Model Design Team X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 13:58:57 -0000 FYI -------- Original Message -------- Subject: [Teas] TE Topology YANG Model Design Team Date: Thu, 11 Dec 2014 08:07:23 -0500 From: Lou Berger To: TEAS WG All, We have formed a WG Design Team whose objective is to deliver a TE Topology YANG Model draft in time for discussion in Dallas. It is our intent that the document will become a TEAS WG draft post Dallas. The scope of the design team is intentionally narrow and the work of the DT will need to be coordinated with other related YANG work -- and such coordination is the focus of next week's interim meeting*. The DT will be closed once we have a WG document adopted on this topic. While the DT has limited membership (and a limited lifespan), how the DT works to produce it's individual draft(s) is up to the DT. For example they may choose to publicize their calls/progress or not. We do appreciate that not all who volunteered are include. Those who are willing to provide input to the DT should contact them directly. Keep in mind that there will be plenty of opportunity for input, per normal WG process, once the DT's individual draft(s) are adopted as WG documents. Again, thank you to all who volunteered. * - Next week's interim is of course open to all -- and we have an open call for those who wish a discussion slot. The focus of the interim is on the scope of the TE Topology YANG model and how it relates/ties-in to other work. The members of the DT are: Vishnu Pavan Beeram Igor Bryskin Oscar Gonzalez De Dios Xufeng Liu Tarek Saad Himanshu Shah Deborah and Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Thu Dec 11 08:16:54 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0311ACF58; Thu, 11 Dec 2014 08:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMGRDGxcaAb7; Thu, 11 Dec 2014 08:16:41 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 734661A1B91; Thu, 11 Dec 2014 08:16:41 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 25331C1BE; Thu, 11 Dec 2014 11:16:41 -0500 (EST) Date: Thu, 11 Dec 2014 11:16:41 -0500 From: Jeffrey Haas To: netmod@ietf.org, rtg-yang-coord@ietf.org Message-ID: <20141211161640.GC16279@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/sdZbO8hr5EuAUdV-NMsCGOmMW3w Subject: [Rtg-yang-coord] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 16:16:42 -0000 In http://tools.ietf.org/html/draft-wang-i2rs-rib-data-model-00, please consider "container tunnel-encap": container tunnel-encap { uses tunnel-encap; choice nexthop-second-encap-or-not{ case nexthop-second-encap{ container nexthop-second-encap{ description "the two encapsulating nexthop.One example is a Pseudowire - which is MPLS over some transport (MPLS or GRE for instance). Another example is VxLAN over IP. "; uses tunnel-encap; choice nexthop-third-encap-or-not{ case nexthop-third-encap { container nexthop-third-encap{ description "the three encapsulating nexthop.One exampl is Option A -L3VPN OVER MPLS tunnel and MPLS over TE tunnel"; uses tunnel-encap; [...] My question to the yang experts are whether there's been any discussion about generally recursive modeling? In the data model above, five levels are accommodated - thankfully using groupings. This precludes a sixth or later level of recursion. Please note that I'm not looking to specifically discuss the contents of this specific modeling, just its impact on the language. Such constructs may be common in certain types of routing modeling. -- Jeff From nobody Thu Dec 11 08:27:04 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A191A1BAA; Thu, 11 Dec 2014 08:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvIalwAh_qA2; Thu, 11 Dec 2014 08:27:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CA91A1AF8; Thu, 11 Dec 2014 08:27:00 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id D1FA414050B; Thu, 11 Dec 2014 17:26:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418315218; bh=06hbYHhB6ZOVYHrbLqvBO0gMu5Yh+0k+wFxHgFwBp04=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aB14xKCs9PLdxcHJGB8IiFs8zoUZO+yHOSxq1dW9Zz+oQt9GnfMeH01uv+n/CIpUH UxZ1ZjwzF+ELZTYv2edt+9ymGb5OT+szAhUGAfX93tO1bFK4o1i7FsXtuRQyNUwoTu qqjolW2JAGYcQv+Re97cHQjvpYN+jNVy5xg38k3M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20141211161640.GC16279@pfrc> Date: Thu, 11 Dec 2014 17:26:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141211161640.GC16279@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/ejX2an5LqievfTo8Z8A9yiCj7to Cc: rtg-yang-coord@ietf.org, netmod@ietf.org Subject: Re: [Rtg-yang-coord] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 16:27:02 -0000 Hi Jeff, > On 11 Dec 2014, at 17:16, Jeffrey Haas wrote: >=20 > In http://tools.ietf.org/html/draft-wang-i2rs-rib-data-model-00, = please > consider "container tunnel-encap": >=20 > container tunnel-encap { > uses tunnel-encap; > choice nexthop-second-encap-or-not{ > case nexthop-second-encap{ > container nexthop-second-encap{ > description > "the two encapsulating nexthop.One example is a = Pseudowire - which is MPLS over > some transport (MPLS or GRE for instance). Another = example is VxLAN > over IP. "; > uses tunnel-encap; > choice nexthop-third-encap-or-not{ > case nexthop-third-encap { > container nexthop-third-encap{ > description > "the three encapsulating nexthop.One exampl is = Option A -L3VPN OVER MPLS tunnel and MPLS over TE tunnel"; > uses tunnel-encap; > [...] >=20 > My question to the yang experts are whether there's been any = discussion > about generally recursive modeling? In the data model above, five = levels > are accommodated - thankfully using groupings. This precludes a sixth = or > later level of recursion. Yes, this has already been discussed several times. It was a deliberate = design decision to avoid recursive structures in YANG. They can be = emulated via leafrefs though. For example, recursive next-hop-list is = implemented this way in draft-ietf-netmod-routing-cfg-16. Lada=20 >=20 > Please note that I'm not looking to specifically discuss the contents = of > this specific modeling, just its impact on the language. Such = constructs > may be common in certain types of routing modeling. >=20 > -- Jeff >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 12 01:40:52 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485D31AC435; Fri, 12 Dec 2014 01:40: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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7NYUKpsCh6C; Fri, 12 Dec 2014 01:40:49 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2121A19E5; Fri, 12 Dec 2014 01:40:47 -0800 (PST) Received: from pc6 (81.151.166.145) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 09:37:00 +0000 Message-ID: <01d401d015ef$281b7700$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas , , References: <20141211161640.GC16279@pfrc> Date: Fri, 12 Dec 2014 09:36:45 +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: [81.151.166.145] X-ClientProxiedBy: DB4PR05CA0032.eurprd05.prod.outlook.com (25.160.40.42) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:DBXPR07MB063; X-Forefront-PRVS: 04238CD941 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(51704005)(189002)(13464003)(84392001)(105586002)(14496001)(99396003)(50226001)(62236002)(1556002)(64706001)(107046002)(4396001)(230783001)(20776003)(87976001)(106356001)(19580405001)(19580395003)(66066001)(120916001)(107886001)(47776003)(97736003)(101416001)(23756003)(44716002)(68736005)(50466002)(77156002)(1456003)(77096005)(31966008)(15975445007)(122386002)(86362001)(33646002)(81816999)(2201001)(61296003)(46102003)(81686999)(40100003)(50986999)(21056001)(62966003)(92566001)(42186005)(76176999)(89996001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/8sUm3dOeADwU8DAEocWqSc5zlos Subject: Re: [Rtg-yang-coord] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 09:40:51 -0000 netmod WG list 12apr2013 >> Recursive schemas are not allowed in YANG, and I believe it was a >>design feature. >> >> Lada 15sep2014 Hello Vladimir, I have been arguing to have recursive containment for quite some time. Have a good number of use-cases to support. regards Balazs etc etc Tom Petch ----- Original Message ----- From: "Jeffrey Haas" To: ; Sent: Thursday, December 11, 2014 4:16 PM > In http://tools.ietf.org/html/draft-wang-i2rs-rib-data-model-00, please > consider "container tunnel-encap": > > container tunnel-encap { > uses tunnel-encap; > choice nexthop-second-encap-or-not{ > case nexthop-second-encap{ > container nexthop-second-encap{ > description > "the two encapsulating nexthop.One example is a Pseudowire - which is MPLS over > some transport (MPLS or GRE for instance). Another example is VxLAN > over IP. "; > uses tunnel-encap; > choice nexthop-third-encap-or-not{ > case nexthop-third-encap { > container nexthop-third-encap{ > description > "the three encapsulating nexthop.One exampl is Option A -L3VPN OVER MPLS tunnel and MPLS over TE tunnel"; > uses tunnel-encap; > [...] > > My question to the yang experts are whether there's been any discussion > about generally recursive modeling? In the data model above, five levels > are accommodated - thankfully using groupings. This precludes a sixth or > later level of recursion. > > Please note that I'm not looking to specifically discuss the contents of > this specific modeling, just its impact on the language. Such constructs > may be common in certain types of routing modeling. > > -- Jeff > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Fri Dec 12 11:14:57 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420E1A9024 for ; Fri, 12 Dec 2014 11:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4ZZ_asQmccE for ; Fri, 12 Dec 2014 11:14:53 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425531A1B45 for ; Fri, 12 Dec 2014 11:14:53 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so6474897lbd.17 for ; Fri, 12 Dec 2014 11:14:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TTEd44APWMqKBy1FqtLPAEB7F4GES1gD7QyGoePra3Y=; b=EgS4QU5r/+W1q0Q7ExAhLMl7Q9M9dalmXZzwb8sPN59YCyAyj/ZbY5/hq671SyDzzY gciBAxFgAghJkWbzGKCxU9x95IuFCUx2hNANhG3HojiqALShj2I952LaVMykUS+Z8/pz yVzBhH5j4GnjmMV2xacO2YPUeZlEPsIMkwHudLQLAmP+km8gtosHFsT3JnpbN6Glk6/u zlvDzN34reqCopDUsD48xj1Zd4ohZToNQ8Y2cbJSakJTsUz0Ag5iK7Ni1u/djYv2RO4e 03tdNw5mbbAxthCgMajKVlcdr9tLSLKeSJ2KctLBvpkcMV+P+kD0BSkEvxMd1zht29FF E7vQ== X-Gm-Message-State: ALoCoQmNykqiW61RZ7ldRRyDJJHVjLU3m2wK2FwHDNYmWqgarNAjpZhcDmwvn/5wjOiVGTzaAVCp MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr13530855laf.82.1418411691587; Fri, 12 Dec 2014 11:14:51 -0800 (PST) Received: by 10.112.157.233 with HTTP; Fri, 12 Dec 2014 11:14:51 -0800 (PST) In-Reply-To: References: <20141211161640.GC16279@pfrc> Date: Fri, 12 Dec 2014 11:14:51 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/4AeueL-m5bvksq6upf8YLv-avC8 Cc: Jeffrey Haas , "rtg-yang-coord@ietf.org" , Ladislav Lhotka , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:14:55 -0000 On Fri, Dec 12, 2014 at 7:43 AM, Kent Watsen wrote: > > >>Yes, this has already been discussed several times. It was a deliberate >>design decision to avoid recursive structures in YANG. > > > As I understand it, the decision was made was to enable parsers to be > deterministic. Is that right? - how is it then that other MLs (XSD) can > support recursion? > > My hope is that YANG can support recursion by requiring a "max-depth" or > similar attribute. Most of my use-cases only need a handful number of > recursions. Could something like a max-depth attribute be used to enable > recursion in YANG? > IMO the use of groupings and grouping expansion is not the right model for schema recursion. Automatic expansion to some arbitrary depth is a hack. Complex types that are not automatically expanded at all are a better fit. (YANG 2.0 discussions already?) > Thanks, > Kent Andy From nobody Mon Dec 15 08:20:39 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10EF1ACF1D; Fri, 12 Dec 2014 10:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtc90VbUmdvz; Fri, 12 Dec 2014 10:03:41 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id BEC1B1A870B; Fri, 12 Dec 2014 10:03:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bjp/6l15Di+L9oJ8mxgW0OGcZRflvzfYexwsYmOdMctacaoeHcNBs88qLB3DGGNm; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XzUYv-0003JR-H9; Fri, 12 Dec 2014 13:03:33 -0500 Received: from 99.187.237.155 by webmail.earthlink.net with HTTP; Fri, 12 Dec 2014 13:03:32 -0500 Message-ID: <32660965.1418407413358.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Fri, 12 Dec 2014 10:03:32 -0800 (GMT-08:00) From: Randy Presuhn To: Kent Watsen , Ladislav Lhotka , Jeffrey Haas Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f129d1b29288448e67b74763b23d14c95350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/V_yHPm4jCoiMp2qN3CYpZkI80zg X-Mailman-Approved-At: Mon, 15 Dec 2014 08:20:30 -0800 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 18:03:50 -0000 Hi - >From: Kent Watsen >Sent: Dec 12, 2014 7:43 AM >To: Ladislav Lhotka , Jeffrey Haas >Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? > > > >>Yes, this has already been discussed several times. It was a deliberate >>design decision to avoid recursive structures in YANG. > > >As I understand it, the decision was made was to enable parsers to be >deterministic. Is that right? - how is it then that other MLs (XSD) can >support recursion? Ancient history note: in the CMIP / GDMO world object containment recursion was featured from the very outset. It caused no controversy. It did not complicate implementation of industrial-strength modeling language processors, protocol engines, agents, subagents, or managers. I'm not aware of it having caused any deployment troubles. With all classes being subclasses of "top", one can sensisbly argue that all containment in the CMIP world is effectively recursive. Subclass-specific containment rules ("name bindings" in that alternative universe) come for free as soon as one accepts the requirement to support extensibility without requiring reinitialization of the management infrastructure. The decision to separate name bindings (containment constraints) from class definitions was crucial, given the versioning rules and ability to define subclasses in that environment. Randy From nobody Mon Dec 15 08:21:13 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF11A8FD7; Fri, 12 Dec 2014 07:44:20 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qSsDdvdhPq9; Fri, 12 Dec 2014 07:44:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C374A1A87A0; Fri, 12 Dec 2014 07:44:18 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 15:43:56 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.216]) with mapi id 15.01.0031.000; Fri, 12 Dec 2014 15:43:56 +0000 From: Kent Watsen To: Ladislav Lhotka , Jeffrey Haas Thread-Topic: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? Thread-Index: AQHQFV9P9xddlsHcYUuSo/kVQJsE+ZyLxksA Date: Fri, 12 Dec 2014 15:43:55 +0000 Message-ID: References: <20141211161640.GC16279@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(230783001)(2656002)(87936001)(31966008)(4396001)(62966003)(83506001)(101416001)(50986999)(76176999)(21056001)(64706001)(20776003)(54356999)(77156002)(97736003)(99396003)(120916001)(102836002)(92566001)(105586002)(86362001)(46102003)(68736005)(107046002)(99286002)(106116001)(122556002)(66066001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <9BB0BB7A3C02EC4A8AC9B6DB87F7897B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/1ospPz8YBa0QrAopIFmFXFdkQ2A X-Mailman-Approved-At: Mon, 15 Dec 2014 08:21:11 -0800 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 15:44:20 -0000 >Yes, this has already been discussed several times. It was a deliberate >design decision to avoid recursive structures in YANG. As I understand it, the decision was made was to enable parsers to be deterministic. Is that right? - how is it then that other MLs (XSD) can support recursion? My hope is that YANG can support recursion by requiring a "max-depth" or similar attribute. Most of my use-cases only need a handful number of recursions. Could something like a max-depth attribute be used to enable recursion in YANG? Thanks, Kent From nobody Mon Dec 15 20:00:11 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3071A0263; Mon, 15 Dec 2014 19:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP7OyqmUbaue; Mon, 15 Dec 2014 19:59:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247CD1A0371; Mon, 15 Dec 2014 19:59:57 -0800 (PST) Received: from BL2PR05CA0035.namprd05.prod.outlook.com (10.255.226.35) by DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 16 Dec 2014 03:59:34 +0000 Received: from BN1AFFO11FD021.protection.gbl (2a01:111:f400:7c10::100) by BL2PR05CA0035.outlook.office365.com (2a01:111:e400:c04::35) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Tue, 16 Dec 2014 03:59:33 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD021.mail.protection.outlook.com (10.58.52.81) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Tue, 16 Dec 2014 03:59:33 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 15 Dec 2014 19:59:32 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id sBG3xTu29294; Mon, 15 Dec 2014 19:59:29 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id sBG3x51k015809; Mon, 15 Dec 2014 22:59:08 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201412160359.sBG3x51k015809@idle.juniper.net> To: Randy Presuhn In-Reply-To: <32660965.1418407413358.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Mon, 15 Dec 2014 22:59:05 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(47776003)(110136001)(81156004)(76506005)(77096005)(48376002)(20776003)(69596002)(230783001)(64706001)(120916001)(53416004)(62966003)(77156002)(106466001)(68736005)(105596002)(97736003)(50466002)(99396003)(4396001)(6806004)(107046002)(92566001)(103666002)(87936001)(21056001)(46102003)(84676001)(31966008)(54356999)(50986999)(86362001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB447; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601003); SRVR:DM2PR05MB447; X-Forefront-PRVS: 04270EF89C X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/vWE2lb7ni_42QyVIR2FcEyLOgk8 Cc: Jeffrey Haas , "rtg-yang-coord@ietf.org" , Kent Watsen , Ladislav Lhotka , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 03:59:59 -0000 Randy Presuhn writes: >Ancient history note: in the CMIP / GDMO world object containment >recursion was featured from the very outset. It caused no controversy. NETCONF rejected the idea of "objects". Config data is just data, nothing more magical. >It did not complicate implementation of industrial-strength modeling >language processors, protocol engines, agents, subagents, or managers. Saying that CMIP and GDMO were not complicated is, well, odd. Even the small port of the ocean that NETCONF boils turns out to be fairly complicated. Thanks, Phil From nobody Tue Dec 16 01:31:52 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190151ACD59; Tue, 16 Dec 2014 01:31:50 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWD8hEbawuK7; Tue, 16 Dec 2014 01:31:48 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D706E1A90DC; Tue, 16 Dec 2014 01:31:47 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2628F1CC0238; Tue, 16 Dec 2014 10:31:45 +0100 (CET) From: Ladislav Lhotka To: Randy Presuhn , Phil Shafer In-Reply-To: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> References: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 16 Dec 2014 10:31:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Mrzzz94ag50xLgV7B8OBNwsEqUg Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 09:31:50 -0000 Randy Presuhn writes: > Hi - > >>From: Phil Shafer >>Sent: Dec 15, 2014 7:59 PM >>To: Randy Presuhn >>Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >>Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? >> >>Randy Presuhn writes: >>>Ancient history note: in the CMIP / GDMO world object containment >>>recursion was featured from the very outset. It caused no controversy. >> >>NETCONF rejected the idea of "objects". Config data is just data, >>nothing more magical. > > I still believe that the lack of an underlying metamodel makes > the netconf universe far more complicated than it needs to be, > particularly when it comes to, say, managing open systems with hot- > swappable components from multiple vendors or dealing with multiple > versions of a kind of managed resource residing within a single > system. I now tend to agree with this, due to all the troubles we have with concurrent access through different management interfaces, ephemeral datastores, etc. Are there any documents left from those ancient times where I could read about the CMIP metamodel? Thanks, Lada > >>>It did not complicate implementation of industrial-strength modeling >>>language processors, protocol engines, agents, subagents, or managers. >> >>Saying that CMIP and GDMO were not complicated is, well, odd. Even >>the small port of the ocean that NETCONF boils turns out to be >>fairly complicated. > > Apologies if this comes across as a rant. It's hard to hold my > tongue watching NETCONF flailing on issues that were dealt with > a quarter century ago. :-) > > There's a lot of IETF folklore about CMIP/GDMO being complicated. > Much of that is, well, folklore, with roots in a highly politicized > environment dominated by FUD marketing masquerading as technological > insight. I've worked through the muck of the goriest details of the > implementation of both CMIP/GDMO and SNMP/SMI technologies. > Both sets have their strengths and weaknesses, but I still believe > that CMIP/GDMO came closer to getting things right for dealing with > systems complex enough to be interesting. > > (Rest of rant deleted, because it would just waste this group's > time.) > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Dec 16 04:02:03 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48661A1ACE for ; Tue, 16 Dec 2014 04:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxSNo1yuGNLr for ; Tue, 16 Dec 2014 04:01:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508031A01F0 for ; Tue, 16 Dec 2014 04:01:58 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 7CD52264605 for ; Tue, 16 Dec 2014 13:01:56 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5A6CF4C0D8 for ; Tue, 16 Dec 2014 13:01:56 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 13:01:56 +0100 From: To: "rtg-yang-coord@ietf.org" Thread-Topic: Address family management in YANG models Thread-Index: AdAZKAlaiamzkDPETEWo5K8clxKHLA== Date: Tue, 16 Dec 2014 12:01:56 +0000 Message-ID: <32371_1418731316_54901F34_32371_1164_1_9E32478DFA9976438E7A22F69B08FF920C746B07@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/o5UCG3C-hR7pAD-2YBbpQOhy0Jo Subject: [Rtg-yang-coord] Address family management in YANG models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 12:02:02 -0000 --_004_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_" --_000_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I don't know if the topic has already been discussed or not. In most of protocols we have to support multiple address families. In order= to have more consistencies between data model, it would be good to agree o= n common way to reference address-families and not let everyone using strin= gs, as strings will let open some doors to misalignment between vendors. Current core routing model introduces the address-family identity which is = good. Could we agree on using identityref using this base for AF type ? In case of yes, where should the AF be defined ? All in core routing model = ? How to manage extensions ? Current model proposes twos AFs ipv4 and ipv6= but may be a renaming is required to be more precise. ipv4 -> ipv4-unicast ipv6 -> ipv6-unicast Thoughts ? [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert NoF phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I don’t know if the topic has already been dis= cussed or not.

In most of protocols we have to support multiple add= ress families. In order to have more consistencies between data model, it w= ould be good to agree on common way to reference address-families and not l= et everyone using strings, as strings will let open some doors to misalignment between vendors.

 

Current core routing model introduces the address-fa= mily identity which is good.

Could we agree on using identityref using this base = for AF type ?

 

In case of yes, where should the AF be defined ? All= in core routing model ? How to manage extensions ? Current model  pro= poses twos AFs ipv4 and ipv6 but may be a renaming is required to be more p= recise.

 

ipv4 -> ipv4-unicast

ipv6 -> ipv6-unicast

 

 

Thoughts ?

 

 

 

3D"O=

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert NoF=

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_-- --_004_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Tue, 16 Dec 2014 12:01:56 GMT"; modification-date="Tue, 16 Dec 2014 12:01:56 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_9E32478DFA9976438E7A22F69B08FF920C746B07OPEXCLILM34corp_-- From nobody Tue Dec 16 04:13:49 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69E1A1AA6 for ; Tue, 16 Dec 2014 04:13:46 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-_YZUZT7V23 for ; Tue, 16 Dec 2014 04:13:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808BD1A1AA5 for ; Tue, 16 Dec 2014 04:13:44 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0060418C464; Tue, 16 Dec 2014 13:13:43 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D423127C1CB; Tue, 16 Dec 2014 13:13:42 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 13:13:43 +0100 From: To: Ladislav Lhotka , "rtg-yang-coord@ietf.org" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdA Date: Tue, 16 Dec 2014 12:13:41 +0000 Message-ID: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/dsfW1bKYxboTvReV429H95jOmzk Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 12:13:46 -0000 SGkgTGFkYSwNCg0KSSB3b3VsZCBiZSBpbiBmYXZvciBvZiByZW1vdmluZyByb3V0ZS1maWx0ZXJz IGZyb20gdGhlIGNvcmUgcm91dGluZyBtb2RlbCBhbmQgbGV0IGFub3RoZXIgIlJvdXRlIFBvbGlj eSIgWWFuZyBtb2RlbCBhdWdtZW50cyBpdCBpbiBmdXR1cmUuDQpSb3V0ZSBwb2xpY3kgZGVmaW5p dGlvbiBpbiBZQU5HIHdpbGwgYmUgYSBoYXJkIHdvcmsgYW5kIGl0IHdvdWxkIGJlIGJldHRlciB0 byByZXN0YXJ0IGZyb20gc2NyYXRjaCByYXRoZXIgdGhhbiBhZGRpbmcgc29tZSBkZXNpZ24gY29u c3RyYWludHMgZnJvbSB0aGUgYmVnaW5uaW5nLg0KDQpSZWdhcmRzLA0KDQpTdGVwaGFuZQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnRnLXlhbmctY29vcmQgW21haWx0bzpy dGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFkaXNsYXYgTGhv dGthDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNSwgMjAxNCAxNDoxMg0KVG86IHJ0Zy15YW5n LWNvb3JkQGlldGYub3JnDQpTdWJqZWN0OiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJv dXRlIGZpbHRlcnMNCg0KSGksDQoNCnRoaXMgaXNzdWUgcmVmZXJzIHRoZSBZQU5HIG1vZHVsZSAi aWV0Zi1yb3V0aW5nIiBjb250YWluZWQgaW4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMTYNCg0KUGxlYXNlIGluZGljYXRlIHlvdXIg cHJlZmVyZW5jZSBvciBhZGQgY29tbWVudHMuDQoNCioqKioqIDpSMDE6IHJvdXRlIGZpbHRlcnMN CiAgICAgIEluIC0xNiwgcm91dGUgZmlsdGVycyBhcmUgZGVmaW5lZCBhcyBzdHVicyB3aXRoIHRo ZSBhc3N1bXB0aW9uDQogICAgICB0aGF0IHJlYWwgcm91dGUgZmlsdGVyaW5nIGZyYW1ld29ya3Mg d2lsbCBiZSBkZXZlbG9wZWQNCiAgICAgIGxhdGVyLiBUaGlzIGNvdWxkIHdvcmsgcHJvdmlkZWQg dGhhdCBzdWNoIGZyYW1ld29ya3MgY2FuIGFjY2VwdA0KICAgICAgdGhlIGNvbnRyb2wgcG9pbnRz IGZvciBhcHBseWluZyByb3V0ZSBmaWx0ZXJzIGFzIHRoZXkgYXJlDQogICAgICBkZWZpbmVkIGlu IC0xNiwgaS5lLiAoaSnCoGJldHdlZW4gcm91dGluZyBwcm90b2NvbCBpbnN0YW5jZXMgYW5kDQog ICAgICBjb25uZWN0ZWQgUklCcywgYW5kIChpaSnCoGJldHdlZW4gUklCcy4NCg0KKioqKioqIFNv bHV0aW9uIFIwMS0xDQogICAgICAgTm8gY2hhbmdlLg0KDQoqKioqKiogU29sdXRpb24gUjAxLTIN CiAgICAgICBLZWVwIHRoZSBzdHViIHJvdXRlIGZpbHRlcnMgYnV0IGNoYW5nZSB0aGUgY29udHJv bCBwb2ludHMuDQoNCioqKioqKiBTb2x1dGlvbiBSMDEtMw0KICAgICAgIFJlbW92ZSByb3V0ZSBm aWx0ZXJzIGZyb20gdGhlIGlldGYtcm91dGluZyBtb2R1bGUuIEZ1dHVyZSByb3V0ZQ0KICAgICAg IGZpbHRlcmluZyBmcmFtZXdvcmtzIHdpbGwgZGVmaW5lIHRoZSBjb250cm9sIHBvaW50cyBhbmQg YXVnbWVudA0KICAgICAgIGlldGYtcm91dGluZyBhY2NvcmRpbmdseS4NCg0KDQotLSANCkxhZGlz bGF2IExob3RrYSwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSdGcteWFuZy1jb29yZCBt YWlsaW5nIGxpc3QNClJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Dec 16 05:04:57 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4DB1ACD5D for ; Tue, 16 Dec 2014 05:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA1uMv76AfHh for ; Tue, 16 Dec 2014 05:04:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169741ACD65 for ; Tue, 16 Dec 2014 05:04:48 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 0607013F9DC; Tue, 16 Dec 2014 14:04:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418735086; bh=5e++U43r2V7viJ5w7IEqhYoDc1hPuSei1gLRZCA0SSs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qAqr1+jXSYwEauXG2YFcFovMgkwKETr+syXpaWf8f9HGWbXjCMtWNtY/LFBF2wIM4 pTd5EL3Yv4IddRVDp6Mr2YQU/tPSkZFsO2ooCBx8QpPKx4gsC7cKCZB6pQ45t73g05 sLFlKWEyyFanjGaE+LrWIpsowgCGtNYPcQz6bd50= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <32371_1418731316_54901F34_32371_1164_1_9E32478DFA9976438E7A22F69B08FF920C746B07@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 16 Dec 2014 14:04:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79FC62E7-4A87-422F-990C-C7AE6ED37177@nic.cz> References: <32371_1418731316_54901F34_32371_1164_1_9E32478DFA9976438E7A22F69B08FF920C746B07@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: stephane.litkowski@orange.com X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/d87zYZFYY5to-DQ9Y2h7tl7jJvs Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] Address family management in YANG models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:04:56 -0000 Hi, > On 16 Dec 2014, at 13:01, = wrote: >=20 > Hi, > =20 > I don=E2=80=99t know if the topic has already been discussed or not. > In most of protocols we have to support multiple address families. In = order to have more consistencies between data model, it would be good to = agree on common way to reference address-families and not let everyone = using strings, as strings will let open some doors to misalignment = between vendors. Right, strings are a bad idea. The other two options are an enumeration = and identities. The main difference is in extensibility: an enumeration = can be extended only via publishing a new revision of the YANG module = where it is defined. Identities, on the other hand, allow for = distributed extensibility - new identities can be defined at any time by = writing a new module (standard or proprietary). Identities are also organized in a hierarchy so that, say, an identity = of a modified OSPF can be derived from regular OSPF, i.e. reuse its data = and add some extra if necessary. > =20 > Current core routing model introduces the address-family identity = which is good. > Could we agree on using identityref using this base for AF type ? > =20 > In case of yes, where should the AF be defined ? All in core routing = model ? I=E2=80=99d suggest to define each protocol=E2=80=99s identity in the = module where its configuration and state data are defined. Appendix C in = draft-ietf-netmod-routing-cfg-16 gives an example. > How to manage extensions ? As I said, it is easy and needn=E2=80=99t be tightly coordinated. Even = if two parties happen to choose same names, they will be distinct due to = namespaces. > Current model proposes twos AFs ipv4 and ipv6 but may be a renaming = is required to be more precise. > =20 > ipv4 -> ipv4-unicast > ipv6 -> ipv6-unicast Of course, go ahead and propose a better hierarchy. When designing it, I = guess it might be useful to know that YANG 1.1 will most likely support = multiple inheritance of identities, see https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-14 In our case it would be possible to treat address family and =E2=80=9Ccast= =E2=80=9D as two orthogonal facets: for instance, ipv4-unicast identity = could inherit from ipv4 and unicast. Lada=20 > =20 > =20 > Thoughts ? > =20 > =20 > =20 > > =20 > Stephane Litkowski=20 > Network Architect=20 > Orange/SCE/EQUANT/IBNF/ENDD/NDE > Orange Expert NoF > phone: +33 2 23 28 49 83=20 > mobile: +33 6 37 86 97 52=20 > stephane.litkowski@orange.com > =20 > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Dec 16 05:12:47 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0B1ACD83 for ; Tue, 16 Dec 2014 05:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEwNNDFtE3sM for ; Tue, 16 Dec 2014 05:12:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200BA1ACD8C for ; Tue, 16 Dec 2014 05:12:29 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id BFAD013FA15; Tue, 16 Dec 2014 14:12:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418735547; bh=RiKBLY8xkKQ+j4wQYedZ6D+59am3pRkSSAesrNdfgFk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dAf7zGeDi9/HkZbpC0Ixz/kfVNg4hQfsjfTBVPUw8nRm3Xbf0yGdUlEWkCZShVmIF geU0F7KMAUlR8avi05bImGusS3Z/cJZe79hBz8PKI56ky7WDQhoQZ+RSblVHoGcl/j U4pgpu0bQiV0Wb19WrIoa1HMEX0L94APD019Ioes= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 16 Dec 2014 14:12:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: Stephane Litkowski X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Ova9mgdewIe-N4lpdPKg1fTDZmA Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:12:45 -0000 > On 16 Dec 2014, at 13:13, = wrote: >=20 > Hi Lada, >=20 > I would be in favor of removing route-filters from the core routing = model and let another "Route Policy" Yang model augments it in future. > Route policy definition in YANG will be a hard work and it would be = better to restart from scratch rather than adding some design = constraints from the beginning. OK. It is also true that it won=E2=80=99t preclude anybody from defining = a temporary solution before a standard one is ready. Thanks, Lada >=20 > Regards, >=20 > Stephane >=20 > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of Ladislav Lhotka > Sent: Tuesday, November 25, 2014 14:12 > To: rtg-yang-coord@ietf.org > Subject: [Rtg-yang-coord] issue :R01: route filters >=20 > Hi, >=20 > this issue refers the YANG module "ietf-routing" contained in >=20 > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 >=20 > Please indicate your preference or add comments. >=20 > ***** :R01: route filters > In -16, route filters are defined as stubs with the assumption > that real route filtering frameworks will be developed > later. This could work provided that such frameworks can accept > the control points for applying route filters as they are > defined in -16, i.e. (i) between routing protocol instances and > connected RIBs, and (ii) between RIBs. >=20 > ****** Solution R01-1 > No change. >=20 > ****** Solution R01-2 > Keep the stub route filters but change the control points. >=20 > ****** Solution R01-3 > Remove route filters from the ietf-routing module. Future route > filtering frameworks will define the control points and augment > ietf-routing accordingly. >=20 >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Dec 16 06:02:16 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA211A1B16 for ; Tue, 16 Dec 2014 06:02:15 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN0N0he41qr4 for ; Tue, 16 Dec 2014 06:02:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22D61A1AC2 for ; Tue, 16 Dec 2014 06:02:10 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 0D1892AC397; Tue, 16 Dec 2014 15:02:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id DA0DE2C08B; Tue, 16 Dec 2014 15:02:08 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 15:02:09 +0100 From: To: Ladislav Lhotka Thread-Topic: [Rtg-yang-coord] Address family management in YANG models Thread-Index: AdAZKAlaiamzkDPETEWo5K8clxKHLAAAHHWAAAPJFnA= Date: Tue, 16 Dec 2014 14:02:08 +0000 Message-ID: <11159_1418738528_54903B60_11159_2232_1_9E32478DFA9976438E7A22F69B08FF920C746C2F@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <32371_1418731316_54901F34_32371_1164_1_9E32478DFA9976438E7A22F69B08FF920C746B07@OPEXCLILM34.corporate.adroot.infra.ftgroup> <79FC62E7-4A87-422F-990C-C7AE6ED37177@nic.cz> In-Reply-To: <79FC62E7-4A87-422F-990C-C7AE6ED37177@nic.cz> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.133922 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/mnrN9RwJrKKmJLTE05qdX-zlhZI Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] Address family management in YANG models X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 14:02:15 -0000 SGkgTGFkYSwNCg0KVGhhbmtzIGZvciBhZGRpbmcgeW91ciB2aWV3IG9uIHRoZSB0b3BpYy4NCg0K SSBhZ3JlZSB0aGF0IHVzaW5nIGlkZW50aXR5IGZvciBBRiBzb3VuZHMgdGhlIG1vcmUgcmVhc29u YWJsZSBzb2x1dGlvbi4NCg0KRm9yIHRoZSBwbGFjZSBvZiBkZWZpbml0aW9uIG9mIHRoZSBBRiBp ZGVudGl0eSwgd2UgbmVlZCB0byBhZ3JlZSBvbiB3aGF0IGtpbmQgb2YgcHJvdG9jb2xzLiBJJ20g bm90IHN1cmUgdGhhdCByb3V0aW5nIHByb3RvY29sIG1vZGVscyBhcmUgYSBnb29kIHBsYWNlIHRv IGRlZmluZSBBRnMuIA0KTWF5IGJlIHdlIGNhbiBmb2xsb3cgd2hhdCB5b3Ugc3RhcnRlZCB0b2Rh eSA6DQotIElQdjQgdW5pY2FzdCBkZWZpbmVkIGluIElQdjQgdW5pY2FzdCByb3V0aW5nIG1hbmFn ZW1lbnQgKEJlZm9yZSBwb3N0aW5nIG15IHByZXZpb3VzIG1haWwsIEkgbWlzc2VkIHRoYXQgeW91 ciBkZWZpbmVkIGlwdjQtdW5pY2FzdCBpbiB0aGlzIG1vZHVsZSAuLi4pIC0+IGFscmVhZHkgZG9u ZQ0KLSBJUHY2IHVuaWNhc3QgZGVmaW5lZCBpbiBJUHY2IHVuaWNhc3Qgcm91dGluZyBtYW5hZ2Vt ZW50IC0+IGFscmVhZHkgZG9uZQ0KLSBJUHY0IG11bHRpY2FzdCBpbiBhIGZ1dHVyZSBtdWx0aWNh c3QgSVB2NCByb3V0aW5nIG1hbmFnZW1lbnQgbW9kdWxlDQotIElQdjYgbXVsdGljYXN0IGluIGEg ZnV0dXJlIG11bHRpY2FzdCBJUHY2IHJvdXRpbmcgbWFuYWdlbWVudCBtb2R1bGUNCi0gdnBuIGlw djQgYW5kIGlwdjYgaW4gYSBMM1ZQTiByb3V0aW5nIG1vZHVsZQ0KLSAuLi4NCg0KUmVnYXJkaW5n IHRoZSBoaWVyYXJjaHksIEkgaGF2ZSBubyBvcGluaW9uIHRvZGF5LCBpZiBhIGhpZXJhcmNoeSBp cyByZXF1aXJlZCBvciBub3QuDQoNCg0KSSdtIHdvbmRlcmluZyBpZiBhIG5ldyBhcHBlbmRpeCBv ciBzZWN0aW9uIGluIHlvdXIgZG9jdW1lbnQgKG5ldG1vZC1yb3V0aW5nLWNmZykgd291bGQgYmUg bmVjZXNzYXJ5IHRvIGRlc2NyaWJlIHN1Y2ggZ3VpZGVsaW5lIGZvciBjaGlsZCBtb2R1bGVzLg0K DQoNClN0ZXBoYW5lDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExhZGlz bGF2IExob3RrYSBbbWFpbHRvOmxob3RrYUBuaWMuY3pdIA0KU2VudDogVHVlc2RheSwgRGVjZW1i ZXIgMTYsIDIwMTQgMTQ6MDUNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBy dGcteWFuZy1jb29yZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gQWRk cmVzcyBmYW1pbHkgbWFuYWdlbWVudCBpbiBZQU5HIG1vZGVscw0KDQpIaSwNCg0KPiBPbiAxNiBE ZWMgMjAxNCwgYXQgMTM6MDEsIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gPHN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiAgDQo+IEkgZG9u 4oCZdCBrbm93IGlmIHRoZSB0b3BpYyBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBvciBub3Qu DQo+IEluIG1vc3Qgb2YgcHJvdG9jb2xzIHdlIGhhdmUgdG8gc3VwcG9ydCBtdWx0aXBsZSBhZGRy ZXNzIGZhbWlsaWVzLiBJbiBvcmRlciB0byBoYXZlIG1vcmUgY29uc2lzdGVuY2llcyBiZXR3ZWVu IGRhdGEgbW9kZWwsIGl0IHdvdWxkIGJlIGdvb2QgdG8gYWdyZWUgb24gY29tbW9uIHdheSB0byBy ZWZlcmVuY2UgYWRkcmVzcy1mYW1pbGllcyBhbmQgbm90IGxldCBldmVyeW9uZSB1c2luZyBzdHJp bmdzLCBhcyBzdHJpbmdzIHdpbGwgbGV0IG9wZW4gc29tZSBkb29ycyB0byBtaXNhbGlnbm1lbnQg YmV0d2VlbiB2ZW5kb3JzLg0KDQpSaWdodCwgc3RyaW5ncyBhcmUgYSBiYWQgaWRlYS4gVGhlIG90 aGVyIHR3byBvcHRpb25zIGFyZSBhbiBlbnVtZXJhdGlvbiBhbmQgaWRlbnRpdGllcy4gVGhlIG1h aW4gZGlmZmVyZW5jZSBpcyBpbiBleHRlbnNpYmlsaXR5OiBhbiBlbnVtZXJhdGlvbiBjYW4gYmUg ZXh0ZW5kZWQgb25seSB2aWEgcHVibGlzaGluZyBhIG5ldyByZXZpc2lvbiBvZiB0aGUgWUFORyBt b2R1bGUgd2hlcmUgaXQgaXMgZGVmaW5lZC4gSWRlbnRpdGllcywgb24gdGhlIG90aGVyIGhhbmQs IGFsbG93IGZvciBkaXN0cmlidXRlZCBleHRlbnNpYmlsaXR5IC0gbmV3IGlkZW50aXRpZXMgY2Fu IGJlIGRlZmluZWQgYXQgYW55IHRpbWUgYnkgd3JpdGluZyBhIG5ldyBtb2R1bGUgKHN0YW5kYXJk IG9yIHByb3ByaWV0YXJ5KS4NCg0KSWRlbnRpdGllcyBhcmUgYWxzbyBvcmdhbml6ZWQgaW4gYSBo aWVyYXJjaHkgc28gdGhhdCwgc2F5LCBhbiBpZGVudGl0eSBvZiBhIG1vZGlmaWVkIE9TUEYgY2Fu IGJlIGRlcml2ZWQgZnJvbSByZWd1bGFyIE9TUEYsIGkuZS4gcmV1c2UgaXRzIGRhdGEgYW5kIGFk ZCBzb21lIGV4dHJhIGlmIG5lY2Vzc2FyeS4NCg0KPiAgDQo+IEN1cnJlbnQgY29yZSByb3V0aW5n IG1vZGVsIGludHJvZHVjZXMgdGhlIGFkZHJlc3MtZmFtaWx5IGlkZW50aXR5IHdoaWNoIGlzIGdv b2QuDQo+IENvdWxkIHdlIGFncmVlIG9uIHVzaW5nIGlkZW50aXR5cmVmIHVzaW5nIHRoaXMgYmFz ZSBmb3IgQUYgdHlwZSA/DQo+ICANCj4gSW4gY2FzZSBvZiB5ZXMsIHdoZXJlIHNob3VsZCB0aGUg QUYgYmUgZGVmaW5lZCA/IEFsbCBpbiBjb3JlIHJvdXRpbmcgbW9kZWwgPw0KDQpJ4oCZZCBzdWdn ZXN0IHRvIGRlZmluZSBlYWNoIHByb3RvY29s4oCZcyBpZGVudGl0eSBpbiB0aGUgbW9kdWxlIHdo ZXJlIGl0cyBjb25maWd1cmF0aW9uIGFuZCBzdGF0ZSBkYXRhIGFyZSBkZWZpbmVkLiBBcHBlbmRp eCBDIGluIGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTE2IGdpdmVzIGFuIGV4YW1wbGUu DQoNCj4gSG93IHRvIG1hbmFnZSBleHRlbnNpb25zID8NCg0KQXMgSSBzYWlkLCBpdCBpcyBlYXN5 IGFuZCBuZWVkbuKAmXQgYmUgdGlnaHRseSBjb29yZGluYXRlZC4gRXZlbiBpZiB0d28gcGFydGll cyBoYXBwZW4gdG8gY2hvb3NlIHNhbWUgbmFtZXMsIHRoZXkgd2lsbCBiZSBkaXN0aW5jdCBkdWUg dG8gbmFtZXNwYWNlcy4NCg0KPiBDdXJyZW50IG1vZGVsICBwcm9wb3NlcyB0d29zIEFGcyBpcHY0 IGFuZCBpcHY2IGJ1dCBtYXkgYmUgYSByZW5hbWluZyBpcyByZXF1aXJlZCB0byBiZSBtb3JlIHBy ZWNpc2UuDQo+ICANCj4gaXB2NCAtPiBpcHY0LXVuaWNhc3QNCj4gaXB2NiAtPiBpcHY2LXVuaWNh c3QNCg0KT2YgY291cnNlLCBnbyBhaGVhZCBhbmQgcHJvcG9zZSBhIGJldHRlciBoaWVyYXJjaHku IFdoZW4gZGVzaWduaW5nIGl0LCBJIGd1ZXNzIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBrbm93IHRo YXQgWUFORyAxLjEgd2lsbCBtb3N0IGxpa2VseSBzdXBwb3J0IG11bHRpcGxlIGluaGVyaXRhbmNl IG9mIGlkZW50aXRpZXMsIHNlZQ0KDQpodHRwczovL3N2bi50b29scy5pZXRmLm9yZy9zdm4vd2cv bmV0bW9kL3lhbmctMS4xL2lzc3Vlcy5odG1sI3NlYy0xNA0KDQpJbiBvdXIgY2FzZSBpdCB3b3Vs ZCBiZSBwb3NzaWJsZSB0byB0cmVhdCBhZGRyZXNzIGZhbWlseSBhbmQg4oCcY2FzdOKAnSBhcyB0 d28gb3J0aG9nb25hbCBmYWNldHM6IGZvciBpbnN0YW5jZSwgaXB2NC11bmljYXN0IGlkZW50aXR5 IGNvdWxkIGluaGVyaXQgZnJvbSBpcHY0IGFuZCB1bmljYXN0Lg0KDQpMYWRhIA0KDQoNCj4gIA0K PiAgDQo+IFRob3VnaHRzID8NCj4gIA0KPiAgDQo+ICANCj4gPGltYWdlMDAxLmdpZj4NCj4gIA0K PiBTdGVwaGFuZSBMaXRrb3dza2kgDQo+IE5ldHdvcmsgQXJjaGl0ZWN0IA0KPiBPcmFuZ2UvU0NF L0VRVUFOVC9JQk5GL0VOREQvTkRFDQo+IE9yYW5nZSBFeHBlcnQgTm9GDQo+IHBob25lOiArMzMg MiAyMyAyOCA0OSA4MyANCj4gbW9iaWxlOiArMzMgNiAzNyA4NiA5NyA1MiANCj4gc3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb20NCj4gIA0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IENlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiBw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KPiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KPiBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0K PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ow0KPiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0 DQo+IFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCg0KLS0NCkxhZGlzbGF2IExob3RrYSwgQ1ouTklD IExhYnMNClBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoNCg0KDQoNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== From nobody Tue Dec 16 09:15:36 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F391A0381; Mon, 15 Dec 2014 20:59:02 -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=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfXFlGcsM8oa; Mon, 15 Dec 2014 20:59:00 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id D7A741A0371; Mon, 15 Dec 2014 20:58:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jh7+KvUihz+aKRbu6hImi2bcdUzTkpEYX0WomF/W6vahg3O7C8mWIzkCwWt2G1e9; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y0kDg-0007xw-E7; Mon, 15 Dec 2014 23:58:48 -0500 Received: from 76.254.48.105 by webmail.earthlink.net with HTTP; Mon, 15 Dec 2014 23:58:48 -0500 Message-ID: <13247066.1418705928467.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Mon, 15 Dec 2014 20:58:48 -0800 (GMT-08:00) From: Randy Presuhn To: Phil Shafer Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f4dee0f6dcd43b74052f3135c7aedb579350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Z5e_aUieEa-mi-uHfnrcKsFqx_A X-Mailman-Approved-At: Tue, 16 Dec 2014 09:15:24 -0800 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 04:59:02 -0000 Hi - >From: Phil Shafer >Sent: Dec 15, 2014 7:59 PM >To: Randy Presuhn >Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? > >Randy Presuhn writes: >>Ancient history note: in the CMIP / GDMO world object containment >>recursion was featured from the very outset. It caused no controversy. > >NETCONF rejected the idea of "objects". Config data is just data, >nothing more magical. I still believe that the lack of an underlying metamodel makes the netconf universe far more complicated than it needs to be, particularly when it comes to, say, managing open systems with hot- swappable components from multiple vendors or dealing with multiple versions of a kind of managed resource residing within a single system. >>It did not complicate implementation of industrial-strength modeling >>language processors, protocol engines, agents, subagents, or managers. > >Saying that CMIP and GDMO were not complicated is, well, odd. Even >the small port of the ocean that NETCONF boils turns out to be >fairly complicated. Apologies if this comes across as a rant. It's hard to hold my tongue watching NETCONF flailing on issues that were dealt with a quarter century ago. :-) There's a lot of IETF folklore about CMIP/GDMO being complicated. Much of that is, well, folklore, with roots in a highly politicized environment dominated by FUD marketing masquerading as technological insight. I've worked through the muck of the goriest details of the implementation of both CMIP/GDMO and SNMP/SMI technologies. Both sets have their strengths and weaknesses, but I still believe that CMIP/GDMO came closer to getting things right for dealing with systems complex enough to be interesting. (Rest of rant deleted, because it would just waste this group's time.) Randy From nobody Tue Dec 16 09:15:38 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447161A7004; Tue, 16 Dec 2014 09:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFzlEOWhTHDS; Tue, 16 Dec 2014 09:13:36 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79A901A7002; Tue, 16 Dec 2014 09:11:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RzkiT4MsJJaDy9pXU726kWHo2JTRbwZKc0jxjm05eVoms3FRTGg/3xtbWm0H9nkW; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Y0vev-0002Ju-MC; Tue, 16 Dec 2014 12:11:41 -0500 Received: from 99.187.238.7 by webmail.earthlink.net with HTTP; Tue, 16 Dec 2014 12:11:40 -0500 Message-ID: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 16 Dec 2014 09:11:41 -0800 (GMT-08:00) From: Randy Presuhn To: Ladislav Lhotka , Phil Shafer Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591fe963882b7e3ff01580a5205e93f6bfd5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/ksmL1iyWbZFw2CggwGy1vdRo5nU X-Mailman-Approved-At: Tue, 16 Dec 2014 09:15:25 -0800 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:13:40 -0000 Hi - >From: Ladislav Lhotka >Sent: Dec 16, 2014 1:31 AM >To: Randy Presuhn , Phil Shafer >Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" >Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? ... >Are there any documents left from those ancient times where I could read >about the CMIP metamodel? Yes. To avoid further pollution of this email list, I'll send you some links directly. I have a busy day before me, so I probably won't get to it until late tonight, California time. Randy From nobody Tue Dec 16 09:30:22 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490761A1B9B; Tue, 16 Dec 2014 09:30:21 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLl1rJGvWaXD; Tue, 16 Dec 2014 09:30:19 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6179C1A1BE0; Tue, 16 Dec 2014 09:30:19 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-f1-54900f486a9d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7B.E3.25146.84F00945; Tue, 16 Dec 2014 11:54:01 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 12:30:17 -0500 From: Jeff Tantsura To: Randy Presuhn , Ladislav Lhotka , Phil Shafer Thread-Topic: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? Thread-Index: AQHQGVNbQ5H2Mdw/80ekNKxb5DlrZZySRvUA Date: Tue, 16 Dec 2014 17:30:16 +0000 Message-ID: References: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> In-Reply-To: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <37406E5B8FA82F46936A7C53B69F8F11@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyuXRPuK4n/4QQg8832C0urJrLZjH/YiOr xZIz69kt7i88wm7x+/ltZgdWjyVLfjJ5XG+6yu7xY0MPu8emy3cYA1iiuGxSUnMyy1KL9O0S uDKm/rnAWvCNu+L3n+IGxilcXYycHBICJhLzP91kgbDFJC7cW8/WxcjFISRwhFFi4fztTBDO ckaJRdM2sIFUsQkYSPz/dhysQ0SgWOLTqweMIDazQJzE/+UnmUBsYQEXiQmHNrBC1LhK7Fz/ kxHCNpKYfmoWM4jNIqAqsen2GXYQm1fAXOLC2T9gM4UEwiQevd4FFucUCJc4++AN2F5GoOu+ n1rDBLFLXOLWk/lMEFcLSCzZc54ZwhaVePn4H9heUQE9iWcbNrNDxJUkPv6ezw7RqyOxYPcn NgjbWuLn2WVQM7Ulli18zQxxj6DEyZlPWCYwSsxCsm4WkvZZSNpnIWmfhaR9ASPrKkaO0uLU stx0I8NNjMD4PCbB5riDccEny0OMAhyMSjy8G/T7Q4RYE8uKK3MPMUpzsCiJ82pWzwsWEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwNhYHSS/3+OJ5VHjiH3SgUn+ZUGz1q469OuP4jnr808z /q960G/8/YrTp8ssMi/sVDp/cFyonl6QsPLy3QVyWhPWPY6eVVZXv2lbXW7RM9vWg1rCS07d OVkZfHOJxP1c1m/ndbe4S1aJNK6VMCpeeFuqYkdkiMUi006P8KLHKjP2HL3jMmXrjCQlluKM REMt5qLiRACCDbOfsAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/qL2odUy04WUES1pPh8m6_Y4fRno Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 17:30:21 -0000 Randy/others who are non-members - please do subscribe, otherwise any time you post it goes to list administrators and we have to explicitly allow/disallow your postings. Subscription page - https://www.ietf.org/mailman/listinfo/rtg-yang-coord =20 Thanks! Cheers, Jeff -----Original Message----- From: Randy Presuhn Reply-To: Randy Presuhn Date: Tuesday, December 16, 2014 at 9:11 AM To: Ladislav Lhotka , Phil Shafer Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? >Hi - > >>From: Ladislav Lhotka >>Sent: Dec 16, 2014 1:31 AM >>To: Randy Presuhn , Phil Shafer >> >>Cc: "rtg-yang-coord@ietf.org" , >>"netmod@ietf.org" >>Subject: Re: [netmod] [Rtg-yang-coord] Recursive modeling in Yang? >... >>Are there any documents left from those ancient times where I could read >>about the CMIP metamodel? > >Yes. To avoid further pollution of this email list, I'll >send you some links directly. I have a busy day before me, >so I probably won't get to it until late tonight, California >time. > >Randy > >_______________________________________________ >Rtg-yang-coord mailing list >Rtg-yang-coord@ietf.org >https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Dec 16 10:31:34 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A891ACD9B for ; Tue, 16 Dec 2014 10:31:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-4WgfdLi5Xu for ; Tue, 16 Dec 2014 10:31:31 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA911ACD9D for ; Tue, 16 Dec 2014 10:31:29 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so13435606wiw.15 for ; Tue, 16 Dec 2014 10:31:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=pfH19+d+CmE4DdABvAGRLB9WTQZxcwIZhGxdwoA8AMo=; b=U4B3fGiWG3j52EWd46jeP/Bc8+WLij84sQYAVltPfOxkL7Lcv88CyFSt8bFWSKbRHM UB9UUZkxauHG+mf1u/FXDJf2ELqcNTulTc/1z4A954IDrM+/c5LsIWfJpRZJmeyO3wZF e+3guct7PZnAodmWa4NJIYLGO+SH139K1s9kAGAmhCjVy4ixscfvOZQzjbiv2eArQboh ysS/qoHfJWsbpGdAKfQSPatTP8fwRAjQ8oeuKV9ohy8P/1cuYXDvgPObwCMJ+tSC4KY4 MvwmqVOZNCivdwkM+cOTndKXoTW/yQ1KcRhAJO49C6DIblMHrnaHJGRrYNtYwQKTDla+ KnlA== X-Gm-Message-State: ALoCoQleUAzza5IguyAGQvo3xHHuv157xWdPyHS46GprwdpicsbZTbTkWury2roDW7bnvdjTb8RE X-Received: by 10.194.62.19 with SMTP id u19mr54919901wjr.0.1418754688482; Tue, 16 Dec 2014 10:31:28 -0800 (PST) Received: from [192.168.1.4] (c-71-227-97-41.hsd1.mi.comcast.net. [71.227.97.41]) by mx.google.com with ESMTPSA id be2sm405675wjb.38.2014.12.16.10.31.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 10:31:26 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Christian Hopps In-Reply-To: Date: Tue, 16 Dec 2014 13:31:14 -0500 Message-Id: References: <33494220.1418749901574.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> To: Jeff Tantsura X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/-5SKdnBiYCBZDGL-2snBqIsb250 Cc: "rtg-yang-coord@ietf.org" , Christian Hopps , Phil Shafer , "netmod@ietf.org" , Ladislav Lhotka , Randy Presuhn Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:31:32 -0000 --Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822" --Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, there=E2=80=99s another option available to add the email address = to always accept. Once you do this it stops going into your holding = queue. I use this anytime someone sends non-spam mail. Chris. > On Dec 16, 2014, at 12:30 PM, Jeff Tantsura = wrote: >=20 > Randy/others who are non-members - please do subscribe, otherwise any = time > you post it goes to list administrators and we have to explicitly > allow/disallow your postings. > Subscription page - = https://www.ietf.org/mailman/listinfo/rtg-yang-coord = >=20 > Thanks! >=20 > Cheers, > Jeff --Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW, there=E2=80=99s another option available to add the = email address to always accept. Once you do this it stops going into = your holding queue. I use this anytime someone sends non-spam mail.

Chris.

On Dec 16, 2014, at 12:30 PM, Jeff Tantsura = <jeff.tantsura@ericsson.com> wrote:

Randy/others who are non-members = - please do subscribe, otherwise any time
you post it goes to list = administrators and we have to explicitly
allow/disallow your = postings.
Subscription page - https://www.ietf.org/mailman/listinfo/rtg-yang-coord

Thanks!

Cheers,
Jeff
= --Apple-Mail=_7F2159A6-91CE-405F-A7E2-6D619AD6F822-- --Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkHp6AAoJEC4dgw7XuDAlZXEP/jHr+10+LPI1VWA9kwenM/6J TgZ8qsJzbID1ebdn+cmN/9l5voLkEdryAyqJTsWpD9ML9QGLXjgibV9AwKJjax/n RgkcysnBlcfuN3uf99XUjiYwd2ZQje4TQlgaIaGot2x7aC8Ka42gexD7Wt/NRYzV kNVBAVbyTJMmvH2FZNlpWUrQd7Ssp3u5dxp3er8DA36BA3r0mLskQeou2krY7iq1 ghUomVf2BBia/Lvb5zQVZkthdP1hbUkKvYwEOdR+9X+uuKFKDBOIpukQWcCG97L1 WoF/53wzJUGkMbiPIjecjzcVublwAgvO4r1XGuDjB3gGYyGMBYCHvqEsJs7tOmi/ g+D/Un9t8f6gnKxvy9ktT6wVmi0iW3zq2Z4hd5SvVNgJCtStFfjWBDoSHadJFNbu NFhLqQr9GVjtyKSvar6c0d5XxxaEnOGVAihwZ+cnmcmGT9Z4TCmFYP2usaSyb/zZ eBUxzTf7lxx4FK4Bmku/hvhiP4T+bG9rvsEbFOuMYM/B4tDAi635XpnPPh0rdVIT RDE8Sj1KP3m+U6V3d8y/V/oEUGnOaovzb6Cnxf/xYQC0JnU9nZD5Vz7vVfuGz/r7 /sOGuDEn+chvFo6+8KHlMBUtefJD61x2YSN+auhzZFjvb3ffoyFpZSXhOpOCh8og 1afNwQOTyYW5scPTeAur =fMXn -----END PGP SIGNATURE----- --Apple-Mail=_3EA418E7-1BEE-4131-9853-18FEDAB2AB37-- From nobody Tue Dec 16 12:35:41 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5852B1A8793; Tue, 16 Dec 2014 12:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.054 X-Spam-Level: X-Spam-Status: No, score=-98.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_SUMOF=1, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK2wDET8mTZ7; Tue, 16 Dec 2014 12:35:33 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 27B011A8786; Tue, 16 Dec 2014 12:35:33 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "NETCONF" , Date: Tue, 16 Dec 2014 15:35:28 -0500 Message-ID: <024901d0196f$d4901120$7db03360$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_024A_01D01945.EBBB41A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAZboapbH/TgJXUSQGTcosv2HJVOQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/dl71upJQrFgmpFCTU3mleI1xeQ8 Cc: rtg-yang-coord@ietf.org, i2rs-chairs@tools.ietf.org Subject: [Rtg-yang-coord] minutes and slides for the I2RS interim X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 20:35:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_024A_01D01945.EBBB41A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_024B_01D01945.EBBB41A0" ------=_NextPart_001_024B_01D01945.EBBB41A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS has held two interims during December to discuss use cases, yang models for RIB and topology, and the I2RS requirements on protocol. These minutes of these meetings are attached. You can find slides and minutes for the December 11th, 2014 meeting at: http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedings.html You can find slides and minutes for the December 11th, 2014 meeting at: http://www.ietf.org/proceedings/interim/2014/12/16/i2rs/proceedings.html Please let us know if you have any questions we can answer regarding the I2RS current status. Sue Hares ------=_NextPart_001_024B_01D01945.EBBB41A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = has held two interims during December to discuss use cases, yang models = for RIB and topology, and the I2RS requirements on protocol.  These = minutes of these meetings are attached.

 

You can find = slides and minutes for the December 11th, 2014 meeting at: =

http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedi= ngs.html

 

You can find slides and minutes for the December = 11th, 2014 meeting at:

http://www.ietf.org/proceedings/interim/2014/12/16/i2rs/proceedi= ngs.html

 

Please let us know if you have any questions we can = answer regarding the I2RS current status.

 

Sue Hares =  

------=_NextPart_001_024B_01D01945.EBBB41A0-- ------=_NextPart_000_024A_01D01945.EBBB41A0 Content-Type: text/plain; name="i2rs-interim-minutes-2014-12-16.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="i2rs-interim-minutes-2014-12-16.txt" I2RS interim, December 16, 2014. 10:00-11:40 ET Attendees: Hariharan Ananthakrishnan Alia Atlas Ignas Bagdonas Nitin Bahadur Lou Berger Andy Bierman Deborah Brungard Alexander Clemm Amit Dass Dhruv Dhody Jie Dong=20 Jan Medved Jie Dong Don Fedyk Cary FitzGarald Jeff Haas=20 Joel Halpern Susan Hares=20 Ace Linden Xufeng Liu Jan Medved=20 Dan Romascanu Ju=C3=ABrgen Sch=C3=B6nw=C3=A4lder Himanshu Shah Robert Varga Lixing Wang =20 Michael Wang Kent Watsen Qin (Bill) Wu=20 Agenda Discussion on I2RS RIB Info Drafts [10:00 - 10:30 (zctual)] discussing: = 1) Interaction between RIB Yang Model and draft-ietf-netmod-routing-cfg 2) Nexthop structures proposed in RIB Info Model = [draft-ietf-i2rs-rib-info-model-04]=20 Discussion of I2RS topology drafts [10:30 - 11:15] =20 Overview and PBR {Sue Hares] [10:30 - 10:35] Yang Model for Network Topologies: [Alexander Clemm] [10:35-10:45]=20 draft-clemm-i2rs-yang-network-topo-01.txt draft-clemm-i2rs-yang-l3-topo =20 Yang Model for L2 Topologies [Jie Dong] [10:45 - 10:50] =20 draft-dong-i2rs-yang-l2-network-topology=20 =20 Yang Model for Service Topologies [Qin Wu/Sue Hares] [10:50 - 11:00]=20 = http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/= Discussion on topology drafts [10:35 - 10:45]=20 =09 Protocol Discussion: [11:05 - 11:30] =20 1) Simple protocol option - [Dean Bogdanovic]=20 2) Complex Protocol option - [Sue Hares]=20 3) pub-sub option [Alexander Clemm, Eric Voit]=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I2RS Adoption calls in December-January=20 I2RS will make an adoption call for RIB Yang/IM model after 12/16/2014 = meeting. =20 Topics for 1/8/2015 and 1/23/2015 I2RS interim: =20 1) Protocol Requirements for I2RS=20 2) Topology drafts =20 3) RIB Info drafts.=20 =20 1) Document status:=20 Traceability draft has been adopted. We dovetail our Yang modules with netconf and netmod.=20 =3D=3D=3D=3D 2) Rib Info Yang model - Amit [slides] High level differences.=20 What are unique for i2rs? I2RS is not covering the default rib model, compared to the netmod-cfg = they do. Using capabilities for tunnel encap types. Propose add RPC from agent to client for route changes Q: Juergen - why do we need rpc vs. notification?=20 Lixing: Example from BGP use case. =E2=80=A6 Sue: This is for pub-sub, for retrieving history. From BGP use cases. Jan: Do we need both info and data model now? Sue: Alia says one draft. Alia: That=E2=80=99s up to WG. IM could proceed separately from DM = since we=E2=80=99re not yet rechartered for DM. Jeff: Notification in I2RS. Does it also belong in netmod-cfg? Amit: They should align. Sooner or later, we should come back and = revisit it. Alia: Amit and Lixing, very useful comparison vs. netmod rtg-cfg model. = Thanks for doing it. =20 There=E2=80=99s a recent draft by Eric et al. and motivations for = pub-sub.=20 Does it describe the rib model requirements? Useful for i2rs to discuss = and netconf to review. Sue: See end presentation. Nitin: Lots of questions raised. Is there a design team to resolve this? Sue: Yes. We are taking volunteers for that team. Nitin: Feel free to add me to it. =3D=3D=3D=3D=3D 3) Protocol Independent (Topology) Data Models - Sue [slides] 3.1 Contrast topology dependent vs. independent. PBR - Sits underneath the rib list, above the BNP. Default RIB? PBR needs a default RIB for failover. We are only proposing groups, rules. ------ 3.2 Network topology Models - Alex Clemm [slides] Represents both horizontal and vertical layering Lou B: Will you be in Thursday=E2=80=99s TEAS interim? Alex: Yes. Lou: Will defer. Grappling with issue of control plane topo vs. data = plane topology. L3 IGPs they=E2=80=99re the same. SDN, TE - = they=E2=80=99re not necessarily the same. Sue: PBR is a forwarding data plane focus. Qin will cover service = topology and Jie will cover Layer 2. Many people will join you on = Thursday. ------- 3.3 Yang data model for L2 topology - Jie Dong [slides] Jeff: Your model includes layer 2 physical info (vlan etc.) Does this = belong in our I2RS stuff? Alex=E2=80=99s draft lets you look between = layers. Do we want this level of detail in our model? Jie: Topo use case draft suggests we want to gather the sum of the info = from across the network. What about layer 3/2/1? Agree it needs = discussion. Alex: Reasonable to do this. Fine line between abstraction model vs. = other info, but not specific to topology. Discuss on case by case = basis. If not tied to topology properties, should go to inventory. Jie: Agreed. Sue: As Lou put it we have forwarding layer at l2 and control plane at = l2. Alex, when you speak at abstract, which do you mean? Alex: Both. Even with service. Jeff: If we allow write, then the l2 config details matter. Sue: Need active discussions on mail list. Tie into use case. 3.4 Service Topology Info Model - Qin Wu and Sue Hares=20 [slides] Joel: *Who* knows the info needed to populate this model? Service = topology needs to be more than just tunnels. Sue: Abstract topology to lay on top of network topology. We=E2=80=99re = describing this using UML. Joel: Starting to cover my questions. Let=E2=80=99s keep going. Lou: I think you made an important clarification. You mean TEAS requests = to I2RS. Juergen: Concerned with restconf extensions and netconf extensions being = called out in UML. They should work in both. Sue: Thanks for correction, will fix in next rev. [slides] Sue: Note how this ties back to Alex=E2=80=99s model. Additional = questions? Lou: Document has TE data. This doesn=E2=80=99t get covered in these = slides. Is that still there? Sue: We had removed it. Expect to harmonize with Alex. Lou: Usage of TE is not the normal use of it. Perhaps better term, like = NAT load balancer, etc.=20 TED is different than normal usage of TED. =20 Sue: I think you=E2=80=99re correct. We=E2=80=99ll update it, happy to = take further feedback. Don Fedyk: There is a lot more commonality in models in layer 3 models = and others.=20 They could be harmonize a bit more. Jeff: What is the additional harmonization=20 My point was the Yang Model for L3 (as presented) seemed to outline L3, = Service and Optical and missed L2 totally. (Not saying this is one document but one = architecture as presented). Then the L2 Presentation had some L2 but missed several L2 capabilities. = (VPLS, EVPN, VXLAN, PBB etc.)=20 If you look at this more generically each layer (l3,l2,l1) has:=20 Data path, Tunneling/Multiplexor/Virtual network, Topology, Topology = data base, TE extensions,=20 Control Plane. Each layer can and may use IS-IS or OSPF (and even BGP) = for some address distribution VPN information, connection coordination, TE information, = within the context of an Instance/VPN. Each layer can and may offer a service, p2p, p2mp, = mp2mp,(some type of persistent connection or set of connections that may have their own = resiliency mechanisms) at the layer or up to a higher layer.=20 Layers can be skipped and upper layers may be unaware of lower layers.=20 Lou Berger (from email response): My comment on control plane vs data = plane is very much in line with this comment. And Don has begun some of the discussion I was = hoping to talk a bit more about in Thursday's TEAS interim. (At least the TE aspects, as well = as the possible formal representation of control plane separately from data plane.) =E2=80=94=E2=80=94 Subscribing to datastore push updates - Alex Clemm [slides] XXX - transport and subscription decoupling =E2=80=94 Simple vs. Complex I2RS - Dean Bogdanovich and Sue (via mailing list) [slides] Joel: This was discussed in WG. Defining granularity at which we = conflict=20 should be in model. Not sure what we=E2=80=99re discussing here. Sue: Trying to come to some conclusion about ephemeral database from = ietf-91. Dean Bogdanovic thought there might be a different way to look at it. Joel: I don=E2=80=99t think these things are really primitives. = We=E2=80=99re only interacting with some properties of the interface. Same for route - only changing = some property. Jeff: Example of route, ownership is internal. Joel: Correct myself from route vs. route-table. Route-table handles = that arbitration. Jeff: Russ White basically says just interact with routing table, it is = much simpler. Joel: Have discussed with Russ - who does not believe we have covered = the scope properly. Sue: Agree that things are complex, like next hops, recursive nexthops. = Let us have more of this discussion on the mail list. =20 RFC 6095 may help here, per netconf folk. Don: Distinction is based on ability override something in config vs. = the ownership of that=20 thing. Objects that are simple can be easily made to override some = properties. Ownership is still in config. Only need this relationship if config is involved. Jeff: Had presented this override picture at last ietf. Covered by = option 4 =E2=80=9Cpanes of glass model=E2=80=9D. Sue: need to continue this on mailing list. Put more questions out on = list. Need to pick=20 this up for Jan 8 meeting. We had hoped this discussin would clarify = things, but=20 we need to go a few more rounds. ------=_NextPart_000_024A_01D01945.EBBB41A0 Content-Type: text/plain; name="i2rs-interim-minutes-2014-12-11-final-v2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="i2rs-interim-minutes-2014-12-11-final-v2.txt" I2RS interim meeting December 11, 2014. Chairs Sue Hares, Jeffrey Haas. 10:00-11:00 ET Attendees: Jeff, Sue, Alia Amit Dass Dhruv Dhoty Hariharan Anathakakrishnan Igneous Bagdonas Lixing Wang Juergen Schoenwaelder Alexander Clemm Cary FitzGerald Dean Bogdanovich Don Fedyk Yael Frank Zafar Ali Status =3D=3D=3D=3D=3D=3D=3D RIB model looking for design team members. Currently, Amit and Lixing. Use case summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dean: The main issue with the protocol selection was does I2rs want to = talk directly to daemons or via configuration? Do we want to focus on managing = primitives such as routes, interfaces, etc. or do we want to manage more complex objects such as = VPNs (l3vpn, l2vpn, etc.) =20 If we can figure out what we want to do, it will make selecting protocol = behaviors a bit easier. Maybe even outside of the IETF since there already exist some solutions. = =20 What do we want to enable through the agent? E.g. Apache Thrift is an = interesting protocol=20 if we are dealing with primitives. Sue: Use cases have both. E.g. virtual topology. Can these be done = with just primitives? =20 One option is we can take a protocol selection that works for just the = primitives, but we know that BGP is something that people want to do and BGP cannot be solved = with just primitives. [slide Virtual topology cases] 25 reqs. that are in-charter. =20 [slide Discussion questions] Is it okay to just use primitives or do we need complex objects? Dean: If we do not want to support bgp vpns, only need primitives. =20 Ignas: One of the important thing is transactions. If we have both, = there is a lot of flexibility. =20 If transactions are not in protocol level but are in client agent = interaction or some other entity,=20 then we have to worry about deterministic issues. Jeff: Speed may require two distinct mechanisms. Ignas: Speed? Possible. Depends on use case. Maybe makes sense. Alia: In architecture, we do not have the idea of transactions. You may = have multiple operations in single exchange with agent. Trying to add transaction = complexity will rat-hole us. The concept of going to two mechanisms if the more complex use cases = sounds much better than trying to push more complexity into the simpler use cases. =20 Jeff: Getting state out of the system is also important. Dean: This might push us into duplicating cases already elsewhere? If = you can already do complex stuff via configuration - e.g. l3vpn - many components, each particular daemon = has work to do.=20 If we can do it using primitives as well, but exposing those interfaces = adds complexity. =20 Know from two vendors that we have different approaches; this would lead = to vendor specific issues. =20 Sue: Your suggestion is we go through config process for everything or = complex? Dean: Primitives should go through daemons - [it is] faster. But then = you limit flexibility. Complex always should go through config; already a solved problem. What = is open? Do we want to have two different ways to do this? Jeff: Simple, complex, issues may have protocol impacts. See discussion = about netconf vs. restconf. Sue: Dean, you know about this in thrift? Dean: Yes, have done some implementation. Sue: We should split this into simple or complex. Next week, let = discuss having the protocol split-up between complex and simple.=20 Dean: I=E2=80=99ve already done that split up, can send to list. Sue: Want to focus on protocol independent items and topology. = Alexander, could you do the analysis on your topology items? Alexander: Ok I can present that. Jeff: IETF session broke things down into interactions with config state = vs. i2rs injected state. This discussion clarified we need to further break this down to simple = vs. complex. Rib Info Models=E2=80=A6 [slides] Nitin and Sriganesh are in Asia and don=E2=80=99t think they can = present. They=E2=80=99ll talk info model next week. RIB yang model [technical issues with Amit and Lixing presenting=E2=80=A6] Jeff: How to do the multiple encaps. Is this a good idea? Amit: Good idea, best idea to date? =20 Jeff: Overlap with rtg-cfg? Amit: Not yet.=20 Hari: I did some of this. Collaborating with Lada. Will work with = Amit. There is some confusion about who is the derived model of whom.=20 Dean: Many discussions about rtg-cfg model. When we started modeling = other protocols such as ospf, we realized we could not do that work yet due to inconsistencies in = rtg-cfg. IMO, should be used as base for all rtg-cfg models. Jeff: Motivation for asking is overlap with regard to complex config vs. = primitives. Hari: Should be complementing? Sue: For next week, figure out how this relates to rtg-cfg. Amit will come back with that information to the next interim.=20 Sue: let=E2=80=99s talk about this on list. Can you drive it Dean, Amit, = Lixing? Alex, for your model? Jeff: Juergen general recursion for 1.1, 2.0? Juergen: 1.1, no. 2.0 no clue. Jeff: Raise on netmod mailing list? Juergen: yes.=20 Jeff: Will raise on netmod. EOF. ------=_NextPart_000_024A_01D01945.EBBB41A0-- From nobody Tue Dec 16 22:03:44 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31F51A1DBD for ; Tue, 16 Dec 2014 22:03:41 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcoMDUO0vLCu for ; Tue, 16 Dec 2014 22:03:39 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA121A1DE2 for ; Tue, 16 Dec 2014 22:03:39 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-82-5490bfcdbac8 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2B.31.25146.DCFB0945; Wed, 17 Dec 2014 00:27:09 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 01:03:31 -0500 From: Jeff Tantsura To: "stephane.litkowski@orange.com" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFq3DAI1iR4rkSO5UpxSSPkb5ySleSAgADXF98= Date: Wed, 17 Dec 2014 06:03:31 +0000 Message-ID: References: , <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXRPlO7Z/RNCDPoeS1tcWDWXzeL389vM Fl/3PmR1YPZYsuQnk8emy3cYPVqenWQLYI7isklJzcksSy3St0vgyljZf4y94KBkxa+NV1kb GJ+IdDFyckgImEj0PH/GDGGLSVy4t56ti5GLQ0jgCKPEvt677BDOckaJDYsPsYJUsQkYSPz/ dpwFxBYRcJZoO3YOqIiDg1kgSmLlXj6QsLCAuUTHj93MECUWEj/+nWGDsK0kOtbsYwIpZxFQ ldjVYA0S5hWwl1i+/j4rxKoFjBI7z98H28sp0Mko8eH8dbBmRqDrvp9awwRiMwuIS9x6Mp8J 4moBiSV7zkN9ICrx8vE/VogaHYkFuz+xQdjaEssWvmaG2CYocXLmE5YJjKKzkIyahaRlFpKW WUhaFjCyrGLkKC1OLctNNzLcxAiMkWMSbI47GBd8sjzEKMDBqMTDa9A4IUSINbGsuDL3EKM0 B4uSOK9m9bxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyp728W9/zwYEhbKGkcfdhm9wt1 HgbXtnXs2ztLmi4f+/T8iuoB8ZMTpe753Cm4yGv1uDWg/PXHdo1Vhx8ucFocwGsz3fDkRg+J 771z6h0vT7P/zZwuHL/TTOb/l08Mf1v+3GCtdi2x1PYJSPEXqutQPTdL9cvHG88O1SY4KAkd nx7H+mtrDocSS3FGoqEWc1FxIgC7v8GecgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/GeHM-iuYUjmmgQZhJyufVuk1_oM Cc: "rtg-yang-coord@ietf.org" , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 06:03:42 -0000 I agree with Stephane. Regards, Jeff > On Dec 16, 2014, at 4:13 AM, "stephane.litkowski@orange.com" wrote: >=20 > Hi Lada, >=20 > I would be in favor of removing route-filters from the core routing model= and let another "Route Policy" Yang model augments it in future. > Route policy definition in YANG will be a hard work and it would be bette= r to restart from scratch rather than adding some design constraints from t= he beginning. >=20 > Regards, >=20 > Stephane >=20 > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf O= f Ladislav Lhotka > Sent: Tuesday, November 25, 2014 14:12 > To: rtg-yang-coord@ietf.org > Subject: [Rtg-yang-coord] issue :R01: route filters >=20 > Hi, >=20 > this issue refers the YANG module "ietf-routing" contained in >=20 > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 >=20 > Please indicate your preference or add comments. >=20 > ***** :R01: route filters > In -16, route filters are defined as stubs with the assumption > that real route filtering frameworks will be developed > later. This could work provided that such frameworks can accept > the control points for applying route filters as they are > defined in -16, i.e. (i) between routing protocol instances and > connected RIBs, and (ii) between RIBs. >=20 > ****** Solution R01-1 > No change. >=20 > ****** Solution R01-2 > Keep the stub route filters but change the control points. >=20 > ****** Solution R01-3 > Remove route filters from the ietf-routing module. Future route > filtering frameworks will define the control points and augment > ietf-routing accordingly. >=20 >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Dec 17 05:55:49 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5C11A1AFE; Wed, 17 Dec 2014 05:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.295 X-Spam-Level: ** X-Spam-Status: No, score=2.295 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnMcmzOZ9gKS; Wed, 17 Dec 2014 05:55:45 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id C61071A1A86; Wed, 17 Dec 2014 05:55:45 -0800 (PST) Received: from [192.168.1.120] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 529772A1FBA1; Wed, 17 Dec 2014 08:55:45 -0500 (EST) From: "Thomas D. Nadeau" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 17 Dec 2014 08:55:44 -0500 To: YANG Doctors , "" , rtg-yang-coord@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/-hmEYRCci0hDqXoSqKY7EaJfjyA Subject: [Rtg-yang-coord] Yangathon @ IETF in Dallas X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 13:55:46 -0000 Hi! I will be hosting a Yangathon hacking session at the IETF in = Dallas. You can get more information about the meeting here: = http://www.ietf.org/meeting/ The past meetings have been very well attended, so we need as = many volunteers who are Yang experts to help others with advice on model = creation/modification and general information around Yang. Please = contact me offline (with the same subject line) if you can commit to = being there in person.=20 We are also considering a tutorial on one or more of the tools. = If you have ideas, please let me know as that is a welcome addition to = the meeting as well. Thanks! --Tom From nobody Wed Dec 17 13:09:38 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2841A90B4 for ; Wed, 17 Dec 2014 13:09: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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb2Be5rFn03C for ; Wed, 17 Dec 2014 13:09:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B5C1A9075 for ; Wed, 17 Dec 2014 13:09:33 -0800 (PST) Received: from BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) by BN1PR05MB311.namprd05.prod.outlook.com (10.141.63.147) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 17 Dec 2014 21:09:11 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.1.36.23; Wed, 17 Dec 2014 21:09:09 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.217]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.217]) with mapi id 15.01.0031.000; Wed, 17 Dec 2014 21:09:09 +0000 From: Dean Bogdanovic To: Jeff Tantsura Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFqvvyajyxwZEG8ZV6J8cb4/5ySQhKAgAEq6ICAAP0CAA== Date: Wed, 17 Dec 2014 21:09:08 +0000 Message-ID: References: , <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 042857DBB5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(189002)(13464003)(199003)(377454003)(24454002)(66066001)(46102003)(20776003)(64706001)(31966008)(83716003)(99396003)(76176999)(50986999)(120916001)(87936001)(2656002)(89996001)(122556002)(40100003)(57306001)(86362001)(36756003)(92566001)(575784001)(4396001)(50226001)(102836002)(15975445007)(106356001)(2900100001)(107046002)(99286002)(106116001)(68736005)(1720100001)(2950100001)(97736003)(19580395003)(82746002)(230783001)(19580405001)(77156002)(33656002)(62966003)(105586002)(21056001)(110136001)(101416001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <705DEB28C7DFA743990451CD9A486269@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2014 21:09:08.1098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB421 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB311; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Zb7Nz2HG_xx5R9HJCgSOSeyWH-k Cc: "rtg-yang-coord@ietf.org" , "stephane.litkowski@orange.com" , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:09:37 -0000 I'm in support of removing route filters from the routing cfg model. Route = filters should be IMO part of the policy model, in which also ACL model bel= ongs too. Actually, I would argue that the current ACL model is very suitab= le for route filters. Dean On Dec 17, 2014, at 1:03 AM, Jeff Tantsura wro= te: > I agree with Stephane. >=20 >=20 > Regards, > Jeff >=20 >> On Dec 16, 2014, at 4:13 AM, "stephane.litkowski@orange.com" wrote: >>=20 >> Hi Lada, >>=20 >> I would be in favor of removing route-filters from the core routing mode= l and let another "Route Policy" Yang model augments it in future. >> Route policy definition in YANG will be a hard work and it would be bett= er to restart from scratch rather than adding some design constraints from = the beginning. >>=20 >> Regards, >>=20 >> Stephane >>=20 >> -----Original Message----- >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Ladislav Lhotka >> Sent: Tuesday, November 25, 2014 14:12 >> To: rtg-yang-coord@ietf.org >> Subject: [Rtg-yang-coord] issue :R01: route filters >>=20 >> Hi, >>=20 >> this issue refers the YANG module "ietf-routing" contained in >>=20 >> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 >>=20 >> Please indicate your preference or add comments. >>=20 >> ***** :R01: route filters >> In -16, route filters are defined as stubs with the assumption >> that real route filtering frameworks will be developed >> later. This could work provided that such frameworks can accept >> the control points for applying route filters as they are >> defined in -16, i.e. (i) between routing protocol instances and >> connected RIBs, and (ii) between RIBs. >>=20 >> ****** Solution R01-1 >> No change. >>=20 >> ****** Solution R01-2 >> Keep the stub route filters but change the control points. >>=20 >> ****** Solution R01-3 >> Remove route filters from the ietf-routing module. Future route >> filtering frameworks will define the control points and augment >> ietf-routing accordingly. >>=20 >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Dec 17 13:49:53 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEFE1A86EC for ; Wed, 17 Dec 2014 13:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiR8UFEzGq3N for ; Wed, 17 Dec 2014 13:49:49 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25301A7021 for ; Wed, 17 Dec 2014 13:49:48 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so16000282iec.39 for ; Wed, 17 Dec 2014 13:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h16bhCSyUptbpfVj4GJsBLLh+6Ri/GZlM/5h4LM+yWk=; b=Sw503KRsJexmxTm6F+mVGY2s2uZzkKqGJ1QVshnUbGxbnCmlyr0RKTCNVhtbK2face Y4iPJX0Sj0YN/Tm1UTrVp9/TwhDK5GhcSZsBMVkUcvD3aAsA5dcZN+vDnac77GwvDoKK GRP3RrITjx5yTa9Datytc5azykNBCwC5kGw0jiFsY5iPo90j5wcgA+pKLt3v4P/vOwZc kFD6kYfFS5CKzvvFGLrCjxNzfN8JBCGF6Jz7GnbAkNQuUJjgz8LPmPEiLfMs6MYY6Phs bYoHsGAb+saqkE55/G+AC2XBKnFagoO6m4EHK5W24IcH3hVzgePtkNla5FB0yBDe8u1P PaLg== MIME-Version: 1.0 X-Received: by 10.107.133.17 with SMTP id h17mr41746276iod.47.1418852987870; Wed, 17 Dec 2014 13:49:47 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.152.130 with HTTP; Wed, 17 Dec 2014 13:49:47 -0800 (PST) In-Reply-To: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Wed, 17 Dec 2014 22:49:47 +0100 X-Google-Sender-Auth: m4jKYwet5APmlzPzVYzlMq5fORc Message-ID: From: Robert Raszuk To: Dean Bogdanovic Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/nBm4XjxAcxkyFaiGSiLcxAm1xcU Cc: "rtg-yang-coord@ietf.org" , "stephane.litkowski@orange.com" , Ladislav Lhotka , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:49:50 -0000 Dean, all The way I read it currently in section 5.5 there are only two route filters proposed (deny-all or allow-all). As we know some routing protocols require explicit permission to operate (example: EBGP). If we remove even those two primitive filters there can be impact to other components. But I do support a separate work for YANG model for policy. I do expect this to be a very interesting and involved work considering significant diversity of policy languages across all implementations today. Once that work is done we could retire section 5.5 of *-netmod-routing-* Regards, r. On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wrote: > I'm in support of removing route filters from the routing cfg model. Route filters should be IMO part of the policy model, in which also ACL model belongs too. Actually, I would argue that the current ACL model is very suitable for route filters. > > Dean From nobody Wed Dec 17 14:07:42 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4EB1A874B for ; Wed, 17 Dec 2014 14:07:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhkdDvO61xR3 for ; Wed, 17 Dec 2014 14:07:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0831A877D for ; Wed, 17 Dec 2014 14:07:34 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 17 Dec 2014 22:07:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.217]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.217]) with mapi id 15.01.0031.000; Wed, 17 Dec 2014 22:07:32 +0000 From: Dean Bogdanovic To: Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFqvvyajyxwZEG8ZV6J8cb4/5ySQhKAgAEq6ICAAP0CAIAAC2GAgAAE9IA= Date: Wed, 17 Dec 2014 22:07:31 +0000 Message-ID: <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 042857DBB5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(189002)(377454003)(51704005)(24454002)(199003)(86362001)(19580405001)(77156002)(50226001)(33656002)(97736003)(106116001)(99286002)(87936001)(106356001)(105586002)(62966003)(93886004)(20776003)(99396003)(102836002)(92566001)(2900100001)(107046002)(2950100001)(2656002)(19580395003)(64706001)(83716003)(50986999)(82746002)(46102003)(76176999)(101416001)(230783001)(31966008)(4396001)(40100003)(122556002)(120916001)(561944003)(21056001)(68736005)(36756003)(89996001)(66066001)(110136001)(57306001)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <75C3ECAEFABB4A41BAFEA8795B0039B4@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/mmZCylsaJ9Ik0bOHCVHhPBQfZ1Q Cc: "rtg-yang-coord@ietf.org" , "stephane.litkowski@orange.com" , Ladislav Lhotka , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:07:41 -0000 Robert, Your proposal is very sensible and I think this is the best option Dean On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: > Dean, all >=20 > The way I read it currently in section 5.5 there are only two route > filters proposed (deny-all or allow-all). As we know some routing > protocols require explicit permission to operate (example: EBGP). If > we remove even those two primitive filters there can be impact to > other components. >=20 > But I do support a separate work for YANG model for policy. I do > expect this to be a very interesting and involved work considering > significant diversity of policy languages across all implementations > today. >=20 > Once that work is done we could retire section 5.5 of *-netmod-routing-* >=20 > Regards, > r. >=20 >=20 > On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wro= te: >> I'm in support of removing route filters from the routing cfg model. Rou= te filters should be IMO part of the policy model, in which also ACL model = belongs too. Actually, I would argue that the current ACL model is very sui= table for route filters. >>=20 >> Dean From nobody Wed Dec 17 14:08:49 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBCB1A87C5 for ; Wed, 17 Dec 2014 14:08:39 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DyBRtLVF-eI for ; Wed, 17 Dec 2014 14:08:32 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E74F1A87BE for ; Wed, 17 Dec 2014 14:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4735; q=dns/txt; s=iport; t=1418854112; x=1420063712; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=81VxpJad4XlpJHElNhNFjcRA8KI1zvYeZ9t4Pi+rASQ=; b=HSDafgufIvnjYyxHpMebcuZczeE0Enn2x4zhI1iLllBcezZIVQNwprFr HF0OtEpPXDgJNJNQ1AIwCzM4gFEoAJs5P7RDbPZVOLQk4Q2IRfNp+aI0H Nx2r138XZfD7dgRTzBZe9a1XRDVvFH1BGNIDGWG3TvDnMUPirM+uPmA+w 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkFAFf+kVStJV2c/2dsb2JhbABagwZSWATFcwqFcgKBIxYBAQEBAX2EDAEBAQMBAQEBawsFBwQCAQgRBAEBAScHJwsUCQgCBA4FG4gJCA3VCgEBAQEBAQEBAQEBAQEBAQEBAQEBARePEBEBHTMHBoMQgRMFjgiDPoUygQswgjGKHIM4IoNsb4EMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,596,1413244800"; d="scan'208";a="110824393" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by mtv-iport-1.cisco.com with ESMTP; 17 Dec 2014 22:08:31 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBHM8TsE030425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 22:08:30 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 16:08:29 -0600 From: "Acee Lindem (acee)" To: Dean Bogdanovic Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAGP+YCAAP0GAIAAEIEA Date: Wed, 17 Dec 2014 22:08:29 +0000 Message-ID: References: , <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <327B085BB647CE4AB635999E174323EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/7ooMVrTHdxPN05_9KYps_pDJJBk Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , Ladislav Lhotka , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:08:39 -0000 On Dec 17, 2014, at 4:09 PM, Dean Bogdanovic wrote: > I'm in support of removing route filters from the routing cfg model. Since I originally raised the issue, I=92m definitely in favor of this.=20 > Route filters should be IMO part of the policy model, in which also ACL m= odel belongs too. Actually, I would argue that the current ACL model is ver= y suitable for route filters. While the list and permit/deny semantics are similar, I don=92t think it is= a good idea to mix packet filtering and route filtering. We=92ll have much= cleaner models if we maintain this separation. IMO, this negates the advan= tage of reusing the list and permit/deny semantics. Consequently my vote wo= uld be for a separate route-prefix-list rather than mixing these things jus= t to pick up the list semantics.=20 Thanks, Acee >=20 > Dean >=20 > On Dec 17, 2014, at 1:03 AM, Jeff Tantsura w= rote: >=20 >> I agree with Stephane. >>=20 >>=20 >> Regards, >> Jeff >>=20 >>> On Dec 16, 2014, at 4:13 AM, "stephane.litkowski@orange.com" wrote: >>>=20 >>> Hi Lada, >>>=20 >>> I would be in favor of removing route-filters from the core routing mod= el and let another "Route Policy" Yang model augments it in future. >>> Route policy definition in YANG will be a hard work and it would be bet= ter to restart from scratch rather than adding some design constraints from= the beginning. >>>=20 >>> Regards, >>>=20 >>> Stephane >>>=20 >>> -----Original Message----- >>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf= Of Ladislav Lhotka >>> Sent: Tuesday, November 25, 2014 14:12 >>> To: rtg-yang-coord@ietf.org >>> Subject: [Rtg-yang-coord] issue :R01: route filters >>>=20 >>> Hi, >>>=20 >>> this issue refers the YANG module "ietf-routing" contained in >>>=20 >>> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 >>>=20 >>> Please indicate your preference or add comments. >>>=20 >>> ***** :R01: route filters >>> In -16, route filters are defined as stubs with the assumption >>> that real route filtering frameworks will be developed >>> later. This could work provided that such frameworks can accept >>> the control points for applying route filters as they are >>> defined in -16, i.e. (i) between routing protocol instances and >>> connected RIBs, and (ii) between RIBs. >>>=20 >>> ****** Solution R01-1 >>> No change. >>>=20 >>> ****** Solution R01-2 >>> Keep the stub route filters but change the control points. >>>=20 >>> ****** Solution R01-3 >>> Remove route filters from the ietf-routing module. Future route >>> filtering frameworks will define the control points and augment >>> ietf-routing accordingly. >>>=20 >>>=20 >>> --=20 >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 >>> _______________________________________________________________________= __________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or privileged= information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Dec 17 14:12:19 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEE51A8785 for ; Wed, 17 Dec 2014 14:12:17 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAwGzjUKxP-3 for ; Wed, 17 Dec 2014 14:12:15 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC721A8781 for ; Wed, 17 Dec 2014 14:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1697; q=dns/txt; s=iport; t=1418854335; x=1420063935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yiC3f1pAV86Sar9O3J01nwBhO2563O9/PbIkNtqnbM0=; b=Puz3ux4EOQtUxrxCkuDhN7vxcJjzxbK17xOc3eWjCfeKm5woqOcubg9V xkHeDxoi+FtHVn++b6LphBzbTZ9UB3TzBCLI8mML8uCPog2i9AsDowsj/ 30uA2U4mbgHWCn1/Ed9EdTNOvhHkWKEr8Xzd4q0zhRsVZMWVtTwEYWBSR Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAM3+kVStJA2H/2dsb2JhbABagwZSWATFcwqFcgKBIxYBAQEBAX2EDAEBAQMBAQEBawsFCwIBCBguJwslAgQOBYgkCA3VEwEBAQEBAQEBAQEBAQEBAQEBAQEBFASPPzMHgxaBEwEEjgiIcIELhRKHa4M4IoNsb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,596,1413244800"; d="scan'208";a="380921854" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 17 Dec 2014 22:12:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBHMCEGw005909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 22:12:14 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 16:12:14 -0600 From: "Acee Lindem (acee)" To: Dean Bogdanovic Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAGP+YCAAP0GAIAAC1yAgAAE9ICAAAE8AA== Date: Wed, 17 Dec 2014 22:12:14 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> In-Reply-To: <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <74DF710A2313A04FBA0B6CE9A0D776D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/qqdKhBw1Qv2GmvymGkw7fuGnvoE Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , Jeff Tantsura , Ladislav Lhotka , Robert Raszuk Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:12:17 -0000 Why is this a problem if the default is to not to redistribute routes betwe= en RIBs? Note that it isn=92t like we have a set of approved routing protoc= ol models that are dependent on this behavior.=20 Acee=20 On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic wrote: > Robert, >=20 > Your proposal is very sensible and I think this is the best option >=20 > Dean >=20 > On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: >=20 >> Dean, all >>=20 >> The way I read it currently in section 5.5 there are only two route >> filters proposed (deny-all or allow-all). As we know some routing >> protocols require explicit permission to operate (example: EBGP). If >> we remove even those two primitive filters there can be impact to >> other components. >>=20 >> But I do support a separate work for YANG model for policy. I do >> expect this to be a very interesting and involved work considering >> significant diversity of policy languages across all implementations >> today. >>=20 >> Once that work is done we could retire section 5.5 of *-netmod-routing-* >>=20 >> Regards, >> r. >>=20 >>=20 >> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wr= ote: >>> I'm in support of removing route filters from the routing cfg model. Ro= ute filters should be IMO part of the policy model, in which also ACL model= belongs too. Actually, I would argue that the current ACL model is very su= itable for route filters. >>>=20 >>> Dean >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Dec 17 14:14:47 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0525B1A87E1 for ; Wed, 17 Dec 2014 14:14:47 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRZUdt10huuF for ; Wed, 17 Dec 2014 14:14:45 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283711A87DB for ; Wed, 17 Dec 2014 14:14:45 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-36-5491af90b156 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 66.CE.03307.09FA1945; Wed, 17 Dec 2014 17:30:08 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 17:14:42 -0500 From: Jeff Tantsura To: "Acee Lindem (acee)" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFq3DAI1iR4rkSO5UpxSSPkb5ySleSAgADXF9+AAVDYAIAAC1uAgAAE9YCAAAFRAP//rN+n Date: Wed, 17 Dec 2014 22:14:42 +0000 Message-ID: <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPoO6E9RNDDE5ckLaY/HYes8Xj9jnM FhdWzWWzaFrYxGzx+/ltZouvex+yOrB5TPm9kdVjyZKfTB7Xm66ye2y6fIfRo+XZSTaP3RsX MAWwRXHZpKTmZJalFunbJXBl7OnuYCrYxl9xdJZDA+N+ni5GTg4JAROJNbdWMkPYYhIX7q1n 62Lk4hASOMIoce7lNRYIZzmjxKdNcxlBqtgEDCT+fzsOlODgEBHQlNjyHqyGWeAGo8SNs5/B JgkLmEt0/NgNZosIWEj8+HeGDcKOkrh26x4TSC+LgKrEt4lmIGFeAXuJK+dXs0Ps2sUscbP/ Clgvp4CtxMfr/9lBbEag676fWsMEYjMLiEvcejKfCeJqAYkle85DfSAq8fLxP1aQ+cxAd/7b wAxRri2xbOFrZohdghInZz5hmcAoOgvJpFkIHbOQdMxC0rGAkWUVI0dpcWpZbrqRwSZGYGQd k2DT3cG456XlIUYBDkYlHt6CnRNChFgTy4orcw8xSnOwKInzzqqdFywkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBUS7hTLRIhITazcbPWZdUryd9qBP5s+OfhKAF47fQnV3vhCJlHGZ9fupe NUt3zyOv6Rfn/dQwem//xX2F5taTiaJHTcXnO6X1WEuIvXqTUj3VfrXeUtk7ws4Jc/9yv997 1u5IZ2aYysN9c6IWLQ6rLw4XifPkEIl3fd74b93S43qXp/londsxX4mlOCPRUIu5qDgRACry qLONAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/LGenERhO5O__eRQRsfrA-jYLFGw Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , Dean Bogdanovic , Robert Raszuk , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:14:47 -0000 Yes, exactly, Robert - the behavior you have described is an implementation= , not a formal specification.=20 Regards, Jeff > On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) wrote: >=20 > Why is this a problem if the default is to not to redistribute routes bet= ween RIBs? Note that it isn=92t like we have a set of approved routing prot= ocol models that are dependent on this behavior.=20 > Acee=20 >=20 >> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic wrote: >>=20 >> Robert, >>=20 >> Your proposal is very sensible and I think this is the best option >>=20 >> Dean >>=20 >>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: >>>=20 >>> Dean, all >>>=20 >>> The way I read it currently in section 5.5 there are only two route >>> filters proposed (deny-all or allow-all). As we know some routing >>> protocols require explicit permission to operate (example: EBGP). If >>> we remove even those two primitive filters there can be impact to >>> other components. >>>=20 >>> But I do support a separate work for YANG model for policy. I do >>> expect this to be a very interesting and involved work considering >>> significant diversity of policy languages across all implementations >>> today. >>>=20 >>> Once that work is done we could retire section 5.5 of *-netmod-routing-= * >>>=20 >>> Regards, >>> r. >>>=20 >>>=20 >>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic = wrote: >>>> I'm in support of removing route filters from the routing cfg model. R= oute filters should be IMO part of the policy model, in which also ACL mode= l belongs too. Actually, I would argue that the current ACL model is very s= uitable for route filters. >>>>=20 >>>> Dean >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 From nobody Wed Dec 17 14:28:22 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587A11A8736 for ; Wed, 17 Dec 2014 14:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1jMPoRTHtuF for ; Wed, 17 Dec 2014 14:28:19 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31B11A876F for ; Wed, 17 Dec 2014 14:28:18 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id r2so10283761igi.3 for ; Wed, 17 Dec 2014 14:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gwO+tl8yIGA3mb6KkLMUQv8G4ETKBmCKLOWuRLKDxk0=; b=LgCBakzhP6lSNxCIMneRg9kQyYr9qVwn1jYeJMjI78O0aQr/zlFN8rxzS2R2fRYI+Q DTT59qEsg8+MPBZnCgyVWv8YyWLYeLxF0Zf406VY10gRMUju7xWpdvwxCHU7nUtVLpY9 ztH37NhCWbtBl7rSPE1OnzS9OjASH1f+nkQNjS9pkbZ72lO0CjNIVkzo0Ajk8B1JZkfS Aroi03AwISDofKJAXPH6wQ/FXcr5VdGOdULWNxtBGaM8h0bBVwTlxST4wo2wlUVqbt8B DJFtgx4aCF1/ftBE0E39ZUvzYpe9durmM3n28l+E4Bb3t5F2ty/HqZ1hIL2X6POvQiXy GznQ== MIME-Version: 1.0 X-Received: by 10.42.146.201 with SMTP id k9mr39572862icv.54.1418855297710; Wed, 17 Dec 2014 14:28:17 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.152.130 with HTTP; Wed, 17 Dec 2014 14:28:17 -0800 (PST) In-Reply-To: <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> Date: Wed, 17 Dec 2014 23:28:17 +0100 X-Google-Sender-Auth: spXyAFxT7sYCorAP81W6WSX77kM Message-ID: From: Robert Raszuk To: Jeff Tantsura Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/JXU6KsGoVWGjTpFbe1K-rLW_npw Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , "Acee Lindem \(acee\)" , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:28:20 -0000 So are you saying that formal YANG specification say for BGP by design will not be compatible with some implementations ? Or are you saying that formal design say of BGP protocol will have to wait few years till YANG for policy spec is complete ? Cheers, r. On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura wrote: > Yes, exactly, Robert - the behavior you have described is an implementati= on, not a formal specification. > > Regards, > Jeff > >> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) wrote: >> >> Why is this a problem if the default is to not to redistribute routes be= tween RIBs? Note that it isn=E2=80=99t like we have a set of approved routi= ng protocol models that are dependent on this behavior. >> Acee >> >>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic wrote: >>> >>> Robert, >>> >>> Your proposal is very sensible and I think this is the best option >>> >>> Dean >>> >>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: >>>> >>>> Dean, all >>>> >>>> The way I read it currently in section 5.5 there are only two route >>>> filters proposed (deny-all or allow-all). As we know some routing >>>> protocols require explicit permission to operate (example: EBGP). If >>>> we remove even those two primitive filters there can be impact to >>>> other components. >>>> >>>> But I do support a separate work for YANG model for policy. I do >>>> expect this to be a very interesting and involved work considering >>>> significant diversity of policy languages across all implementations >>>> today. >>>> >>>> Once that work is done we could retire section 5.5 of *-netmod-routing= -* >>>> >>>> Regards, >>>> r. >>>> >>>> >>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic = wrote: >>>>> I'm in support of removing route filters from the routing cfg model. = Route filters should be IMO part of the policy model, in which also ACL mod= el belongs too. Actually, I would argue that the current ACL model is very = suitable for route filters. >>>>> >>>>> Dean >>> >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> From nobody Wed Dec 17 14:52:05 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0921A0127 for ; Wed, 17 Dec 2014 14:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYbXDCt87Wmi for ; Wed, 17 Dec 2014 14:52:00 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EDB1A0004 for ; Wed, 17 Dec 2014 14:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3369; q=dns/txt; s=iport; t=1418856719; x=1420066319; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cqI31lO3wNhu/3KB5ueY635/45FiUaQHFcKtqa0i/Cw=; b=cbPZ2sGAszwUE/pCGLRkN7o+PEYtT2bJb6pIYlI8DtY7Px9shyCSVSH9 3VZ3kcX38Sca27SkUEAzCAXcSgAZVXUJu8X/EmAqoOGNuq/dYWnwzgIxw tcuz3ACqcMChHVxVTj4vHTdPh0enxGONJKChzNIX5iK1P1NPpcqtlH8Az M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAO0HklStJA2N/2dsb2JhbABagwZSWATFdAqFcgKBGhYBAQEBAX2EDAEBAQMBAQEBawsFCwIBCBguJwslAgQOBYgkCA3VEQEBAQEBAQEBAQEBAQEBAQEBAQEBFASPPzMHgxaBEwWOCIhwgQuFEodrgzgig2xvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,596,1413244800"; d="scan'208";a="380985137" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 17 Dec 2014 22:51:59 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sBHMpw5t003701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 22:51:59 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 16:51:58 -0600 From: "Acee Lindem (acee)" To: Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAGP+YCAAP0GAIAAC1yAgAAE9ICAAAE8AIAAAMYAgAADzICAAAaJgA== Date: Wed, 17 Dec 2014 22:51:58 +0000 Message-ID: <8E05EC04-7764-4CA1-831F-6A098E7086E8@cisco.com> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1D3520371C050C499331848405343761@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/fc6yPk_0o5fFR-J7S9OUa-dWDKU Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:52:03 -0000 On Dec 17, 2014, at 5:28 PM, Robert Raszuk wrote: > So are you saying that formal YANG specification say for BGP by design > will not be compatible with some implementations ? >=20 > Or are you saying that formal design say of BGP protocol will have to > wait few years till YANG for policy spec is complete ? The design of the routing policy model and the BGP module should precede in= parallel. For BGP, at least in my opinion, there will be protocol specific= policy. In fact, if we follow the majority of the deployed implementations= , all the routing policy attach points could be in the routing protocol mod= els. =20 There are also implementations that support procedural policy. However, the= re is significant variance between implementations and these do not lend th= emselves nicely to YANG representation. Hence, the models representing thes= e directly will most likely ending up being vendor specific.=20 In short, this is not an easy problem but standardizing these permit/deny a= ll route filters at arbitrary attach points doesn=92t get us any closer to = YANG routing policy. =20 Thanks, Acee=20 >=20 > Cheers, > r. >=20 > On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura > wrote: >> Yes, exactly, Robert - the behavior you have described is an implementat= ion, not a formal specification. >>=20 >> Regards, >> Jeff >>=20 >>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) wrote: >>>=20 >>> Why is this a problem if the default is to not to redistribute routes b= etween RIBs? Note that it isn=92t like we have a set of approved routing pr= otocol models that are dependent on this behavior. >>> Acee >>>=20 >>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic wrote= : >>>>=20 >>>> Robert, >>>>=20 >>>> Your proposal is very sensible and I think this is the best option >>>>=20 >>>> Dean >>>>=20 >>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: >>>>>=20 >>>>> Dean, all >>>>>=20 >>>>> The way I read it currently in section 5.5 there are only two route >>>>> filters proposed (deny-all or allow-all). As we know some routing >>>>> protocols require explicit permission to operate (example: EBGP). If >>>>> we remove even those two primitive filters there can be impact to >>>>> other components. >>>>>=20 >>>>> But I do support a separate work for YANG model for policy. I do >>>>> expect this to be a very interesting and involved work considering >>>>> significant diversity of policy languages across all implementations >>>>> today. >>>>>=20 >>>>> Once that work is done we could retire section 5.5 of *-netmod-routin= g-* >>>>>=20 >>>>> Regards, >>>>> r. >>>>>=20 >>>>>=20 >>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wrote: >>>>>> I'm in support of removing route filters from the routing cfg model.= Route filters should be IMO part of the policy model, in which also ACL mo= del belongs too. Actually, I would argue that the current ACL model is very= suitable for route filters. >>>>>>=20 >>>>>> Dean >>>>=20 >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 From nobody Wed Dec 17 14:56:54 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3CE1A0021 for ; Wed, 17 Dec 2014 14:56:51 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBjwjGiAlO9b for ; Wed, 17 Dec 2014 14:56:49 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F561A000A for ; Wed, 17 Dec 2014 14:56:40 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-16-5491b95dceda Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 98.E0.03307.D59B1945; Wed, 17 Dec 2014 18:11:57 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 17:56:32 -0500 From: Jeff Tantsura To: Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFq3DAI1iR4rkSO5UpxSSPkb5ySleSAgADXF9+AAVDYAIAAC1uAgAAE9YCAAAFRAP//rN+ngABXnYD//4HMgA== Date: Wed, 17 Dec 2014 22:56:31 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyuXRPgm7szokhBp+aDCwmv53HbPG4fQ6z xYVVc9ksmhY2MVv8fn6b2eLr3oesDmweU35vZPVYsuQnk8f1pqvsHpsu32H0aHl2ks1j98YF TAFsUVw2Kak5mWWpRfp2CVwZnxtesBTMk6z4cfYxcwPjTZEuRk4OCQETiasHGhghbDGJC/fW s3UxcnEICRxhlFh9aTI7hLOcUWLvjGlsIFVsAgYS/78dZwGxRQRUJTpPPGIGKWIWuMco8X7v R3aQhLCAuUTHj93MEEUWEj/+nWGDsLMkTj5ZBmRzcLAANf//7AgS5gUq7/z/lgVi2U4WictT zjKD1HAKBEqsf6cMUsMIdN33U2uYQGxmAXGJW0/mM0FcLSCxZM95ZghbVOLl43+sILaogJ7E sw2b2SHiShIff89nh+jVk7gxdQobhG0t8evGZ0YIW1ti2cLXzBD3CEqcnPmEZQKjxCwk62Yh aZ+FpH0WkvZZSNoXMLKuYuQoLU4ty003MtjECIzfYxJsujsY97y0PMQowMGoxMNbsHNCiBBr YllxZe4hRmkOFiVx3lm184KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MKo4e3w4VvB6z6tt 82dO+3Z//mSNOw/bPIvrGdtPsV24/fKk9yOzmxo/HL0kphZv2PKxpnrurzetqeEH7MSvXGt8 mSzqZWlnPuH112J2ndlvfDm3PisQyDvnKdoU8/rryfcNDT/5dniWTk7/fNRbgul+htP9gPv/ O+7XV+Zuib8hf2dRjoy4zSolluKMREMt5qLiRADvXkeWwAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/HkWdsWIgJbEQJdBTEcUaOxB3LNc Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , "Acee Lindem \(acee\)" , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:56:51 -0000 Robert, This is why we do standardization, isn=B9t it? :) I=B9m quite sure =B3some implementations=B2 will not be fully compliant wit= h the formal YANG specifications to come and would have to be changed/enhanced. Formal design of BGP protocol should be done independently, YANG work is there to augment, not to interrupt. Cheers, Jeff -----Original Message----- From: "robert@raszuk.net" Date: Wednesday, December 17, 2014 at 2:28 PM To: Jeff Tantsura Cc: "Acee Lindem (acee)" , Dean Bogdanovic , "rtg-yang-coord@ietf.org" , Stephane Litkowski , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters >So are you saying that formal YANG specification say for BGP by design >will not be compatible with some implementations ? > >Or are you saying that formal design say of BGP protocol will have to >wait few years till YANG for policy spec is complete ? > >Cheers, >r. > >On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura > wrote: >> Yes, exactly, Robert - the behavior you have described is an >>implementation, not a formal specification. >> >> Regards, >> Jeff >> >>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) wrote: >>> >>> Why is this a problem if the default is to not to redistribute routes >>>between RIBs? Note that it isn=B9t like we have a set of approved routin= g >>>protocol models that are dependent on this behavior. >>> Acee >>> >>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic >>>>wrote: >>>> >>>> Robert, >>>> >>>> Your proposal is very sensible and I think this is the best option >>>> >>>> Dean >>>> >>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: >>>>> >>>>> Dean, all >>>>> >>>>> The way I read it currently in section 5.5 there are only two route >>>>> filters proposed (deny-all or allow-all). As we know some routing >>>>> protocols require explicit permission to operate (example: EBGP). If >>>>> we remove even those two primitive filters there can be impact to >>>>> other components. >>>>> >>>>> But I do support a separate work for YANG model for policy. I do >>>>> expect this to be a very interesting and involved work considering >>>>> significant diversity of policy languages across all implementations >>>>> today. >>>>> >>>>> Once that work is done we could retire section 5.5 of >>>>>*-netmod-routing-* >>>>> >>>>> Regards, >>>>> r. >>>>> >>>>> >>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic >>>>>> wrote: >>>>>> I'm in support of removing route filters from the routing cfg >>>>>>model. Route filters should be IMO part of the policy model, in >>>>>>which also ACL model belongs too. Actually, I would argue that the >>>>>>current ACL model is very suitable for route filters. >>>>>> >>>>>> Dean >>>> >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> From nobody Wed Dec 17 14:58:53 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE261A000A for ; Wed, 17 Dec 2014 14:58:51 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii-uK7mqueuZ for ; Wed, 17 Dec 2014 14:58:49 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C10A1A0127 for ; Wed, 17 Dec 2014 14:58:49 -0800 (PST) Received: by mail-yk0-f171.google.com with SMTP id 142so29413ykq.2 for ; Wed, 17 Dec 2014 14:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DFBRnIFMkHyX1KUhaH2u7BdMaCEfsVFZLAEaUptk8cI=; b=hCUReCu14QTOK6kYmfmTXx0A9xC5KmOljaYzc7/L5KmvmJjEvtboeU9e5U9+QXVUt3 zYIxU+qIPyCibtSnfwnsXAyOeeQDnf3S3rk9RKFtc/Br3OcyZf7Q8UcugE+bTvKXUmwC Ceja4D7pmpLlFMtL7QMRv4a9e8BnliaFVODRbEScXBfcVZwibfAh8/K5RN/l8G3a3D2V h2e3eqzid683Ijj35BGgjE/oGedJEpt0wnfrqQLZNVM4tPvM4Gkg9rzLsvDg24Famlis /2ziThRrUO5zwq8fwoFNagS84c34xgJJMcquhtQKs9R4in7ideqNypu0i/PFjZxhrXoU LnXw== MIME-Version: 1.0 X-Received: by 10.236.210.6 with SMTP id t6mr32658570yho.3.1418857127313; Wed, 17 Dec 2014 14:58:47 -0800 (PST) Received: by 10.170.136.132 with HTTP; Wed, 17 Dec 2014 14:58:47 -0800 (PST) In-Reply-To: References: Date: Wed, 17 Dec 2014 17:58:47 -0500 Message-ID: From: Alia Atlas To: "Rtg-yang-coord@ietf.org" Content-Type: multipart/alternative; boundary=089e016336a80f8681050a716b19 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/eRbiWII6RlpSvhu5P4IizYhRZnM Subject: [Rtg-yang-coord] Fwd: IESG YANG Model Work Redistribution X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:58:51 -0000 --089e016336a80f8681050a716b19 Content-Type: text/plain; charset=UTF-8 FYI ---------- Forwarded message ---------- From: IETF Chair Date: Wed, Dec 17, 2014 at 5:56 PM Subject: IESG YANG Model Work Redistribution To: IETF Announcement List Cc: IETF-Discussion list The IESG plans on redistributing workload in order to allow for resources to be focused on YANG model coordination. Discussion on how to do so based on demand has been going on for some time. https://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/ Primary oversight responsibility and coordination of this work across areas (AD document ownership) becomes the responsibility of Benoit Claise. Working groups with YANG model work remain the responsibility of the currently responsible AD. A YANG Model Coordination group (a RFC2418 directorate) will be created by the IESG to assist the AD and complement the work of the, YANG Doctors, Operations and Management Directorate and Routing area directorate and IAB liaison managers. The YANG doctor's responsibility to validate models remains unchanged. The YANG Model Coordination group will consist of up to three members initially and report to the Operations and Management AD assuming the YANG Model work. The responsible AD for some Operations and Management working groups will be shifted to in order to distribute the workload. For now the area associated with the working-group doesn't change. The Title of Operations and Management AD remains associated with the current responsibilities. New BOFs or working groups created to support YANG model work will be assigned to the appropriate area. As with SNMP MIBs the preference is for work to occur in the working group where the expertise exists for each data model. The IESG thinks about organizational effectiveness on an ongoing basis both tactically and strategically; When newly seated ADs are installed in March It is likely that the distribution of working groups will be revisited, as it typically is in a more limited fashion. Jari Arkko for the IESG --089e016336a80f8681050a716b19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI
---------- Forwarded mes= sage ----------
From: IETF Chair <chair@ietf.org>
Date: Wed, Dec 17, 2014 at 5:56 PM
Subject: IESG YANG Model Wor= k Redistribution
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: IETF-Discussion lis= t <ietf@ietf.org>


The= IESG plans on redistributing workload in order to allow for
resources to be=C2=A0 focused on YANG model coordination. Discussion on
how to do so=C2=A0 based on demand has been going on for some time.

https://www.ietf.org/blog/2014/11/yang-really-t= akes-off-in-the-industry/

Primary oversight responsibility and coordination of this work across
areas (AD document ownership) becomes the responsibility of Benoit Claise.<= br>
Working groups with YANG model work remain the responsibility of the
currently responsible AD.

A YANG Model Coordination group (a RFC2418 directorate) will be
created by the IESG to assist the AD and complement the work of the,
YANG Doctors, Operations and Management Directorate and Routing area
directorate and IAB liaison managers. The YANG doctor's responsibility<= br> to validate models remains unchanged.=C2=A0 The YANG Model Coordination gro= up
will consist of=C2=A0 up to three members initially and report to the
Operations and Management AD assuming the YANG Model work.

The responsible AD for some Operations and Management working groups
will be shifted to in order to distribute the workload. For now the area associated with the working-group doesn't change.

The Title of Operations and Management AD remains associated with the
current responsibilities. New BOFs or working groups created to support
YANG model work will be assigned to the appropriate area. As with SNMP
MIBs the preference is for work to occur in the working group where the
expertise exists for each data model.

The IESG thinks about organizational effectiveness on an ongoing basis
both tactically and strategically; When newly seated ADs are installed
in March It is likely that the distribution of working groups will be
revisited, as it typically is in a more limited fashion.

Jari Arkko for the IESG


--089e016336a80f8681050a716b19-- From nobody Thu Dec 18 02:10:29 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6C41A1F16 for ; Thu, 18 Dec 2014 02:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypx7RnDloAcX for ; Thu, 18 Dec 2014 02:10:23 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 91B751A1EEF for ; Thu, 18 Dec 2014 02:10:22 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 05F121CC0456; Thu, 18 Dec 2014 11:10:21 +0100 (CET) From: Ladislav Lhotka To: Robert Raszuk , Dean Bogdanovic In-Reply-To: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 18 Dec 2014 11:10:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/zbpd_WBEbAzjjGcN_0EagAE3Fbk Cc: "rtg-yang-coord@ietf.org" , "stephane.litkowski@orange.com" , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 10:10:26 -0000 Hi Robert, Robert Raszuk writes: > Dean, all > > The way I read it currently in section 5.5 there are only two route > filters proposed (deny-all or allow-all). As we know some routing > protocols require explicit permission to operate (example: EBGP). If > we remove even those two primitive filters there can be impact to > other components. Protocols can have an "enabled" switch as a part of their configuration. Does it solve this issue? Should the two primitive filters be needed before the routing policy model gets done, I'd propose to have them in a separate module that augments the "ietf-routing" module. This way, they could be replaced at any time without affecting the rest of the routing model. This extra module can be published either in the same document or in a new I-D. Lada > > But I do support a separate work for YANG model for policy. I do > expect this to be a very interesting and involved work considering > significant diversity of policy languages across all implementations > today. > > Once that work is done we could retire section 5.5 of *-netmod-routing-* > > Regards, > r. > > > On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wrote: >> I'm in support of removing route filters from the routing cfg model. Route filters should be IMO part of the policy model, in which also ACL model belongs too. Actually, I would argue that the current ACL model is very suitable for route filters. >> >> Dean -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 18 02:19:48 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6E21A6F57 for ; Thu, 18 Dec 2014 02:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8RQxJ_a8n8k for ; Thu, 18 Dec 2014 02:19:41 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DA61A079A for ; Thu, 18 Dec 2014 02:19:40 -0800 (PST) Received: from pc6 (81.151.166.145) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 18 Dec 2014 10:19:17 +0000 Message-ID: <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> From: t.petch To: Robert Raszuk , Jeff Tantsura References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> Date: Thu, 18 Dec 2014 10:03:20 +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: [81.151.166.145] X-ClientProxiedBy: DB4PR02CA0030.eurprd02.prod.outlook.com (10.242.174.158) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 042957ACD7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51444003)(24454002)(51704005)(189002)(377454003)(13464003)(89996001)(42186005)(40100003)(101416001)(84392001)(561944003)(120916001)(62966003)(50466002)(33646002)(77156002)(50986999)(23676002)(50226001)(68736005)(122386002)(62236002)(1456003)(19580395003)(14496001)(77096005)(21056001)(15975445007)(19580405001)(105586002)(31966008)(64706001)(46102003)(107046002)(106356001)(92566001)(76176999)(81686999)(20776003)(66066001)(87976001)(4396001)(97736003)(44716002)(61296003)(81816999)(93886004)(86362001)(230783001)(47776003)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/8aMtN2wtNdq9LU14tkEAQX3Cvjk Cc: rtg-yang-coord@ietf.org, Stephane Litkowski , "Acee Lindem \(acee\)" , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 10:19:44 -0000 ----- Original Message ----- From: "Robert Raszuk" To: "Jeff Tantsura" Sent: Wednesday, December 17, 2014 10:28 PM > So are you saying that formal YANG specification say for BGP by design > will not be compatible with some implementations ? Robert It might be more accurate to say that the formal YANG specification will not be compatible with any implementation! The IETF does a grand job with protocols, what can be seen on whatever connects two black boxes, and there are myriad such boxes that conform to IETF RFC. Configuring, the prime purpose of YANG models, is about poking around inside the implementation and making changes thereto, something a protocol has little to do with. So as I have tracked the development of models, first with SMI and now YANG, I see this issue getting larger, that we are trying to specify something new and different for which there has been historically no standard, except, perhaps, where implementers might use the BGP FSM as a basis for their design. Lada studied four router implementations before producing routing-cfg and used their concepts to produce the model. Cisco and Juniper diverged widely, e.g. on RIB and FIB, which led to lengthy discussions on the netmod list and a rough consensus (which I am not part of). So it is quite likely that none of the four templates match routing-cfg and no current implementation matches the YANG model. Perhaps future implementers will use a YANG model for their design and so in time, there will be a convergence. I think that this point needs to be in our thinking when producing YANG models, that it should be possible to present the appearance over NETCONF of a box that is structured in the manner of the model and to implement a box which matches the YANG model (even if, so far, noone ever has - and may be noone ever will) Meanwhile, we should go on designing protocols (something we are rather good at:-). Tom Petch > Or are you saying that formal design say of BGP protocol will have to > wait few years till YANG for policy spec is complete ? > > Cheers, > r. > > On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura > wrote: > > Yes, exactly, Robert - the behavior you have described is an implementation, not a formal specification. > > > > Regards, > > Jeff > > > >> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) wrote: > >> > >> Why is this a problem if the default is to not to redistribute routes between RIBs? Note that it isn’t like we have a set of approved routing protocol models that are dependent on this behavior. > >> Acee > >> > >>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic wrote: > >>> > >>> Robert, > >>> > >>> Your proposal is very sensible and I think this is the best option > >>> > >>> Dean > >>> > >>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: > >>>> > >>>> Dean, all > >>>> > >>>> The way I read it currently in section 5.5 there are only two route > >>>> filters proposed (deny-all or allow-all). As we know some routing > >>>> protocols require explicit permission to operate (example: EBGP). If > >>>> we remove even those two primitive filters there can be impact to > >>>> other components. > >>>> > >>>> But I do support a separate work for YANG model for policy. I do > >>>> expect this to be a very interesting and involved work considering > >>>> significant diversity of policy languages across all implementations > >>>> today. > >>>> > >>>> Once that work is done we could retire section 5.5 of *-netmod-routing-* > >>>> > >>>> Regards, > >>>> r. > >>>> > >>>> > >>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wrote: > >>>>> I'm in support of removing route filters from the routing cfg model. Route filters should be IMO part of the policy model, in which also ACL model belongs too. Actually, I would argue that the current ACL model is very suitable for route filters. > >>>>> > >>>>> Dean > >>> > >>> _______________________________________________ > >>> Rtg-yang-coord mailing list > >>> Rtg-yang-coord@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >> > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Thu Dec 18 03:00:46 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7F31A6FE3 for ; Thu, 18 Dec 2014 03:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVIL_E9EEOOU for ; Thu, 18 Dec 2014 03:00:41 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E59C1A6FBC for ; Thu, 18 Dec 2014 03:00:41 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 243C2140053; Thu, 18 Dec 2014 12:00:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418900439; bh=2A56GMJDH2tX0nLFYuruGpB2z/U8j/ZewWcZpcr6FBg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DAzBVJnixm+X3r3d0U1uuIJSDqd8kMeUj49/e0lx1W7fqM0H0PXYUjvLptAFvXc8J wKyfX4RgRYldJvgBMIjYD9LiVTBHiQSyIgUHN8hnWWaRzVqCGMAaYhytSe8cCE8BhB hN6o8gm10CCbyFduHUxuJtp2unIhU53FVg0XQJ4Y= Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> Date: Thu, 18 Dec 2014 12:00:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58CDF9C3-0B7B-4BB3-B338-FDEEA5F34F75@nic.cz> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/JV3yfkrZqorLdU6dAllFviYphPY Cc: rtg-yang-coord@ietf.org, Stephane Litkowski , Robert Raszuk , Dean Bogdanovic , Jeff Tantsura , "Acee Lindem \(acee\)" Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 11:00:44 -0000 > On 18 Dec 2014, at 11:03, t.petch wrote: >=20 > ----- Original Message ----- > From: "Robert Raszuk" > To: "Jeff Tantsura" > Sent: Wednesday, December 17, 2014 10:28 PM >=20 >> So are you saying that formal YANG specification say for BGP by = design >> will not be compatible with some implementations ? >=20 > Robert >=20 > It might be more accurate to say that the formal YANG specification = will > not be compatible with any implementation! >=20 > The IETF does a grand job with protocols, what can be seen on whatever > connects two black boxes, and there are myriad such boxes that conform > to IETF RFC. Configuring, the prime purpose of YANG models, is about > poking around inside the implementation and making changes thereto, > something a protocol has little to do with. >=20 > So as I have tracked the development of models, first with SMI and now > YANG, I see this issue getting larger, that we are trying to specify > something new and different for which there has been historically no > standard, except, perhaps, where implementers might use the BGP FSM as = a > basis for their design. >=20 > Lada studied four router implementations before producing routing-cfg > and used their concepts to produce the model. Cisco and Juniper > diverged widely, e.g. on RIB and FIB, which led to lengthy discussions > on the netmod list and a rough consensus (which I am not part of). >=20 > So it is quite likely that none of the four templates match = routing-cfg > and no current implementation matches the YANG model. Perhaps future > implementers will use a YANG model for their design and so in time, > there will be a convergence. >=20 > I think that this point needs to be in our thinking when producing = YANG > models, that it should be possible to present the appearance over > NETCONF of a box that is structured in the manner of the model and to > implement a box which matches the YANG model (even if, so far, noone > ever has - and may be noone ever will) Actually, I really studied only three implementations (Cisco IOS, JUNOS = and BIRD), with occassional input from people familiar with other = implementations. I tried to make sure that a mapping to each of the = three implementations can be established, and I believe it is still the = case if we limit ourselves to the relatively basic =E2=80=9Ccore=E2=80=9D = data models that are being produced by the NETMOD WG. However, Tom=E2=80=99s observation might well be true when it comes to = more complicated stuff that really depends on the internals of a routing = system implementation. I raised some concerns and questions in my review = of the OSPF data model: http://www.ietf.org/mail-archive/web/netmod/current/msg11029.html Lada >=20 > Meanwhile, we should go on designing protocols (something we are = rather > good at:-). >=20 > Tom Petch >=20 >> Or are you saying that formal design say of BGP protocol will have to >> wait few years till YANG for policy spec is complete ? >>=20 >> Cheers, >> r. >>=20 >> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura >> wrote: >>> Yes, exactly, Robert - the behavior you have described is an > implementation, not a formal specification. >>>=20 >>> Regards, >>> Jeff >>>=20 >>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) > wrote: >>>>=20 >>>> Why is this a problem if the default is to not to redistribute > routes between RIBs? Note that it isn=E2=80=99t like we have a set of = approved > routing protocol models that are dependent on this behavior. >>>> Acee >>>>=20 >>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic > wrote: >>>>>=20 >>>>> Robert, >>>>>=20 >>>>> Your proposal is very sensible and I think this is the best option >>>>>=20 >>>>> Dean >>>>>=20 >>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk > wrote: >>>>>>=20 >>>>>> Dean, all >>>>>>=20 >>>>>> The way I read it currently in section 5.5 there are only two > route >>>>>> filters proposed (deny-all or allow-all). As we know some routing >>>>>> protocols require explicit permission to operate (example: EBGP). > If >>>>>> we remove even those two primitive filters there can be impact to >>>>>> other components. >>>>>>=20 >>>>>> But I do support a separate work for YANG model for policy. I do >>>>>> expect this to be a very interesting and involved work > considering >>>>>> significant diversity of policy languages across all > implementations >>>>>> today. >>>>>>=20 >>>>>> Once that work is done we could retire section 5.5 of > *-netmod-routing-* >>>>>>=20 >>>>>> Regards, >>>>>> r. >>>>>>=20 >>>>>>=20 >>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic > wrote: >>>>>>> I'm in support of removing route filters from the routing cfg > model. Route filters should be IMO part of the policy model, in which > also ACL model belongs too. Actually, I would argue that the current = ACL > model is very suitable for route filters. >>>>>>>=20 >>>>>>> Dean >>>>>=20 >>>>> _______________________________________________ >>>>> Rtg-yang-coord mailing list >>>>> Rtg-yang-coord@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>=20 >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 18 06:27:21 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6481D1A89ED for ; Thu, 18 Dec 2014 06:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoQ0F9yc6uUM for ; Thu, 18 Dec 2014 06:27:16 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A74E1A6FAD for ; Thu, 18 Dec 2014 06:27:16 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so857229igb.0 for ; Thu, 18 Dec 2014 06:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ATxRehTBf3BYu+gUkNrG9CN2Lgw5UjYJte1vit4dcu8=; b=XUa5PM/kx4GjreeoES6DPSwWVprEgya5cOZ29FtSKpjMw943nCKsp8Axl22tDnmvFr QDQ/iDfEG92eU2ZtMOoPf5n/zDXLLgdsjHjrTcdt0/hbEPN44G2fLUt7JNgHlFD03KHd VbCgtmooJjQ63XBaCzNNwvYW1c66Ce3Uc74OB1tJ8ZC/jVEYb7ZgqadWIuoEI+ycglo+ iNAg2dyOCKP0uNv7EfagdPCJuNX1uNPhrfQzs1qIIT2iK7TqhN31EqPr8IpqLgMxfAI+ xZzTmD/cJgwZIZPLx6/ZgSS/vJsr1oflEDHuHuqL7uZBAkQ6n16js/NhBglYCpgjPlFu xWwQ== MIME-Version: 1.0 X-Received: by 10.50.138.226 with SMTP id qt2mr5238820igb.1.1418912835606; Thu, 18 Dec 2014 06:27:15 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.152.130 with HTTP; Thu, 18 Dec 2014 06:27:15 -0800 (PST) In-Reply-To: <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> Date: Thu, 18 Dec 2014 15:27:15 +0100 X-Google-Sender-Auth: VM60pTLfx2NU7I-PwwrHHeiPwH4 Message-ID: From: Robert Raszuk To: "t.petch" , Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/rA2q270DwDCzKU2_PuFNUoEOOe4 Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 14:27:18 -0000 Tom, Ladislav, Many thx for your insight ! r. On Thu, Dec 18, 2014 at 11:03 AM, t.petch wrote: > ----- Original Message ----- > From: "Robert Raszuk" > To: "Jeff Tantsura" > Sent: Wednesday, December 17, 2014 10:28 PM > >> So are you saying that formal YANG specification say for BGP by design >> will not be compatible with some implementations ? > > Robert > > It might be more accurate to say that the formal YANG specification will > not be compatible with any implementation! > > The IETF does a grand job with protocols, what can be seen on whatever > connects two black boxes, and there are myriad such boxes that conform > to IETF RFC. Configuring, the prime purpose of YANG models, is about > poking around inside the implementation and making changes thereto, > something a protocol has little to do with. > > So as I have tracked the development of models, first with SMI and now > YANG, I see this issue getting larger, that we are trying to specify > something new and different for which there has been historically no > standard, except, perhaps, where implementers might use the BGP FSM as a > basis for their design. > > Lada studied four router implementations before producing routing-cfg > and used their concepts to produce the model. Cisco and Juniper > diverged widely, e.g. on RIB and FIB, which led to lengthy discussions > on the netmod list and a rough consensus (which I am not part of). > > So it is quite likely that none of the four templates match routing-cfg > and no current implementation matches the YANG model. Perhaps future > implementers will use a YANG model for their design and so in time, > there will be a convergence. > > I think that this point needs to be in our thinking when producing YANG > models, that it should be possible to present the appearance over > NETCONF of a box that is structured in the manner of the model and to > implement a box which matches the YANG model (even if, so far, noone > ever has - and may be noone ever will) > > Meanwhile, we should go on designing protocols (something we are rather > good at:-). > > Tom Petch > >> Or are you saying that formal design say of BGP protocol will have to >> wait few years till YANG for policy spec is complete ? >> >> Cheers, >> r. >> >> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura >> wrote: >> > Yes, exactly, Robert - the behavior you have described is an > implementation, not a formal specification. >> > >> > Regards, >> > Jeff >> > >> >> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) > wrote: >> >> >> >> Why is this a problem if the default is to not to redistribute > routes between RIBs? Note that it isn=E2=80=99t like we have a set of app= roved > routing protocol models that are dependent on this behavior. >> >> Acee >> >> >> >>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic > wrote: >> >>> >> >>> Robert, >> >>> >> >>> Your proposal is very sensible and I think this is the best option >> >>> >> >>> Dean >> >>> >> >>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk > wrote: >> >>>> >> >>>> Dean, all >> >>>> >> >>>> The way I read it currently in section 5.5 there are only two > route >> >>>> filters proposed (deny-all or allow-all). As we know some routing >> >>>> protocols require explicit permission to operate (example: EBGP). > If >> >>>> we remove even those two primitive filters there can be impact to >> >>>> other components. >> >>>> >> >>>> But I do support a separate work for YANG model for policy. I do >> >>>> expect this to be a very interesting and involved work > considering >> >>>> significant diversity of policy languages across all > implementations >> >>>> today. >> >>>> >> >>>> Once that work is done we could retire section 5.5 of > *-netmod-routing-* >> >>>> >> >>>> Regards, >> >>>> r. >> >>>> >> >>>> >> >>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic > wrote: >> >>>>> I'm in support of removing route filters from the routing cfg > model. Route filters should be IMO part of the policy model, in which > also ACL model belongs too. Actually, I would argue that the current ACL > model is very suitable for route filters. >> >>>>> >> >>>>> Dean >> >>> >> >>> _______________________________________________ >> >>> Rtg-yang-coord mailing list >> >>> Rtg-yang-coord@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> > From nobody Thu Dec 18 07:34:02 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E481A1B6B for ; Thu, 18 Dec 2014 07:33: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5BWdaDXpugh for ; Thu, 18 Dec 2014 07:33:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4F21A1B5F for ; Thu, 18 Dec 2014 07:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=594; q=dns/txt; s=iport; t=1418916828; x=1420126428; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iFFwZNRI0HKRnPcvAjhCUYIxjrimTBpgjiOUWxzvHI0=; b=KYEQojDr/2rxzJRuihEwS8wOqSeCJtqYtELeBTfue05htuOk6UgUkZ6Q CqMQ49UK7A5m/7Bfx4okhMQXAb77NJjOS1b1xwzL6EHQ2y1NKFeRBjcwp dW+TfMRyeVUgJO/UIK4SCNf3nZXSPzZsos2iPdVCkb1R2TezSXXaQOAa5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAIHzklStJA2J/2dsb2JhbABagwaBKgTMDQKBHRYBAQEBAX2EDAEBAQQ6PwwEAgEIFQEgEDIlAgQBDQWILNR2AQEBAQEBAQEBAQEBAQEBAQEBAQEBF49yB4QpAQSOCohwkUIig2xvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="381031666" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP; 18 Dec 2014 15:33:47 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBIFXl57006727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 15:33:47 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 09:33:47 -0600 From: "Acee Lindem (acee)" To: "t.petch" , Robert Raszuk , "Jeff Tantsura" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAGP+YCAAP0GAIAAC1yAgAAE9ICAAAE8AIAAAMYAgAADzICAAGIZOIAAWF4A Date: Thu, 18 Dec 2014 15:33:47 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> In-Reply-To: <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <75DFE54963BF0E4E92A5365E398C600D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/4ehncKZkV6DC-HbmI5KMNe0yDEs Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 15:33:57 -0000 On 12/18/14, 5:03 AM, "t.petch" wrote: >----- Original Message ----- >From: "Robert Raszuk" >To: "Jeff Tantsura" >Sent: Wednesday, December 17, 2014 10:28 PM > >> So are you saying that formal YANG specification say for BGP by design >> will not be compatible with some implementations ? > >Robert > >It might be more accurate to say that the formal YANG specification will >not be compatible with any implementation! I believe the model (as proposed) is aligned with BIRD. Thanks, Acee=20 > From nobody Thu Dec 18 07:59:11 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC8D1A1B2C for ; Thu, 18 Dec 2014 07:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: 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_KPTsB9HF20 for ; Thu, 18 Dec 2014 07:59:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E8B1A1A68 for ; Thu, 18 Dec 2014 07:59:08 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 2C8F513FCB8; Thu, 18 Dec 2014 16:59:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418918346; bh=0Ikw4a3GV6sjrhzZ5D9m7K9zfBHO+E60dN+Ev1Mw+iA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LdHXTiYGEuW6ov17zSJIHtnIL5HWRjVfl3pmCjxvPkzvrZGmHw6pDvSODGmvf/WRC xI05mrbPnESzrOUarT83uDuLOg7aBmWMM+FIwgrEaFfgu682hlmh+493K5XrXZExET VT5/wYSj6pMBhg6YMuNGNcukGjRkpCbXvzPehsjQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 18 Dec 2014 16:59:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3F14B006-781B-42EA-89DE-30B351B57811@nic.cz> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <00e201d01aac$0860c0c0$4001a8c0@gateway.2wire.net> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/M9Edegwpdrii5DuJHN4KSPpVVi4 Cc: "rtg-yang-coord@ietf.org" , Stephane Litkowski , Robert Raszuk , "t.petch" , Jeff Tantsura , Dean Bogdanovic Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 15:59:10 -0000 > On 18 Dec 2014, at 16:33, Acee Lindem (acee) wrote: >=20 >=20 >=20 > On 12/18/14, 5:03 AM, "t.petch" wrote: >=20 >> ----- Original Message ----- >> From: "Robert Raszuk" >> To: "Jeff Tantsura" >> Sent: Wednesday, December 17, 2014 10:28 PM >>=20 >>> So are you saying that formal YANG specification say for BGP by = design >>> will not be compatible with some implementations ? >>=20 >> Robert >>=20 >> It might be more accurate to say that the formal YANG specification = will >> not be compatible with any implementation! >=20 > I believe the model (as proposed) is aligned with BIRD. Not really. For instance, BIRD has no notion of routing instances or = multiple address families, and it uses a special pseudo-protocol = =E2=80=98pipe=E2=80=99 for passing routes between routing tables. I=E2=80=99= d say the model is closer to JUNOS than BIRD. And as for IOS, I wrote an XSLT stylesheet that was able to transform = any YANG configuration comprising the modules ietf-interfaces, ietf-ip, = ietf-system, ietf-routing, and ietf-ipv[46]-unicast-routing into IOS = configuration: = https://gitlab.labs.nic.cz/labs/yang-tools/tree/master/data-models/xslt/ci= sco-ios I haven=E2=80=99t updated it for some time so that it probably won=E2=80=99= t work now due to the changes to the modules that happened in the mean = time, but I am convinced it can still be done. Note also that I wasn=E2=80=99t affiliated with CZ.NIC (=3D BIRD = maintainer) at the time when the routing module was designed. Lada >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 18 08:13:55 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D051A90CA for ; Thu, 18 Dec 2014 08:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bww6eDpKre9 for ; Thu, 18 Dec 2014 08:13:43 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 79B8A1A1A68 for ; Thu, 18 Dec 2014 08:13:21 -0800 (PST) Received: (qmail 15427 invoked by uid 0); 18 Dec 2014 16:13:17 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 18 Dec 2014 16:13:17 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id V4D71p00G2SSUrH014DAc4; Thu, 18 Dec 2014 09:13:17 -0700 X-Authority-Analysis: v=2.1 cv=EL+VjTpC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=NojvYFcnAAAA:8 a=JZ-65iEVhaEcivQLGeQA:9 a=JSGsUzmQoDrw56B8:21 a=Hz3Kop-yDgBa2_8d:21 a=pILNOxqGKmIA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=M0c-BsepF_cA:10 a=9uUzcS5Nrb8A: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:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=eGZM8jw67FZYcFMiWgUHs/I1LJWBbJGClBa/9bn+fQo=; b=SOgveCcQ8OAALSPB2dsjFzFoCQizUXO0kB0QVxJSe7WYdSiinSP9XQKQNvxD9THFHN5eCAZ7VRBajllDKIWh+jiQZObv5atCQ/HEWozEIJLMtLSsh8jLy7qkhqL8g/vc; Received: from box313.bluehost.com ([69.89.31.113]:60209 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y1dhK-0003KM-TP for rtg-yang-coord@ietf.org; Thu, 18 Dec 2014 09:13:07 -0700 Message-ID: <5492FD22.7040303@labn.net> Date: Thu, 18 Dec 2014 11:13:22 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing YANG Coordination References: <5492FC44.6020607@labn.net> In-Reply-To: <5492FC44.6020607@labn.net> X-Forwarded-Message-Id: <5492FC44.6020607@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/_z5QYaW6tQMpUUSI-WgdG6fd_Hw Subject: [Rtg-yang-coord] Fwd: Re: [Teas] TEAS - Virtual Interim Meeting Agenda X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:13:47 -0000 fyi -------- Original Message -------- Subject: Re: [Teas] TEAS - Virtual Interim Meeting Agenda Date: Thu, 18 Dec 2014 11:09:40 -0500 From: Lou Berger To: BRUNGARD, DEBORAH A , teas@ietf.org Just a reminder that this is scheduled for later today. Material is posted (although I expect one set to be updated before the meeting): http://www.ietf.org/proceedings/interim/2014/12/18/teas/proceedings.html Etherpad for the meeting is at: http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-teas Lou (and Deborah) On 12/16/2014 4:32 PM, BRUNGARD, DEBORAH A wrote: > Agenda - TEAS Virtual Interim > Dec. 18, 2014 20:00 UTC (Target: 2 hour duration) > https://ietf.webex.com/ietf/j.php?MTID=m2c971eab8a0059f69b228fbf2549532f > Meeting number: 641 996 091 > Meeting password: 1234 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 641 996 091 > Meeting Objective: Clarify the relationship of a TE Topology YANG > model to other models in development > (including models for non-TE topology, TE tunnel/LSP, control plane > protocols, specific data planes) > - 10 min - Agenda/Intro > - 10 min - I2RS Related Activities (Sue) > - 10 min - TE RSVP/Tunnel/LSP YANG Discussions (Tarek) > - 5 min - TE Topology YANG Model Design Team Introduction (Chairs) > – Design Team Led Discussion > - Open Discussion > The existing set of related drafts includes: > draft-liu-yang-abstract-te-topo > draft-clemm-i2rs-yang-l3-topo > draft-clemm-i2rs-yang-network-topo > draft-chen-mpls-te-yang-cfg (LSP focused) > draft-gandhi-mpls-te-yang-model (LSP focused) > draft-ietf-netmod-routing-cfg (Foundational work, not topology specific) > draft-hares-i2rs-info-model-service-topo (Topology only) > draft-vergara-flexigrid-yang (Data plane technology specific) > draft-dharini-netmod-g-698-2-yang (Data plane technology specific) > draft-dong-i2rs-yang-l2-network-topology(Data plane technology specific) > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Thu Dec 18 08:30:10 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E921A90FB for ; Thu, 18 Dec 2014 08:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPX4HeCrJh3U for ; Thu, 18 Dec 2014 08:29:54 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC7F1A9121 for ; Thu, 18 Dec 2014 08:28:19 -0800 (PST) Received: by mail-yk0-f182.google.com with SMTP id 131so656791ykp.41 for ; Thu, 18 Dec 2014 08:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vV2h4JsxP48hMvf6SzH6p4p63QhanS66R7jSthE/7cw=; b=VXXi72g2AUyrKTXV/EdpUmZrFiToFFUaNtOvGfj74iOHeqlaPryERySZ28NoatAwdK vo1Owu5gRz+zkV0IH/yWJ96gFIKEFZ63fspAsLUdeHk/2Q1fdmmfMyNV7F7schbzDfWp xXeZbY/HPv3fSWqfuvPxDwsCjSGZ5A0UWS8P2YzPhLU7FA/5FeclQ3WptWo6FLqVS8zT I+oVLsxmhNFixewzvxihEaWss7SjE6K6Yl2oIUKGW0ePosy4VrStsuy49fHJjEFxVyUU R8M6jN+ygzD9bfI9DoHFG7MuveQ2bPjB8i7r2EvCucQ8yDphR1yB3C60IIN98qHEqfze jIuA== MIME-Version: 1.0 X-Received: by 10.236.21.206 with SMTP id r54mr2535205yhr.16.1418920098879; Thu, 18 Dec 2014 08:28:18 -0800 (PST) Received: by 10.170.136.132 with HTTP; Thu, 18 Dec 2014 08:28:18 -0800 (PST) In-Reply-To: References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> Date: Thu, 18 Dec 2014 11:28:18 -0500 Message-ID: From: Alia Atlas To: "Rtg-yang-coord@ietf.org" Content-Type: multipart/alternative; boundary=089e0149d02c7561a9050a801460 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/1wZ9uunJx0PF-SwXDwGBkM8lc18 Subject: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 16:29:59 -0000 --089e0149d02c7561a9050a801460 Content-Type: text/plain; charset=UTF-8 Are there routing YANG models that are running into concerns around floating point? Regards, Alia ---------- Forwarded message ---------- From: Acee Lindem (acee) Date: Wed, Dec 17, 2014 at 7:30 PM Subject: Re: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard To: "t.p." , "adrian@olddog.co.uk" < adrian@olddog.co.uk> Cc: "draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org" < draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>, "ietf@ietf.org" < ietf@ietf.org> Tom, John Drake will update the reference in the OSPF TE Extensions draft. I agree that YANG should have a corresponding common data type for floating point since, for better or worse, RFC 2210 chose IEEE 32-bit floating point representation for bandwidth many years ago. Thanks, Acee On 12/17/14, 5:14 AM, "t.p." wrote: >Acee > >Sorry that my original comment was opaque. Partly, I was agreeing with >Adrian that a reference to a floating point standard would be a good >idea, but disagreeing with Adrain about the particular standard, that a >more recent one was available and had been used previously by an IETF >RFC. That part I hope is now clear, thanks to the clarifications by >others. > >My tangential comment was that YANG has no facility to model floating >point numbers, having looked at doing so and rejected it, several times, >reckoning that the decimal-64, defined in RFC6020 section 9.3, is >adequate for network configuration. > >A consequence of this, which is understood, is that if you think of a >number, express it in YANG's decimal-64, convert it to floating point >because that is what XPath uses (and so is used by YANG's conditional >statements), convert it back to decimal-64 then you do not get the >number you first thought of (sometimes), so a test for equality will >fail, when you might expect it to succeed. > >Is this an issue? The consensus of the netmod WG (AFAICT) is that it is >not, that the use of floating point in the IETF is minimal - after all, >it took SNMP over 20 years to get round to specifying it. > >But given the explosion of interest in YANG recently, I think it is a >topic to keep an eye on so when I read an I-D and find floating point, I >point{!} out that it cannot readily be modeled. I suspect that, in this >case, consistency with what has gone before outweighs the facility to do >it in YANG. > >Tom Petch > > >----- Original Message ----- >From: "Acee Lindem (acee)" >To: >Cc: "t.p." ; >; > >Sent: Monday, December 15, 2014 4:58 PM >Subject: Re: Last Call: >(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard > > >Hi Adrian, Tom, >Can you guys indicate how you would like to see this comment reflected >in the draft? Are you suggesting to change he encoding to 64 bits for >the new bandwidth sub-TLVs? >Thanks, >Acee >On Dec 12, 2014, at 1:16 PM, Adrian Farrel wrote: > >> Good catch Tom, >> >> Acee, the trick is to go to 6340 and look in the references :-) >> >> [IEEE.754.2008] Institute of Electrical and Electronics Engineers, >> "Standard for Floating-Point Arithmetic", >> IEEE Standard 754, August 2008. >> >> A >> >>> -----Original Message----- >>> From: Acee Lindem (acee) [mailto:acee@cisco.com] >>> Sent: 12 December 2014 18:14 >>> To: t.p. >>> Cc: adrian@olddog.co.uk; >> draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org; >>> ietf@ietf.org >>> Subject: Re: Last Call: >(OSPF >> Traffic >>> Engineering (TE) Metric Extensions) to Proposed Standard >>> >>> Hi Tom, >>> >>> On Dec 12, 2014, at 1:08 PM, t.p. wrote: >>> >>>> On the question of Floating-Point, there is now 754-2008, which is a >>>> tighter spec and is used in RFC6340. >>> >>> What is 754-2008? >>> >>> Thanks, >>> Acee >>> >>> >>> >>>> >>>> At a tangent, the issue of floating-point support has surfaced a >number >>>> of times in YANG and, to date, has always been rejected, reckoning >that >>>> suppport for 64-bit decimal is adequate for data modelling. The >>>> interactions with XPath (which is used as a basis for YANG >constraint >>>> statements), where floating-point is allowed, have caused a number >of >>>> discussions, some ongoing, about the comparison of a floating-point >>>> number to a 64-bit decimal one. Something to be aware of should you >ever >>>> want to model this in YANG. >>>> >>>> Tom Petch >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Adrian Farrel" >>>> To: >>>> Cc: ; >>>> Sent: Wednesday, December 10, 2014 11:07 PM >>>> >>>>> All, >>>>> >>>>> I reviewed this document as AD and found a few small points that I >>>> have asked >>>>> the authors to address as IETF last call comments. >>>>> >>>>> Adrian >>>>> >>>>> === >>>>> >>>>> Please look for places where you have "proposed" something and >change >>>>> that to "defined". >>>>> >>>>> --- >>>>> >>>>> It would be good to include a reference for encoding floating point >>>>> integers. The usual is (I think)... >>>>> >>>>> IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", >>>>> Standard 754-1985, 1985 (ISBN 1-5593-7653-8). >>>>> >>>>> --- >>>>> >>>>> Section 4.2.5 >>>>> >>>>> Implementations MAY also permit the configuration of a static (non >>>>> dynamic) offset value (in microseconds) to be added to the >measured >>>>> delay value, to facilitate the communication of operator specific >>>>> delay constraints. >>>>> >>>>> On the third reading I got it! I'm slow (I have a high delay :-) >>>>> >>>>> The point here is that the measured value and the static value are >>>> added >>>>> together and the sum is transmitted in this field. I'd suggest... >>>>> >>>>> Implementations MAY also permit the configuration of a static (non >>>>> dynamic) offset value (in microseconds) to be added to the >measured >>>> >>>>> delay value before encoding into this TLV, to facilitate the >>>>> communication of operator specific delay constraints. >>>>> >>>>> Similarly in 4.2.6. >>>>> >>>>> --- >>>>> >>>>> 4.2.7 appears out of sequence. But since it repeats the content of >>>>> 4.2.4 I suggest you merge them and talk about the plurality of >fields. >>>>> >>>>> --- >>>>> >>>>> Section 7 >>>>> >>>>> "Sections 6 and 7 provide" should be 5 and 6. >>>>> >>>>> --- >>>>> >>>>> Section 10 >>>>> >>>>> "As per (RFC3630), unrecognized TLVs should be silently ignored" >>>>> >>>>> There has been confusion about what 3630 means by "silently >ignored". >>>>> In particular, some enthusiastic implementations thought this meant >>>> the >>>>> TLVs should be stripped from the LSA before it is propagated. I >think >>>> it >>>>> is worth the few words to explicitly state that this is not the >case. >>>>> >>>>> --- >>>>> >>>>> Section 13 >>>>> >>>>> RFC 4203 is used in a normative way, please move it to the other >>>>> section. >>>>> >>>>> >>>>> >>>> >> > --089e0149d02c7561a9050a801460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Are there routing YANG models that are running into c= oncerns around floating point?

Regards,
= Alia

---------- Forwarded message -----= -----
From: Acee Lindem (acee) <acee@cisco.com>
Date: Wed, Dec 17, 2014 at 7:30 PM
Subject: Re: Last Call: <dr= aft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic Engineering (TE= ) Metric Extensions) to Proposed Standard
To: "t.p." <daedulus@btconnect.com>, "= adrian@olddog.co.uk" <adrian@olddog.co.uk>
Cc: &qu= ot;draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org" <dr= aft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>

Tom,

John Drake will update the reference in the OSPF TE Extensions draft. I
agree that YANG should have a corresponding common data type for floating point since, for better or worse, RFC 2210 chose IEEE 32-bit floating
point representation for bandwidth many years ago.

Thanks,
Acee

On 12/17/14, 5:14 AM, "t.p." <daedulus@btconnect.com> wrote:

>Acee
>
>Sorry that my original comment was opaque.=C2=A0 =C2=A0Partly, I was ag= reeing with
>Adrian that a reference to a floating point standard would be a good >idea, but disagreeing with Adrain about the particular standard, that a=
>more recent one was available and had been used previously by an IETF >RFC.=C2=A0 That part I hope is now clear, thanks to the clarifications = by
>others.
>
>My tangential comment was that YANG has no facility to model floating >point numbers, having looked at doing so and rejected it, several times= ,
>reckoning that the decimal-64, defined in RFC6020 section 9.3, is
>adequate for network configuration.
>
>A consequence of this, which is understood, is that if you think of a >number, express it in YANG's decimal-64, convert it to floating poi= nt
>because that is what XPath uses (and so is used by YANG's condition= al
>statements), convert it back to decimal-64 then you do not get the
>number you first thought of (sometimes), so a test for equality will >fail, when you might expect it to succeed.
>
>Is this an issue?=C2=A0 The consensus of the netmod WG (AFAICT) is that= it is
>not, that the use of floating point in the IETF is minimal - after all,=
>it took SNMP over 20 years to get round to specifying it.
>
>But given the explosion of interest in YANG recently, I think it is a >topic to keep an eye on so when I read an I-D and find floating point, = I
>point{!} out that it cannot readily be modeled.=C2=A0 I suspect that, i= n this
>case, consistency with what has gone before outweighs the facility to d= o
>it in YANG.
>
>Tom Petch
>
>
>----- Original Message -----
>From: "Acee Lindem (acee)" <acee@cisco.com>
>To: <adrian@olddog.co.uk&= gt;
>Cc: "t.p." <daed= ulus@btconnect.com>;
><draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>; ><ietf@ietf.org>
>Sent: Monday, December 15, 2014 4:58 PM
>Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt= >
>(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard<= br> >
>
>Hi Adrian, Tom,
>Can you guys indicate how you would like to see this comment reflected<= br> >in the draft? Are you suggesting to change he encoding to 64 bits for >the new bandwidth sub-TLVs?
>Thanks,
>Acee
>On Dec 12, 2014, at 1:16 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
>
>> Good catch Tom,
>>
>> Acee, the trick is to go to 6340 and look in the references :-) >>
>>=C2=A0 =C2=A0[IEEE.754.2008]=C2=A0 Institute of Electrical and Elec= tronics Engineers,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "Standard for Floating-Point Arithmetic",
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 IEEE Standard 754, August 2008.
>>
>> A
>>
>>> -----Original Message-----
>>> From: Acee Lindem (acee) [mailto:acee@cisco.com]
>>> Sent: 12 December 2014 18:14
>>> To: t.p.
>>> Cc: adrian@olddog.co.uk= ;
>> draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org;
>>> ietf@ietf.org
>>> Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensio= ns-08.txt>
>(OSPF
>> Traffic
>>> Engineering (TE) Metric Extensions) to Proposed Standard
>>>
>>> Hi Tom,
>>>
>>> On Dec 12, 2014, at 1:08 PM, t.p. <daedulus@btconnect.com> wrote:
>>>
>>>> On the question of Floating-Point, there is now 754-2008, = which is a
>>>> tighter spec and is used in RFC6340.
>>>
>>> What is 754-2008?
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>>
>>>> At a tangent, the issue of floating-point support has surf= aced a
>number
>>>> of times in YANG and, to date, has always been rejected, r= eckoning
>that
>>>> suppport for 64-bit decimal is adequate for data modelling= .=C2=A0 The
>>>> interactions with XPath (which is used as a basis for YANG=
>constraint
>>>> statements), where floating-point is allowed, have caused = a number
>of
>>>> discussions, some ongoing, about the comparison of a float= ing-point
>>>> number to a 64-bit decimal one. Something to be aware of s= hould you
>ever
>>>> want to model this in YANG.
>>>>
>>>> Tom Petch
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Adrian Farrel" <adrian@olddog.co.uk>
>>>> To: <draft-ietf-ospf-te-metric-extensions.all@tools.iet= f.org>
>>>> Cc: <ospf@ietf.org= >; <ietf@ietf.org>
>>>> Sent: Wednesday, December 10, 2014 11:07 PM
>>>>
>>>>> All,
>>>>>
>>>>> I reviewed this document as AD and found a few small p= oints that I
>>>> have asked
>>>>> the authors to address as IETF last call comments.
>>>>>
>>>>> Adrian
>>>>>
>>>>> =3D=3D=3D
>>>>>
>>>>> Please look for places where you have "proposed&q= uot; something and
>change
>>>>> that to "defined".
>>>>>
>>>>> ---
>>>>>
>>>>> It would be good to include a reference for encoding f= loating point
>>>>> integers. The usual is (I think)...
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0IEEE, "IEEE Standard fo= r Binary Floating-Point Arithmetic",
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Standard 754-1985, 1985 (ISB= N 1-5593-7653-8).
>>>>>
>>>>> ---
>>>>>
>>>>> Section 4.2.5
>>>>>
>>>>>=C2=A0 Implementations MAY also permit the configuratio= n of a static (non
>>>>>=C2=A0 dynamic) offset value (in microseconds) to be ad= ded to the
>measured
>>>>>=C2=A0 delay value, to facilitate the communication of = operator specific
>>>>>=C2=A0 delay constraints.
>>>>>
>>>>> On the third reading I got it! I'm slow (I have a = high delay :-)
>>>>>
>>>>> The point here is that the measured value and the stat= ic value are
>>>> added
>>>>> together and the sum is transmitted in this field. I&#= 39;d suggest...
>>>>>
>>>>>=C2=A0 Implementations MAY also permit the configuratio= n of a static (non
>>>>>=C2=A0 dynamic) offset value (in microseconds) to be ad= ded to the
>measured
>>>>
>>>>>=C2=A0 delay value before encoding into this TLV, to fa= cilitate the
>>>>>=C2=A0 communication of operator specific delay constra= ints.
>>>>>
>>>>> Similarly in 4.2.6.
>>>>>
>>>>> ---
>>>>>
>>>>> 4.2.7 appears out of sequence. But since it repeats th= e content of
>>>>> 4.2.4 I suggest you merge them and talk about the plur= ality of
>fields.
>>>>>
>>>>> ---
>>>>>
>>>>> Section 7
>>>>>
>>>>> "Sections 6 and 7 provide" should be 5 and 6= .
>>>>>
>>>>> ---
>>>>>
>>>>> Section 10
>>>>>
>>>>>=C2=A0 "As per (RFC3630), unrecognized TLVs should= be silently ignored"
>>>>>
>>>>> There has been confusion about what 3630 means by &quo= t;silently
>ignored".
>>>>> In particular, some enthusiastic implementations thoug= ht this meant
>>>> the
>>>>> TLVs should be stripped from the LSA before it is prop= agated. I
>think
>>>> it
>>>>> is worth the few words to explicitly state that this i= s not the
>case.
>>>>>
>>>>> ---
>>>>>
>>>>> Section 13
>>>>>
>>>>> RFC 4203 is used in a normative way, please move it to= the other
>>>>> section.
>>>>>
>>>>>
>>>>>
>>>>
>>
>

--089e0149d02c7561a9050a801460-- From nobody Thu Dec 18 09:05:35 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0051A6FB9; Thu, 18 Dec 2014 04:19: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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tanfmVWewCaq; Thu, 18 Dec 2014 04:19:58 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF801A6FA3; Thu, 18 Dec 2014 04:19:57 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-ed-5492c66b43e4 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.E3.29772.B66C2945; Thu, 18 Dec 2014 13:19:55 +0100 (CET) Received: from [159.107.197.172] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.195.1; Thu, 18 Dec 2014 13:19:54 +0100 Message-ID: <5492C66A.3070807@ericsson.com> Date: Thu, 18 Dec 2014 13:19:54 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kent Watsen , Ladislav Lhotka , Jeffrey Haas References: <20141211161640.GC16279@pfrc> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvjW72sUkhBk/3ilvsP/iW1eLAHHaL C6vmslnMv9jIavH7+W1mB1aPJUt+Mnlcb7rK7rHp8h1Gj8u9W1kDWKK4bFJSczLLUov07RK4 MnqOr2crmMtb8X3rNdYGxkVcXYycHBICJhIdr2ewQdhiEhfurQeyuTiEBI4wSmzaO4URwlnL KDH9xQ1mkCpeAW2J/e9usYLYLAKqEr13V7KA2GwCRhJT+8+D2aICURJ3LvWzQtQLSpyc+QQs LiKQLtHUfRbMZhaIk/i//CQTiC0s4CSx4slGsPlCAjUSu06tAKrh4OAUMJR49IMHotxW4sKc 61Ct8hLb386BKteQeHjhL+sERsFZSLbNQtIyC0nLAkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiB4X1wy2+DHYwvnzseYhTgYFTi4TVwnhQixJpYVlyZe4hRmoNFSZx34bl5wUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYlWLvrZi3bMHHW93te7QORx6KX2RxtG2Zxtq8N48vtlQu /aFQ/J5ZMH1X7onm19fk/tnWJH54vzJqirKMgaVLzucpiyapsL048NKTo8TxSMrSpeYXXkau qvi9vZ11hUPZ+xvf8rqbV3WsmTwnzfnYVYaTblc7dDlZ9j6fNHvJ70Wi+6anrVCNbFRiKc5I NNRiLipOBAD9eY4JUAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/NlZGm6lVKhjYlXCRUmdM1yGmNLg X-Mailman-Approved-At: Thu, 18 Dec 2014 09:05:34 -0800 Cc: "rtg-yang-coord@ietf.org" , "netmod@ietf.org" Subject: Re: [Rtg-yang-coord] [netmod] Recursive modeling in Yang? X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 12:20:00 -0000 Hello, I would still love to have recursive containment in YANG. I have a number of use cases where recursion is the natural, the" easy to understand" way to model. E.g. we model HW parts as replaceable units (chassis, shelves, cabinets, cards, daughter cards, interfaces, etc). There can be such a variety of containments, relationships, that the easiest way is to use some global holding structure "replaceable unit" and let it contain itself. And yes all this can be done by a simple list with references, but that has a number of disadvantages. Just by allowing a grouping to contain itself, most of my use cases would be solved. And maxdepth is a good idea. Balazs On 2014-12-12 16:43, Kent Watsen wrote: > >> Yes, this has already been discussed several times. It was a deliberate >> design decision to avoid recursive structures in YANG. > > As I understand it, the decision was made was to enable parsers to be > deterministic. Is that right? - how is it then that other MLs (XSD) can > support recursion? > > My hope is that YANG can support recursion by requiring a "max-depth" or > similar attribute. Most of my use-cases only need a handful number of > recursions. Could something like a max-depth attribute be used to enable > recursion in YANG? > > Thanks, > Kent > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Dec 18 10:36:16 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0421A1A6FCF for ; Thu, 18 Dec 2014 10:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_27=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvQeVfKLJYPn for ; Thu, 18 Dec 2014 10:36:11 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D66A1A6FC8 for ; Thu, 18 Dec 2014 10:36:10 -0800 (PST) Received: from AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) by AMXPR07MB120.eurprd07.prod.outlook.com (10.242.70.156) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 18 Dec 2014 18:06:11 +0000 Received: from pc6 (81.151.166.145) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.36.23; Thu, 18 Dec 2014 18:06:10 +0000 Message-ID: <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> From: t.petch To: Alia Atlas , References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> Date: Thu, 18 Dec 2014 18:05:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.166.145] X-ClientProxiedBy: AM3PR03CA019.eurprd03.prod.outlook.com (10.141.191.147) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMXPR07MB054; X-Forefront-PRVS: 042957ACD7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(37854004)(164054003)(479174004)(51704005)(13464003)(189002)(24454002)(2473001)(377454003)(15975445007)(97736003)(92566001)(86362001)(19580395003)(19580405001)(62236002)(44716002)(20776003)(4396001)(230783001)(50226001)(14496001)(77156002)(50986999)(81686999)(66066001)(76176999)(84392001)(1456003)(68736005)(64706001)(89996001)(101416001)(81816999)(1556002)(47776003)(87976001)(46102003)(61296003)(62966003)(40100003)(99396003)(33646002)(42186005)(21056001)(23676002)(50466002)(561944003)(120916001)(93886004)(122386002)(31966008)(106356001)(77096005)(107886001)(107046002)(105586002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2014 18:06:10.7608 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB120; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/vi-y5ToD2efeojIzTeYuD5V4pSg Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:36:15 -0000 ----- Original Message ----- From: "Alia Atlas" To: Sent: Thursday, December 18, 2014 4:28 PM > Are there routing YANG models that are running into concerns around > floating point? Alia 24Apr14 netmod WG list Robert Varga "while modeling some protocols (notably RSVP), we came across the need to represent IEEE754-2008 floating types without losing precision. I'd like to ask what is the group's sentiment regarding extending the base types with at least binary{32,64} (which have their counterparts in XML schema datatypes)." which suggests that the answer is yes. I might have posed a slightly different question, such as - does anyone outside a few on the netmod WG list realise that YANG has no support for floating point, just decimal-64? In passing, YANG did have floating point support in 2008/2009, which led to Martin saying "Here's a proposal for solving our float problem, which is one of the few remaining open issues in the YANG document. I suggest we remove the float types, and instead replace them with a fix point decimal type, much like xs:decimal. " which duly happened. Details in the archives. Interestingly, for me, this preceded the addition of floating point to SMI with RFC6340 in August 2011; one of the arguments for removing floating point from YANG was that SMI had never needed it in all its years. Tom Petch > Regards, > Alia > > ---------- Forwarded message ---------- > From: Acee Lindem (acee) > Date: Wed, Dec 17, 2014 at 7:30 PM > Subject: Re: Last Call: (OSPF > Traffic Engineering (TE) Metric Extensions) to Proposed Standard > To: "t.p." , "adrian@olddog.co.uk" < > adrian@olddog.co.uk> > Cc: "draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org" < > draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>, "ietf@ietf.org" < > ietf@ietf.org> > > Tom, > > John Drake will update the reference in the OSPF TE Extensions draft. I > agree that YANG should have a corresponding common data type for floating > point since, for better or worse, RFC 2210 chose IEEE 32-bit floating > point representation for bandwidth many years ago. > > Thanks, > Acee > > On 12/17/14, 5:14 AM, "t.p." wrote: > > >Acee > > > >Sorry that my original comment was opaque. Partly, I was agreeing with > >Adrian that a reference to a floating point standard would be a good > >idea, but disagreeing with Adrain about the particular standard, that a > >more recent one was available and had been used previously by an IETF > >RFC. That part I hope is now clear, thanks to the clarifications by > >others. > > > >My tangential comment was that YANG has no facility to model floating > >point numbers, having looked at doing so and rejected it, several times, > >reckoning that the decimal-64, defined in RFC6020 section 9.3, is > >adequate for network configuration. > > > >A consequence of this, which is understood, is that if you think of a > >number, express it in YANG's decimal-64, convert it to floating point > >because that is what XPath uses (and so is used by YANG's conditional > >statements), convert it back to decimal-64 then you do not get the > >number you first thought of (sometimes), so a test for equality will > >fail, when you might expect it to succeed. > > > >Is this an issue? The consensus of the netmod WG (AFAICT) is that it is > >not, that the use of floating point in the IETF is minimal - after all, > >it took SNMP over 20 years to get round to specifying it. > > > >But given the explosion of interest in YANG recently, I think it is a > >topic to keep an eye on so when I read an I-D and find floating point, I > >point{!} out that it cannot readily be modeled. I suspect that, in this > >case, consistency with what has gone before outweighs the facility to do > >it in YANG. > > > >Tom Petch > > > > > >----- Original Message ----- > >From: "Acee Lindem (acee)" > >To: > >Cc: "t.p." ; > >; > > > >Sent: Monday, December 15, 2014 4:58 PM > >Subject: Re: Last Call: > >(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard > > > > > >Hi Adrian, Tom, > >Can you guys indicate how you would like to see this comment reflected > >in the draft? Are you suggesting to change he encoding to 64 bits for > >the new bandwidth sub-TLVs? > >Thanks, > >Acee > >On Dec 12, 2014, at 1:16 PM, Adrian Farrel wrote: > > > >> Good catch Tom, > >> > >> Acee, the trick is to go to 6340 and look in the references :-) > >> > >> [IEEE.754.2008] Institute of Electrical and Electronics Engineers, > >> "Standard for Floating-Point Arithmetic", > >> IEEE Standard 754, August 2008. > >> > >> A > >> > >>> -----Original Message----- > >>> From: Acee Lindem (acee) [mailto:acee@cisco.com] > >>> Sent: 12 December 2014 18:14 > >>> To: t.p. > >>> Cc: adrian@olddog.co.uk; > >> draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org; > >>> ietf@ietf.org > >>> Subject: Re: Last Call: > >(OSPF > >> Traffic > >>> Engineering (TE) Metric Extensions) to Proposed Standard > >>> > >>> Hi Tom, > >>> > >>> On Dec 12, 2014, at 1:08 PM, t.p. wrote: > >>> > >>>> On the question of Floating-Point, there is now 754-2008, which is a > >>>> tighter spec and is used in RFC6340. > >>> > >>> What is 754-2008? > >>> > >>> Thanks, > >>> Acee > >>> > >>> > >>> > >>>> > >>>> At a tangent, the issue of floating-point support has surfaced a > >number > >>>> of times in YANG and, to date, has always been rejected, reckoning > >that > >>>> suppport for 64-bit decimal is adequate for data modelling. The > >>>> interactions with XPath (which is used as a basis for YANG > >constraint > >>>> statements), where floating-point is allowed, have caused a number > >of > >>>> discussions, some ongoing, about the comparison of a floating-point > >>>> number to a 64-bit decimal one. Something to be aware of should you > >ever > >>>> want to model this in YANG. > >>>> > >>>> Tom Petch > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: "Adrian Farrel" > >>>> To: > >>>> Cc: ; > >>>> Sent: Wednesday, December 10, 2014 11:07 PM > >>>> > >>>>> All, > >>>>> > >>>>> I reviewed this document as AD and found a few small points that I > >>>> have asked > >>>>> the authors to address as IETF last call comments. > >>>>> > >>>>> Adrian > >>>>> > >>>>> === > >>>>> > >>>>> Please look for places where you have "proposed" something and > >change > >>>>> that to "defined". > >>>>> > >>>>> --- > >>>>> > >>>>> It would be good to include a reference for encoding floating point > >>>>> integers. The usual is (I think)... > >>>>> > >>>>> IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", > >>>>> Standard 754-1985, 1985 (ISBN 1-5593-7653-8). > >>>>> > >>>>> --- > >>>>> > >>>>> Section 4.2.5 > >>>>> > >>>>> Implementations MAY also permit the configuration of a static (non > >>>>> dynamic) offset value (in microseconds) to be added to the > >measured > >>>>> delay value, to facilitate the communication of operator specific > >>>>> delay constraints. > >>>>> > >>>>> On the third reading I got it! I'm slow (I have a high delay :-) > >>>>> > >>>>> The point here is that the measured value and the static value are > >>>> added > >>>>> together and the sum is transmitted in this field. I'd suggest... > >>>>> > >>>>> Implementations MAY also permit the configuration of a static (non > >>>>> dynamic) offset value (in microseconds) to be added to the > >measured > >>>> > >>>>> delay value before encoding into this TLV, to facilitate the > >>>>> communication of operator specific delay constraints. > >>>>> > >>>>> Similarly in 4.2.6. > >>>>> > >>>>> --- > >>>>> > >>>>> 4.2.7 appears out of sequence. But since it repeats the content of > >>>>> 4.2.4 I suggest you merge them and talk about the plurality of > >fields. > >>>>> > >>>>> --- > >>>>> > >>>>> Section 7 > >>>>> > >>>>> "Sections 6 and 7 provide" should be 5 and 6. > >>>>> > >>>>> --- > >>>>> > >>>>> Section 10 > >>>>> > >>>>> "As per (RFC3630), unrecognized TLVs should be silently ignored" > >>>>> > >>>>> There has been confusion about what 3630 means by "silently > >ignored". > >>>>> In particular, some enthusiastic implementations thought this meant > >>>> the > >>>>> TLVs should be stripped from the LSA before it is propagated. I > >think > >>>> it > >>>>> is worth the few words to explicitly state that this is not the > >case. > >>>>> > >>>>> --- > >>>>> > >>>>> Section 13 > >>>>> > >>>>> RFC 4203 is used in a normative way, please move it to the other > >>>>> section. > >>>>> > >>>>> > >>>>> > >>>> > >> > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Thu Dec 18 10:38:44 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26BD1A1B23 for ; Thu, 18 Dec 2014 10:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.367 X-Spam-Level: * X-Spam-Status: No, score=1.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_27=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUf6_W_Usuwk for ; Thu, 18 Dec 2014 10:38:36 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A501A6FE2 for ; Thu, 18 Dec 2014 10:38:36 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id i57so794410yha.26 for ; Thu, 18 Dec 2014 10:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=peo/U5DS5lKFIiHAs/7fJ1TdQCKSTaVYWv9vds9lNlg=; b=jIjzMIFw53Netk6II8IThvOT6q7BrUM+woRNygQGwxyOm5Ewcph2LzfXKd2EC5zcHu Ojhq2znXmbB/kVahYRP2UzJLnzRsKoMZhLuma+2Gmq6HBSOHXJ/n5BUcdKFG+bTwqWRw /YE1FKYaKSsdrXkjnUpI84SqdVZS+GXo21yz52AI2kWE7Z31IsxqioCPfHIW7YiMrAzn mARjjJqk2cHV4ZDTHzE2fYAb8+DpfhQPz+WH8thk1hBGTkB1l0jtvrCPvo1SJvYBMR0Z 6ctnz0+c7lrfn1zePlXsqKsE02s0BB4HOHjWfkE/mrYdP077FdZFYVHS9VZZ4DMgYEH0 nmbg== MIME-Version: 1.0 X-Received: by 10.170.128.207 with SMTP id u198mr3330566ykb.51.1418927915120; Thu, 18 Dec 2014 10:38:35 -0800 (PST) Received: by 10.170.136.132 with HTTP; Thu, 18 Dec 2014 10:38:34 -0800 (PST) In-Reply-To: <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> Date: Thu, 18 Dec 2014 13:38:34 -0500 Message-ID: From: Alia Atlas To: "t.petch" Content-Type: multipart/alternative; boundary=001a1139511c57bde2050a81e65d Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/mKZ_XRqxzWbZTOxH1pCKS9G5rf0 Cc: "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:38:40 -0000 --001a1139511c57bde2050a81e65d Content-Type: text/plain; charset=UTF-8 Tom, On Thu, Dec 18, 2014 at 1:05 PM, t.petch wrote: > > ----- Original Message ----- > From: "Alia Atlas" > To: > Sent: Thursday, December 18, 2014 4:28 PM > > > Are there routing YANG models that are running into concerns around > > floating point? > > Alia > > 24Apr14 netmod WG list Robert Varga > "while modeling some protocols (notably RSVP), we came across the need > to represent IEEE754-2008 floating types without losing precision. I'd > like > to ask what is the group's sentiment regarding extending the base types > with at least binary{32,64} (which have their counterparts in XML schema > datatypes)." > > which suggests that the answer is yes. > Indeed it does. Assuming these TE extensions are modeled, there'll be at least 4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE. > > I might have posed a slightly different question, such as - does > anyone outside a few on the netmod WG list realise that YANG has no > support for floating point, just decimal-64? > If they didn't before, they should be aware now. Alia > In passing, YANG did have floating point support in 2008/2009, which led > to Martin saying > > "Here's a proposal for solving our float problem, which is one of the > few remaining open issues in the YANG document. > I suggest we remove the float types, and instead replace them with a > fix point decimal type, much like xs:decimal. " > > which duly happened. Details in the archives. > > Interestingly, for me, this preceded the addition of floating point to > SMI with RFC6340 in August 2011; one of the arguments for removing > floating point from YANG was that SMI had never needed it in all its > years. > > Tom Petch > > > Regards, > > Alia > > > > ---------- Forwarded message ---------- > > From: Acee Lindem (acee) > > Date: Wed, Dec 17, 2014 at 7:30 PM > > Subject: Re: Last Call: > (OSPF > > Traffic Engineering (TE) Metric Extensions) to Proposed Standard > > To: "t.p." , "adrian@olddog.co.uk" < > > adrian@olddog.co.uk> > > Cc: "draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org" < > > draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>, > "ietf@ietf.org" < > > ietf@ietf.org> > > > > Tom, > > > > John Drake will update the reference in the OSPF TE Extensions draft. > I > > agree that YANG should have a corresponding common data type for > floating > > point since, for better or worse, RFC 2210 chose IEEE 32-bit floating > > point representation for bandwidth many years ago. > > > > Thanks, > > Acee > > > > On 12/17/14, 5:14 AM, "t.p." wrote: > > > > >Acee > > > > > >Sorry that my original comment was opaque. Partly, I was agreeing > with > > >Adrian that a reference to a floating point standard would be a good > > >idea, but disagreeing with Adrain about the particular standard, that > a > > >more recent one was available and had been used previously by an IETF > > >RFC. That part I hope is now clear, thanks to the clarifications by > > >others. > > > > > >My tangential comment was that YANG has no facility to model floating > > >point numbers, having looked at doing so and rejected it, several > times, > > >reckoning that the decimal-64, defined in RFC6020 section 9.3, is > > >adequate for network configuration. > > > > > >A consequence of this, which is understood, is that if you think of a > > >number, express it in YANG's decimal-64, convert it to floating point > > >because that is what XPath uses (and so is used by YANG's conditional > > >statements), convert it back to decimal-64 then you do not get the > > >number you first thought of (sometimes), so a test for equality will > > >fail, when you might expect it to succeed. > > > > > >Is this an issue? The consensus of the netmod WG (AFAICT) is that it > is > > >not, that the use of floating point in the IETF is minimal - after > all, > > >it took SNMP over 20 years to get round to specifying it. > > > > > >But given the explosion of interest in YANG recently, I think it is a > > >topic to keep an eye on so when I read an I-D and find floating > point, I > > >point{!} out that it cannot readily be modeled. I suspect that, in > this > > >case, consistency with what has gone before outweighs the facility to > do > > >it in YANG. > > > > > >Tom Petch > > > > > > > > >----- Original Message ----- > > >From: "Acee Lindem (acee)" > > >To: > > >Cc: "t.p." ; > > >; > > > > > >Sent: Monday, December 15, 2014 4:58 PM > > >Subject: Re: Last Call: > > >(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed > Standard > > > > > > > > >Hi Adrian, Tom, > > >Can you guys indicate how you would like to see this comment > reflected > > >in the draft? Are you suggesting to change he encoding to 64 bits for > > >the new bandwidth sub-TLVs? > > >Thanks, > > >Acee > > >On Dec 12, 2014, at 1:16 PM, Adrian Farrel > wrote: > > > > > >> Good catch Tom, > > >> > > >> Acee, the trick is to go to 6340 and look in the references :-) > > >> > > >> [IEEE.754.2008] Institute of Electrical and Electronics > Engineers, > > >> "Standard for Floating-Point Arithmetic", > > >> IEEE Standard 754, August 2008. > > >> > > >> A > > >> > > >>> -----Original Message----- > > >>> From: Acee Lindem (acee) [mailto:acee@cisco.com] > > >>> Sent: 12 December 2014 18:14 > > >>> To: t.p. > > >>> Cc: adrian@olddog.co.uk; > > >> draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org; > > >>> ietf@ietf.org > > >>> Subject: Re: Last Call: > > > >(OSPF > > >> Traffic > > >>> Engineering (TE) Metric Extensions) to Proposed Standard > > >>> > > >>> Hi Tom, > > >>> > > >>> On Dec 12, 2014, at 1:08 PM, t.p. wrote: > > >>> > > >>>> On the question of Floating-Point, there is now 754-2008, which > is a > > >>>> tighter spec and is used in RFC6340. > > >>> > > >>> What is 754-2008? > > >>> > > >>> Thanks, > > >>> Acee > > >>> > > >>> > > >>> > > >>>> > > >>>> At a tangent, the issue of floating-point support has surfaced a > > >number > > >>>> of times in YANG and, to date, has always been rejected, > reckoning > > >that > > >>>> suppport for 64-bit decimal is adequate for data modelling. The > > >>>> interactions with XPath (which is used as a basis for YANG > > >constraint > > >>>> statements), where floating-point is allowed, have caused a > number > > >of > > >>>> discussions, some ongoing, about the comparison of a > floating-point > > >>>> number to a 64-bit decimal one. Something to be aware of should > you > > >ever > > >>>> want to model this in YANG. > > >>>> > > >>>> Tom Petch > > >>>> > > >>>> > > >>>> ----- Original Message ----- > > >>>> From: "Adrian Farrel" > > >>>> To: > > >>>> Cc: ; > > >>>> Sent: Wednesday, December 10, 2014 11:07 PM > > >>>> > > >>>>> All, > > >>>>> > > >>>>> I reviewed this document as AD and found a few small points that > I > > >>>> have asked > > >>>>> the authors to address as IETF last call comments. > > >>>>> > > >>>>> Adrian > > >>>>> > > >>>>> === > > >>>>> > > >>>>> Please look for places where you have "proposed" something and > > >change > > >>>>> that to "defined". > > >>>>> > > >>>>> --- > > >>>>> > > >>>>> It would be good to include a reference for encoding floating > point > > >>>>> integers. The usual is (I think)... > > >>>>> > > >>>>> IEEE, "IEEE Standard for Binary Floating-Point > Arithmetic", > > >>>>> Standard 754-1985, 1985 (ISBN 1-5593-7653-8). > > >>>>> > > >>>>> --- > > >>>>> > > >>>>> Section 4.2.5 > > >>>>> > > >>>>> Implementations MAY also permit the configuration of a static > (non > > >>>>> dynamic) offset value (in microseconds) to be added to the > > >measured > > >>>>> delay value, to facilitate the communication of operator > specific > > >>>>> delay constraints. > > >>>>> > > >>>>> On the third reading I got it! I'm slow (I have a high delay :-) > > >>>>> > > >>>>> The point here is that the measured value and the static value > are > > >>>> added > > >>>>> together and the sum is transmitted in this field. I'd > suggest... > > >>>>> > > >>>>> Implementations MAY also permit the configuration of a static > (non > > >>>>> dynamic) offset value (in microseconds) to be added to the > > >measured > > >>>> > > >>>>> delay value before encoding into this TLV, to facilitate the > > >>>>> communication of operator specific delay constraints. > > >>>>> > > >>>>> Similarly in 4.2.6. > > >>>>> > > >>>>> --- > > >>>>> > > >>>>> 4.2.7 appears out of sequence. But since it repeats the content > of > > >>>>> 4.2.4 I suggest you merge them and talk about the plurality of > > >fields. > > >>>>> > > >>>>> --- > > >>>>> > > >>>>> Section 7 > > >>>>> > > >>>>> "Sections 6 and 7 provide" should be 5 and 6. > > >>>>> > > >>>>> --- > > >>>>> > > >>>>> Section 10 > > >>>>> > > >>>>> "As per (RFC3630), unrecognized TLVs should be silently > ignored" > > >>>>> > > >>>>> There has been confusion about what 3630 means by "silently > > >ignored". > > >>>>> In particular, some enthusiastic implementations thought this > meant > > >>>> the > > >>>>> TLVs should be stripped from the LSA before it is propagated. I > > >think > > >>>> it > > >>>>> is worth the few words to explicitly state that this is not the > > >case. > > >>>>> > > >>>>> --- > > >>>>> > > >>>>> Section 13 > > >>>>> > > >>>>> RFC 4203 is used in a normative way, please move it to the other > > >>>>> section. > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >> > > > > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > --001a1139511c57bde2050a81e65d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tom,

On Thu, Dec 18, 2014 at 1:05 PM, t.petch <ietfc@btconnect.com&g= t; wrote:

----- Original Message -----
From: "Alia Atlas" <akatl= as@gmail.com>
To: <Rtg-yang-coord@ietf.org<= /a>>
Sent: Thursday, December 18, 2014 4:28 PM

> Are there routing YANG models that are running into concerns around > floating point?

Alia

24Apr14 netmod WG list Robert Varga
"while modeling some protocols (notably RSVP), we came across the need=
to represent IEEE754-2008 floating types without losing precision. I'd<= br> like
to ask what is the group's sentiment regarding extending the base types=
with at least binary{32,64} (which have their counterparts in XML schema datatypes)."

which suggests that the answer is yes.


I might have posed a slightly different question, such as - does
anyone outside a few on the netmod WG list realise that YANG has no
support for floating point, just decimal-64?

If they didn't before, they should be aware now.=C2=A0
=
Alia
=C2=A0
In passing, YANG did have floating point support in 2008/2009, which led to Martin saying

"Here's a proposal for solving our float problem, which is one of = the
few remaining open issues in the YANG document.
I suggest we remove the float types, and instead replace them with a
fix point decimal type, much like xs:decimal. "

which duly happened.=C2=A0 Details in the archives.

Interestingly, for me, this preceded the addition of floating point to
SMI with RFC6340 in August 2011; one of the arguments for removing
floating point from YANG was that SMI had never needed it in all its
years.

Tom Petch

> Regards,
> Alia
>
> ---------- Forwarded message ----------
> From: Acee Lindem (acee) <acee@ci= sco.com>
> Date: Wed, Dec 17, 2014 at 7:30 PM
> Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.tx= t>
(OSPF
> Traffic Engineering (TE) Metric Extensions) to Proposed Standard
> To: "t.p." <dae= dulus@btconnect.com>, "a= drian@olddog.co.uk" <
> adrian@olddog.co.uk>
> Cc: "draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org&= quot; <
> draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>,
"ietf@ietf.org" <
> ietf@ietf.org>
>
> Tom,
>
> John Drake will update the reference in the OSPF TE Extensions draft.<= br> I
> agree that YANG should have a corresponding common data type for
floating
> point since, for better or worse, RFC 2210 chose IEEE 32-bit floating<= br> > point representation for bandwidth many years ago.
>
> Thanks,
> Acee
>
> On 12/17/14, 5:14 AM, "t.p." <daedulus@btconnect.com> wrote:
>
> >Acee
> >
> >Sorry that my original comment was opaque.=C2=A0 =C2=A0Partly, I w= as agreeing
with
> >Adrian that a reference to a floating point standard would be a go= od
> >idea, but disagreeing with Adrain about the particular standard, t= hat
a
> >more recent one was available and had been used previously by an I= ETF
> >RFC.=C2=A0 That part I hope is now clear, thanks to the clarificat= ions by
> >others.
> >
> >My tangential comment was that YANG has no facility to model float= ing
> >point numbers, having looked at doing so and rejected it, several<= br> times,
> >reckoning that the decimal-64, defined in RFC6020 section 9.3, is<= br> > >adequate for network configuration.
> >
> >A consequence of this, which is understood, is that if you think o= f a
> >number, express it in YANG's decimal-64, convert it to floatin= g point
> >because that is what XPath uses (and so is used by YANG's cond= itional
> >statements), convert it back to decimal-64 then you do not get the=
> >number you first thought of (sometimes), so a test for equality wi= ll
> >fail, when you might expect it to succeed.
> >
> >Is this an issue?=C2=A0 The consensus of the netmod WG (AFAICT) is= that it
is
> >not, that the use of floating point in the IETF is minimal - after=
all,
> >it took SNMP over 20 years to get round to specifying it.
> >
> >But given the explosion of interest in YANG recently, I think it i= s a
> >topic to keep an eye on so when I read an I-D and find floating point, I
> >point{!} out that it cannot readily be modeled.=C2=A0 I suspect th= at, in
this
> >case, consistency with what has gone before outweighs the facility= to
do
> >it in YANG.
> >
> >Tom Petch
> >
> >
> >----- Original Message -----
> >From: "Acee Lindem (acee)" <acee@cisco.com>
> >To: <adrian@olddog.co.uk= >
> >Cc: "t.p." <daedulus@btconnect.com>;
> ><draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>= ;;
> ><ietf@ietf.org>
> >Sent: Monday, December 15, 2014 4:58 PM
> >Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-0= 8.txt>
> >(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed
Standard
> >
> >
> >Hi Adrian, Tom,
> >Can you guys indicate how you would like to see this comment
reflected
> >in the draft? Are you suggesting to change he encoding to 64 bits = for
> >the new bandwidth sub-TLVs?
> >Thanks,
> >Acee
> >On Dec 12, 2014, at 1:16 PM, Adrian Farrel <adrian@olddog.co.uk>
wrote:
> >
> >> Good catch Tom,
> >>
> >> Acee, the trick is to go to 6340 and look in the references := -)
> >>
> >>=C2=A0 =C2=A0[IEEE.754.2008]=C2=A0 Institute of Electrical and= Electronics
Engineers,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 "Standard for Floating-Point Arithmetic",
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 IEEE Standard 754, August 2008.
> >>
> >> A
> >>
> >>> -----Original Message-----
> >>> From: Acee Lindem (acee) [mailto:acee@cisco.com]
> >>> Sent: 12 December 2014 18:14
> >>> To: t.p.
> >>> Cc: adrian@olddog.= co.uk;
> >> draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org;<= br> > >>> ietf@ietf.org
> >>> Subject: Re: Last Call:
<draft-ietf-ospf-te-metric-extensions-08.txt>
> >(OSPF
> >> Traffic
> >>> Engineering (TE) Metric Extensions) to Proposed Standard<= br> > >>>
> >>> Hi Tom,
> >>>
> >>> On Dec 12, 2014, at 1:08 PM, t.p. <daedulus@btconnect.com> wrote:
> >>>
> >>>> On the question of Floating-Point, there is now 754-2= 008, which
is a
> >>>> tighter spec and is used in RFC6340.
> >>>
> >>> What is 754-2008?
> >>>
> >>> Thanks,
> >>> Acee
> >>>
> >>>
> >>>
> >>>>
> >>>> At a tangent, the issue of floating-point support has= surfaced a
> >number
> >>>> of times in YANG and, to date, has always been reject= ed,
reckoning
> >that
> >>>> suppport for 64-bit decimal is adequate for data mode= lling.=C2=A0 The
> >>>> interactions with XPath (which is used as a basis for= YANG
> >constraint
> >>>> statements), where floating-point is allowed, have ca= used a
number
> >of
> >>>> discussions, some ongoing, about the comparison of a<= br> floating-point
> >>>> number to a 64-bit decimal one. Something to be aware= of should
you
> >ever
> >>>> want to model this in YANG.
> >>>>
> >>>> Tom Petch
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Adrian Farrel" <adrian@olddog.co.uk>
> >>>> To: <draft-ietf-ospf-te-metric-extensions.all@tool= s.ietf.org>
> >>>> Cc: <ospf@ietf.or= g>; <ietf@ietf.org>
> >>>> Sent: Wednesday, December 10, 2014 11:07 PM
> >>>>
> >>>>> All,
> >>>>>
> >>>>> I reviewed this document as AD and found a few sm= all points that
I
> >>>> have asked
> >>>>> the authors to address as IETF last call comments= .
> >>>>>
> >>>>> Adrian
> >>>>>
> >>>>> =3D=3D=3D
> >>>>>
> >>>>> Please look for places where you have "propo= sed" something and
> >change
> >>>>> that to "defined".
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> It would be good to include a reference for encod= ing floating
point
> >>>>> integers. The usual is (I think)...
> >>>>>
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0IEEE, "IEEE Standa= rd for Binary Floating-Point
Arithmetic",
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Standard 754-1985, 1985= (ISBN 1-5593-7653-8).
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> Section 4.2.5
> >>>>>
> >>>>>=C2=A0 Implementations MAY also permit the configu= ration of a static
(non
> >>>>>=C2=A0 dynamic) offset value (in microseconds) to = be added to the
> >measured
> >>>>>=C2=A0 delay value, to facilitate the communicatio= n of operator
specific
> >>>>>=C2=A0 delay constraints.
> >>>>>
> >>>>> On the third reading I got it! I'm slow (I ha= ve a high delay :-)
> >>>>>
> >>>>> The point here is that the measured value and the= static value
are
> >>>> added
> >>>>> together and the sum is transmitted in this field= . I'd
suggest...
> >>>>>
> >>>>>=C2=A0 Implementations MAY also permit the configu= ration of a static
(non
> >>>>>=C2=A0 dynamic) offset value (in microseconds) to = be added to the
> >measured
> >>>>
> >>>>>=C2=A0 delay value before encoding into this TLV, = to facilitate the
> >>>>>=C2=A0 communication of operator specific delay co= nstraints.
> >>>>>
> >>>>> Similarly in 4.2.6.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> 4.2.7 appears out of sequence. But since it repea= ts the content
of
> >>>>> 4.2.4 I suggest you merge them and talk about the= plurality of
> >fields.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> Section 7
> >>>>>
> >>>>> "Sections 6 and 7 provide" should be 5 = and 6.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> Section 10
> >>>>>
> >>>>>=C2=A0 "As per (RFC3630), unrecognized TLVs s= hould be silently
ignored"
> >>>>>
> >>>>> There has been confusion about what 3630 means by= "silently
> >ignored".
> >>>>> In particular, some enthusiastic implementations = thought this
meant
> >>>> the
> >>>>> TLVs should be stripped from the LSA before it is= propagated. I
> >think
> >>>> it
> >>>>> is worth the few words to explicitly state that t= his is not the
> >case.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> Section 13
> >>>>>
> >>>>> RFC 4203 is used in a normative way, please move = it to the other
> >>>>> section.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >
>


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


> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org=
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>


--001a1139511c57bde2050a81e65d-- From nobody Thu Dec 18 10:49:50 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203D71A1B57 for ; Thu, 18 Dec 2014 10:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.387 X-Spam-Level: * X-Spam-Status: No, score=1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHgq6CdFeLq0 for ; Thu, 18 Dec 2014 10:49:45 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467FB1A016A for ; Thu, 18 Dec 2014 10:49:45 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so1655024lbj.9 for ; Thu, 18 Dec 2014 10:49:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4T/oZ7bGsuejzulOYY78Vehccsd7keDga6YL69yEf4M=; b=gKSEyrSr96WVv5oott/pwrPfXfB9Ar96eWTOAylWDrAcBGSwdcy5UjvitHUQDsWp8u QLZxzBH5GW0v0PyHI7RqGwQM+rWK8XiXf3qZQEbv8xz2kzpbb/kYghkgUNsPqnecn2CX 2prhScyvYdV1OLeXTUY7iliVjYZpDdNUnbj5ARmrj0mqNBzlUFlsARy6+TqroxYe8FLD UD0slsVzFWlg8n1US442VwFrffQl6Z1k91IKQ51ro2PUu0XP165Eqf7FMjjtcBTNc7J2 9ihcIIhyOx6gDPL2aOYlB33hy0chzGR14SAB6zX0GddF4zO6PLmG5QTxx0BVV7oSOJ3O U/bA== X-Gm-Message-State: ALoCoQm8vEIiYNHGLF9Onh9Rd6P5Dm8if/TfdbS5ZVpDoCIUX2QNC/amcx0c31cNpdd2cUAkWkHV MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr3787824lac.3.1418928583823; Thu, 18 Dec 2014 10:49:43 -0800 (PST) Received: by 10.112.157.233 with HTTP; Thu, 18 Dec 2014 10:49:43 -0800 (PST) In-Reply-To: References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> Date: Thu, 18 Dec 2014 10:49:43 -0800 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/RE0pj6cKY-KUlHyXCk3EtKXKaGU Cc: "Rtg-yang-coord@ietf.org" , "t.petch" Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:49:48 -0000 On Thu, Dec 18, 2014 at 10:38 AM, Alia Atlas wrote: > Tom, > > On Thu, Dec 18, 2014 at 1:05 PM, t.petch wrote: >> >> >> ----- Original Message ----- >> From: "Alia Atlas" >> To: >> Sent: Thursday, December 18, 2014 4:28 PM >> >> > Are there routing YANG models that are running into concerns around >> > floating point? >> >> Alia >> >> 24Apr14 netmod WG list Robert Varga >> "while modeling some protocols (notably RSVP), we came across the need >> to represent IEEE754-2008 floating types without losing precision. I'd >> like >> to ask what is the group's sentiment regarding extending the base types >> with at least binary{32,64} (which have their counterparts in XML schema >> datatypes)." >> >> which suggests that the answer is yes. > > > Indeed it does. Assuming these TE extensions are modeled, there'll be at > least > 4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE. >> >> >> I might have posed a slightly different question, such as - does >> anyone outside a few on the netmod WG list realise that YANG has no >> support for floating point, just decimal-64? > > > If they didn't before, they should be aware now. > I think some vendors objected to mandatory support for floating point since not all their platforms supported it. Rather than have an optional base type, it was removed. You might have to define a string-based typedef for encoding float32 or float64. > Alia > Andy >> >> In passing, YANG did have floating point support in 2008/2009, which led >> to Martin saying >> >> "Here's a proposal for solving our float problem, which is one of the >> few remaining open issues in the YANG document. >> I suggest we remove the float types, and instead replace them with a >> fix point decimal type, much like xs:decimal. " >> >> which duly happened. Details in the archives. >> >> Interestingly, for me, this preceded the addition of floating point to >> SMI with RFC6340 in August 2011; one of the arguments for removing >> floating point from YANG was that SMI had never needed it in all its >> years. >> >> Tom Petch >> >> > Regards, >> > Alia >> > >> > ---------- Forwarded message ---------- >> > From: Acee Lindem (acee) >> > Date: Wed, Dec 17, 2014 at 7:30 PM >> > Subject: Re: Last Call: >> (OSPF >> > Traffic Engineering (TE) Metric Extensions) to Proposed Standard >> > To: "t.p." , "adrian@olddog.co.uk" < >> > adrian@olddog.co.uk> >> > Cc: "draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org" < >> > draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>, >> "ietf@ietf.org" < >> > ietf@ietf.org> >> > >> > Tom, >> > >> > John Drake will update the reference in the OSPF TE Extensions draft. >> I >> > agree that YANG should have a corresponding common data type for >> floating >> > point since, for better or worse, RFC 2210 chose IEEE 32-bit floating >> > point representation for bandwidth many years ago. >> > >> > Thanks, >> > Acee >> > >> > On 12/17/14, 5:14 AM, "t.p." wrote: >> > >> > >Acee >> > > >> > >Sorry that my original comment was opaque. Partly, I was agreeing >> with >> > >Adrian that a reference to a floating point standard would be a good >> > >idea, but disagreeing with Adrain about the particular standard, that >> a >> > >more recent one was available and had been used previously by an IETF >> > >RFC. That part I hope is now clear, thanks to the clarifications by >> > >others. >> > > >> > >My tangential comment was that YANG has no facility to model floating >> > >point numbers, having looked at doing so and rejected it, several >> times, >> > >reckoning that the decimal-64, defined in RFC6020 section 9.3, is >> > >adequate for network configuration. >> > > >> > >A consequence of this, which is understood, is that if you think of a >> > >number, express it in YANG's decimal-64, convert it to floating point >> > >because that is what XPath uses (and so is used by YANG's conditional >> > >statements), convert it back to decimal-64 then you do not get the >> > >number you first thought of (sometimes), so a test for equality will >> > >fail, when you might expect it to succeed. >> > > >> > >Is this an issue? The consensus of the netmod WG (AFAICT) is that it >> is >> > >not, that the use of floating point in the IETF is minimal - after >> all, >> > >it took SNMP over 20 years to get round to specifying it. >> > > >> > >But given the explosion of interest in YANG recently, I think it is a >> > >topic to keep an eye on so when I read an I-D and find floating >> point, I >> > >point{!} out that it cannot readily be modeled. I suspect that, in >> this >> > >case, consistency with what has gone before outweighs the facility to >> do >> > >it in YANG. >> > > >> > >Tom Petch >> > > >> > > >> > >----- Original Message ----- >> > >From: "Acee Lindem (acee)" >> > >To: >> > >Cc: "t.p." ; >> > >; >> > > >> > >Sent: Monday, December 15, 2014 4:58 PM >> > >Subject: Re: Last Call: >> > >(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed >> Standard >> > > >> > > >> > >Hi Adrian, Tom, >> > >Can you guys indicate how you would like to see this comment >> reflected >> > >in the draft? Are you suggesting to change he encoding to 64 bits for >> > >the new bandwidth sub-TLVs? >> > >Thanks, >> > >Acee >> > >On Dec 12, 2014, at 1:16 PM, Adrian Farrel >> wrote: >> > > >> > >> Good catch Tom, >> > >> >> > >> Acee, the trick is to go to 6340 and look in the references :-) >> > >> >> > >> [IEEE.754.2008] Institute of Electrical and Electronics >> Engineers, >> > >> "Standard for Floating-Point Arithmetic", >> > >> IEEE Standard 754, August 2008. >> > >> >> > >> A >> > >> >> > >>> -----Original Message----- >> > >>> From: Acee Lindem (acee) [mailto:acee@cisco.com] >> > >>> Sent: 12 December 2014 18:14 >> > >>> To: t.p. >> > >>> Cc: adrian@olddog.co.uk; >> > >> draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org; >> > >>> ietf@ietf.org >> > >>> Subject: Re: Last Call: >> >> > >(OSPF >> > >> Traffic >> > >>> Engineering (TE) Metric Extensions) to Proposed Standard >> > >>> >> > >>> Hi Tom, >> > >>> >> > >>> On Dec 12, 2014, at 1:08 PM, t.p. wrote: >> > >>> >> > >>>> On the question of Floating-Point, there is now 754-2008, which >> is a >> > >>>> tighter spec and is used in RFC6340. >> > >>> >> > >>> What is 754-2008? >> > >>> >> > >>> Thanks, >> > >>> Acee >> > >>> >> > >>> >> > >>> >> > >>>> >> > >>>> At a tangent, the issue of floating-point support has surfaced a >> > >number >> > >>>> of times in YANG and, to date, has always been rejected, >> reckoning >> > >that >> > >>>> suppport for 64-bit decimal is adequate for data modelling. The >> > >>>> interactions with XPath (which is used as a basis for YANG >> > >constraint >> > >>>> statements), where floating-point is allowed, have caused a >> number >> > >of >> > >>>> discussions, some ongoing, about the comparison of a >> floating-point >> > >>>> number to a 64-bit decimal one. Something to be aware of should >> you >> > >ever >> > >>>> want to model this in YANG. >> > >>>> >> > >>>> Tom Petch >> > >>>> >> > >>>> >> > >>>> ----- Original Message ----- >> > >>>> From: "Adrian Farrel" >> > >>>> To: >> > >>>> Cc: ; >> > >>>> Sent: Wednesday, December 10, 2014 11:07 PM >> > >>>> >> > >>>>> All, >> > >>>>> >> > >>>>> I reviewed this document as AD and found a few small points that >> I >> > >>>> have asked >> > >>>>> the authors to address as IETF last call comments. >> > >>>>> >> > >>>>> Adrian >> > >>>>> >> > >>>>> === >> > >>>>> >> > >>>>> Please look for places where you have "proposed" something and >> > >change >> > >>>>> that to "defined". >> > >>>>> >> > >>>>> --- >> > >>>>> >> > >>>>> It would be good to include a reference for encoding floating >> point >> > >>>>> integers. The usual is (I think)... >> > >>>>> >> > >>>>> IEEE, "IEEE Standard for Binary Floating-Point >> Arithmetic", >> > >>>>> Standard 754-1985, 1985 (ISBN 1-5593-7653-8). >> > >>>>> >> > >>>>> --- >> > >>>>> >> > >>>>> Section 4.2.5 >> > >>>>> >> > >>>>> Implementations MAY also permit the configuration of a static >> (non >> > >>>>> dynamic) offset value (in microseconds) to be added to the >> > >measured >> > >>>>> delay value, to facilitate the communication of operator >> specific >> > >>>>> delay constraints. >> > >>>>> >> > >>>>> On the third reading I got it! I'm slow (I have a high delay :-) >> > >>>>> >> > >>>>> The point here is that the measured value and the static value >> are >> > >>>> added >> > >>>>> together and the sum is transmitted in this field. I'd >> suggest... >> > >>>>> >> > >>>>> Implementations MAY also permit the configuration of a static >> (non >> > >>>>> dynamic) offset value (in microseconds) to be added to the >> > >measured >> > >>>> >> > >>>>> delay value before encoding into this TLV, to facilitate the >> > >>>>> communication of operator specific delay constraints. >> > >>>>> >> > >>>>> Similarly in 4.2.6. >> > >>>>> >> > >>>>> --- >> > >>>>> >> > >>>>> 4.2.7 appears out of sequence. But since it repeats the content >> of >> > >>>>> 4.2.4 I suggest you merge them and talk about the plurality of >> > >fields. >> > >>>>> >> > >>>>> --- >> > >>>>> >> > >>>>> Section 7 >> > >>>>> >> > >>>>> "Sections 6 and 7 provide" should be 5 and 6. >> > >>>>> >> > >>>>> --- >> > >>>>> >> > >>>>> Section 10 >> > >>>>> >> > >>>>> "As per (RFC3630), unrecognized TLVs should be silently >> ignored" >> > >>>>> >> > >>>>> There has been confusion about what 3630 means by "silently >> > >ignored". >> > >>>>> In particular, some enthusiastic implementations thought this >> meant >> > >>>> the >> > >>>>> TLVs should be stripped from the LSA before it is propagated. I >> > >think >> > >>>> it >> > >>>>> is worth the few words to explicitly state that this is not the >> > >case. >> > >>>>> >> > >>>>> --- >> > >>>>> >> > >>>>> Section 13 >> > >>>>> >> > >>>>> RFC 4203 is used in a normative way, please move it to the other >> > >>>>> section. >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>> >> > >> >> > > >> > >> >> >> ------------------------------------------------------------------------ >> -------- >> >> >> > _______________________________________________ >> > Rtg-yang-coord mailing list >> > Rtg-yang-coord@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> > >> > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Thu Dec 18 10:53:12 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BD41A8F44 for ; Thu, 18 Dec 2014 10:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aC8syrSjF7z for ; Thu, 18 Dec 2014 10:53:09 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD4C1A8F4B for ; Thu, 18 Dec 2014 10:53:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8B7B9A7F; Thu, 18 Dec 2014 19:53:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id p6gBSTNxUtGt; Thu, 18 Dec 2014 19:53:04 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 18 Dec 2014 19:53:06 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA0FB2002C; Thu, 18 Dec 2014 19:53:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D5ZfZdRfkZO1; Thu, 18 Dec 2014 19:53: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 F23E720017; Thu, 18 Dec 2014 19:53:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 47FED300FDB2; Thu, 18 Dec 2014 19:53:05 +0100 (CET) Date: Thu, 18 Dec 2014 19:53:04 +0100 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20141218185304.GA28738@elstar.local> Mail-Followup-To: "t. petch" , Alia Atlas , Rtg-yang-coord@ietf.org References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/VLZDAQxK2rDt9M4y3A94j0qtV4s Cc: Rtg-yang-coord@ietf.org, Alia Atlas Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 18:53:10 -0000 On Thu, Dec 18, 2014 at 06:05:43PM +0000, t. petch wrote: > > Interestingly, for me, this preceded the addition of floating point to > SMI with RFC6340 in August 2011; one of the arguments for removing > floating point from YANG was that SMI had never needed it in all its > years. > I think the following questions are important: a) Does network gear use floating point arithmetic internally in their implementations or are numbers just represented as floating point numbers but internally treated as fixed poined anyway? b) Is the large range that is possible using floating point numbers needed or desirable? It is instructive to see how FLOAT-TC-MIB is used. In some cases, it is modeling a quality number between 0 and 1. Is IEEE floating point needed for that? In other cases, they are used to model bandwidth. Again, are IEEE floating point numbers needed for that? If we would model link distances between integrated circuits and between planets in different galaxies, then a floating point type may make a lot of sense. /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 18 17:57:32 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0406B1A7005 for ; Thu, 18 Dec 2014 17:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.434 X-Spam-Level: X-Spam-Status: No, score=-100.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwrmOjQpVFYM for ; Thu, 18 Dec 2014 17:57:29 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122671A87AF for ; Thu, 18 Dec 2014 17:57:29 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so72865qcy.32 for ; Thu, 18 Dec 2014 17:57:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=C8NrHtiaSt4EewclTjdOH5nXpwgpo5YSRgXm5FDbL3o=; b=XJ/5ufaHZgrd2+289k26sFnAOoFUE7cBIOsju52Djy1Ykat5BtZ4w/omM5uJrNJC// mZj5XeZG3+sKRLGj8nO0lvWJJF2MOr1VlM5jCpV0ec5hMLnNT5BkuE0gcSafkKT+7Bk8 uEDMKhb/icbpc7EHnG3UQ1y6VEetskDF+X2SICNC8TewWmSJMj+rMBeAywHemN7Z4SKz RC3NqDNZMN5jcldfeDLpuvoBXby0NnOUoy4wbPK8PLfFV8JoAvs7S5OBQUFwnNIeSREs coPskm52DJ9eUK5aBuMBlbmWDgIFUk5yVsjdkZIJLckqe1lxpr2vecoc2Kf3K3Q1vAAa tR9A== X-Gm-Message-State: ALoCoQly8DCc431RqtsNGvhOrhH4KBvO2JbQ24HBrCA4YWTh97dJwEZ/Jckpa+atdJX/sTRj3ByI X-Received: by 10.224.50.75 with SMTP id y11mr9587580qaf.89.1418954248348; Thu, 18 Dec 2014 17:57:28 -0800 (PST) Received: from [10.235.8.202] (mobile-166-171-056-009.mycingular.net. [166.171.56.9]) by mx.google.com with ESMTPSA id z17sm8388981qge.44.2014.12.18.17.57.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 17:57:26 -0800 (PST) References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <20141218185304.GA28738@elstar.local> Mime-Version: 1.0 (1.0) In-Reply-To: <20141218185304.GA28738@elstar.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <21B14005-4E83-4E0A-B6D0-8F7563555DAD@fenron.com> X-Mailer: iPhone Mail (12B440) From: Bill Fenner Date: Thu, 18 Dec 2014 20:57:24 -0500 To: Juergen Schoenwaelder Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/lNVIuoCBiFQy_Xo_N5hxFjz3W7I Cc: "Rtg-yang-coord@ietf.org" , "t. petch" , Alia Atlas Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 01:57:30 -0000 > On Dec 18, 2014, at 1:53 PM, Juergen Schoenwaelder wrote: >=20 >> On Thu, Dec 18, 2014 at 06:05:43PM +0000, t. petch wrote: >>=20 >> Interestingly, for me, this preceded the addition of floating point to >> SMI with RFC6340 in August 2011; one of the arguments for removing >> floating point from YANG was that SMI had never needed it in all its >> years. >=20 > I think the following questions are important: >=20 > a) Does network gear use floating point arithmetic internally in their > implementations or are numbers just represented as floating point > numbers but internally treated as fixed poined anyway? We use floating point extensively, including for TimeTicks where fixed point= would do. Turns out that you don't need a floating-point co-processor any m= ore when you are designing systems with modern CPUs. Bill From nobody Fri Dec 19 02:04:00 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6540D1A6F3A for ; Fri, 19 Dec 2014 02:03:57 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFSujjTL6-LM for ; Fri, 19 Dec 2014 02:03:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F211A6F3B for ; Fri, 19 Dec 2014 02:03:54 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8F63332541A; Fri, 19 Dec 2014 11:03:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6537B27C0D0; Fri, 19 Dec 2014 11:03:52 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0210.002; Fri, 19 Dec 2014 11:03:52 +0100 From: To: Robert Raszuk , Jeff Tantsura Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4A== Date: Fri, 19 Dec 2014 10:03:51 +0000 Message-ID: <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/K7eM6bFJphjYW5otTPhdn1BvYiE Cc: "rtg-yang-coord@ietf.org" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:03:57 -0000 SGksDQoNCkkgdGhpbmsgd29ya2luZyBvZiBCR1AgWUFORyBpcyBhIGdvb2Qgb3Bwb3J0dW5pdHkg dG8gc3RhcnQgd29ya2luZyBvbiBwb2xpY3kgZnJhbWV3b3JrLg0KV29yayBvbiBwcm90b2NvbHMg WUFORyBpcyBhbHJlYWR5IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWcgZGlzcHJlY2FuY2llcywg SSBleHBlY3QgcG9saWN5IHdvcmsgdG8gYmUgbXVjaCBoYXJkZXIgLi4uDQoNCkJ1dCBJIHRoaW5r LCB0aGVyZSBpcyBhbiBvcHBvcnR1bml0eSB0byBzdGFydCBzb21ldGhpbmcgbmV3IGZvciBldmVy eW9uZSAodGhhdCBtYXkgY29leGlzdCB3aXRoIGV4aXN0aW5nIENMSSBwb2xpY2llcykgYW5kIG5v dCBsb29raW5nIGF0IENMSSB0cmFuc2xhdGlvbiAoaXQgd2lsbCBiZSBpbXBvc3NpYmxlIHdpdGgg cG9saWNpZXMpLiBUaGVuIGl0IHdvdWxkIGJlIHVwIHRvIHNlcnZpY2UgcHJvdmlkZXJzIHRvIHJl cXVlc3QgdGhlIHN1cHBvcnQgb2YgdGhpcyBieSB0aGVpciBmYXZvcml0ZSB2ZW5kb3JzLg0KDQpC ZXN0IFJlZ2FyZHMsDQoNClN0ZXBoYW5lDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJl aGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE3LCAyMDE0 IDIzOjI4DQpUbzogSmVmZiBUYW50c3VyYQ0KQ2M6IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBC b2dkYW5vdmljOyBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgTElUS09XU0tJIFN0ZXBoYW5lIFND RS9JQk5GOyBMYWRpc2xhdiBMaG90a2ENClN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlz c3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCg0KU28gYXJlIHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwg WUFORyBzcGVjaWZpY2F0aW9uIHNheSBmb3IgQkdQIGJ5IGRlc2lnbiB3aWxsIG5vdCBiZSBjb21w YXRpYmxlIHdpdGggc29tZSBpbXBsZW1lbnRhdGlvbnMgPw0KDQpPciBhcmUgeW91IHNheWluZyB0 aGF0IGZvcm1hbCBkZXNpZ24gc2F5IG9mIEJHUCBwcm90b2NvbCB3aWxsIGhhdmUgdG8gd2FpdCBm ZXcgeWVhcnMgdGlsbCBZQU5HIGZvciBwb2xpY3kgc3BlYyBpcyBjb21wbGV0ZSA/DQoNCkNoZWVy cywNCnIuDQoNCk9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDExOjE0IFBNLCBKZWZmIFRhbnRzdXJh IDxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IFllcywgZXhhY3RseSwgUm9i ZXJ0IC0gdGhlIGJlaGF2aW9yIHlvdSBoYXZlIGRlc2NyaWJlZCBpcyBhbiBpbXBsZW1lbnRhdGlv biwgbm90IGEgZm9ybWFsIHNwZWNpZmljYXRpb24uDQo+DQo+IFJlZ2FyZHMsDQo+IEplZmYNCj4N Cj4+IE9uIERlYyAxNywgMjAxNCwgYXQgMjoxMiBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2Vl QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pg0KPj4gV2h5IGlzIHRoaXMgYSBwcm9ibGVtIGlmIHRoZSBk ZWZhdWx0IGlzIHRvIG5vdCB0byByZWRpc3RyaWJ1dGUgcm91dGVzIGJldHdlZW4gUklCcz8gTm90 ZSB0aGF0IGl0IGlzbuKAmXQgbGlrZSB3ZSBoYXZlIGEgc2V0IG9mIGFwcHJvdmVkIHJvdXRpbmcg cHJvdG9jb2wgbW9kZWxzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiB0aGlzIGJlaGF2aW9yLg0KPj4g QWNlZQ0KPj4NCj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDU6MDcgUE0sIERlYW4gQm9nZGFub3Zp YyA8ZGVhbmJAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+DQo+Pj4gUm9iZXJ0LA0KPj4+DQo+Pj4g WW91ciBwcm9wb3NhbCBpcyB2ZXJ5IHNlbnNpYmxlIGFuZCBJIHRoaW5rIHRoaXMgaXMgdGhlIGJl c3Qgb3B0aW9uDQo+Pj4NCj4+PiBEZWFuDQo+Pj4NCj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCA0 OjQ5IFBNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4gd3JvdGU6DQo+Pj4+DQo+ Pj4+IERlYW4sIGFsbA0KPj4+Pg0KPj4+PiBUaGUgd2F5IEkgcmVhZCBpdCBjdXJyZW50bHkgaW4g c2VjdGlvbiA1LjUgdGhlcmUgYXJlIG9ubHkgdHdvIHJvdXRlIA0KPj4+PiBmaWx0ZXJzIHByb3Bv c2VkIChkZW55LWFsbCBvciBhbGxvdy1hbGwpLiBBcyB3ZSBrbm93IHNvbWUgcm91dGluZyANCj4+ Pj4gcHJvdG9jb2xzIHJlcXVpcmUgZXhwbGljaXQgcGVybWlzc2lvbiB0byBvcGVyYXRlIChleGFt cGxlOiBFQkdQKS4gDQo+Pj4+IElmIHdlIHJlbW92ZSBldmVuIHRob3NlIHR3byBwcmltaXRpdmUg ZmlsdGVycyB0aGVyZSBjYW4gYmUgaW1wYWN0IA0KPj4+PiB0byBvdGhlciBjb21wb25lbnRzLg0K Pj4+Pg0KPj4+PiBCdXQgSSBkbyBzdXBwb3J0IGEgc2VwYXJhdGUgd29yayBmb3IgWUFORyBtb2Rl bCBmb3IgcG9saWN5LiBJIGRvIA0KPj4+PiBleHBlY3QgdGhpcyB0byBiZSBhIHZlcnkgaW50ZXJl c3RpbmcgYW5kIGludm9sdmVkIHdvcmsgY29uc2lkZXJpbmcgDQo+Pj4+IHNpZ25pZmljYW50IGRp dmVyc2l0eSBvZiBwb2xpY3kgbGFuZ3VhZ2VzIGFjcm9zcyBhbGwgDQo+Pj4+IGltcGxlbWVudGF0 aW9ucyB0b2RheS4NCj4+Pj4NCj4+Pj4gT25jZSB0aGF0IHdvcmsgaXMgZG9uZSB3ZSBjb3VsZCBy ZXRpcmUgc2VjdGlvbiA1LjUgb2YgDQo+Pj4+ICotbmV0bW9kLXJvdXRpbmctKg0KPj4+Pg0KPj4+ PiBSZWdhcmRzLA0KPj4+PiByLg0KPj4+Pg0KPj4+Pg0KPj4+Pj4gT24gV2VkLCBEZWMgMTcsIDIw MTQgYXQgMTA6MDkgUE0sIERlYW4gQm9nZGFub3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ+IHdyb3Rl Og0KPj4+Pj4gSSdtIGluIHN1cHBvcnQgb2YgcmVtb3Zpbmcgcm91dGUgZmlsdGVycyBmcm9tIHRo ZSByb3V0aW5nIGNmZyBtb2RlbC4gUm91dGUgZmlsdGVycyBzaG91bGQgYmUgSU1PIHBhcnQgb2Yg dGhlIHBvbGljeSBtb2RlbCwgaW4gd2hpY2ggYWxzbyBBQ0wgbW9kZWwgYmVsb25ncyB0b28uIEFj dHVhbGx5LCBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkg c3VpdGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuDQo+Pj4+Pg0KPj4+Pj4gRGVhbg0KPj4+DQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBSdGct eWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4+ DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Fri Dec 19 02:10:16 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E981A6F62 for ; Fri, 19 Dec 2014 02:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRtQx-CxWruz for ; Fri, 19 Dec 2014 02:10:13 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCDC1A6F59 for ; Fri, 19 Dec 2014 02:10:13 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id hl2so407669igb.5 for ; Fri, 19 Dec 2014 02:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=CIsbOBpE4wwGOQ7pfkiO60snRJG+e2wv9JhjuhzpRYM=; b=ApsL/P2nPY9hcLG1gP5tg8bw6L2mDvj1oRN1kV2P6V05yZtyN1aZ7T2QMph4ga6ZHp ROE/wJl+amkYtJN8VSx8j8bH4g7R8mj4M1lo4YbJPT+mBNUlthcFSXjgLMjvOeVOug7T 2OpLIromYrvfCTg89mSrrb8uMeZniNH+CqCULMxiCRrDAeBKI0uA3ZHy+O7aQAyKYq64 JIFXmtX19VMV/4Pixjgf2p9r7bf+zA4Ptlj/n1/dss9sld07F+f1uzKS9bPefNtMogts r3BUjpAJQYvvn2Wsg7HMCORAR02fsz8qnETIUTFyCF+SJ/o89XLWbmwz2BIISB2JB+a8 lC+w== MIME-Version: 1.0 X-Received: by 10.50.171.168 with SMTP id av8mr2143585igc.2.1418983812384; Fri, 19 Dec 2014 02:10:12 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.152.130 with HTTP; Fri, 19 Dec 2014 02:10:12 -0800 (PST) In-Reply-To: <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Fri, 19 Dec 2014 11:10:12 +0100 X-Google-Sender-Auth: _BQm8HTO2J3jlGdoEUCnG53O-EU Message-ID: From: Robert Raszuk To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/96XaN2r772PHiHUPCobt0y1KpjQ Cc: "rtg-yang-coord@ietf.org" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:10:15 -0000 Hi Stephane, That is going to be very interesting indeed. Considering that number of customers have paid vendors millions for customized extensions and only some of them made it to IETF drafts/rfcs. So what will most likely happen is general YANG model of not much use and zoo of proprietary vendor YANG extensions not compatible between implementations. Is this really where we want to go with this entire effort ? Best, r. On Fri, Dec 19, 2014 at 11:03 AM, wrote: > Hi, > > I think working of BGP YANG is a good opportunity to start working on pol= icy framework. > Work on protocols YANG is already hard due to vendor config disprecancies= , I expect policy work to be much harder ... > > But I think, there is an opportunity to start something new for everyone = (that may coexist with existing CLI policies) and not looking at CLI transl= ation (it will be impossible with policies). Then it would be up to service= providers to request the support of this by their favorite vendors. > > Best Regards, > > Stephane > > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Ra= szuk > Sent: Wednesday, December 17, 2014 23:28 > To: Jeff Tantsura > Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; LITKOWS= KI Stephane SCE/IBNF; Ladislav Lhotka > Subject: Re: [Rtg-yang-coord] issue :R01: route filters > > So are you saying that formal YANG specification say for BGP by design wi= ll not be compatible with some implementations ? > > Or are you saying that formal design say of BGP protocol will have to wai= t few years till YANG for policy spec is complete ? > > Cheers, > r. > > On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura wrote: >> Yes, exactly, Robert - the behavior you have described is an implementat= ion, not a formal specification. >> >> Regards, >> Jeff >> >>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) wrote: >>> >>> Why is this a problem if the default is to not to redistribute routes b= etween RIBs? Note that it isn=E2=80=99t like we have a set of approved rout= ing protocol models that are dependent on this behavior. >>> Acee >>> >>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic wrote= : >>>> >>>> Robert, >>>> >>>> Your proposal is very sensible and I think this is the best option >>>> >>>> Dean >>>> >>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrote: >>>>> >>>>> Dean, all >>>>> >>>>> The way I read it currently in section 5.5 there are only two route >>>>> filters proposed (deny-all or allow-all). As we know some routing >>>>> protocols require explicit permission to operate (example: EBGP). >>>>> If we remove even those two primitive filters there can be impact >>>>> to other components. >>>>> >>>>> But I do support a separate work for YANG model for policy. I do >>>>> expect this to be a very interesting and involved work considering >>>>> significant diversity of policy languages across all >>>>> implementations today. >>>>> >>>>> Once that work is done we could retire section 5.5 of >>>>> *-netmod-routing-* >>>>> >>>>> Regards, >>>>> r. >>>>> >>>>> >>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wrote: >>>>>> I'm in support of removing route filters from the routing cfg model.= Route filters should be IMO part of the policy model, in which also ACL mo= del belongs too. Actually, I would argue that the current ACL model is very= suitable for route filters. >>>>>> >>>>>> Dean >>>> >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > From nobody Fri Dec 19 02:33:31 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6221A874B for ; Fri, 19 Dec 2014 02:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNdc4ERjxmkW for ; Fri, 19 Dec 2014 02:33:27 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82CE21A8752 for ; Fri, 19 Dec 2014 02:33:25 -0800 (PST) Received: from pc6 (81.151.166.145) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.49.12; Fri, 19 Dec 2014 10:28:16 +0000 Message-ID: <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> From: t.petch To: Alia Atlas References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk><07ae01d01636$ac853340$4001a8c0@gateway.2wire.net><89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com><064e01d01637$bab52370$301f6a50$@olddog.co.uk><1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com><053001d019eb$92845760$4001a8c0@gateway.2wire.net><022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> Date: Fri, 19 Dec 2014 10:08:07 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.166.145] X-ClientProxiedBy: DB4PR05CA0040.eurprd05.prod.outlook.com (25.160.40.50) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB061; X-Forefront-PRVS: 0430FA5CB7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(37854004)(377454003)(189002)(51704005)(199003)(105586002)(106356001)(33646002)(68736005)(97736003)(87976001)(1556002)(19580395003)(19580405001)(84392001)(1456003)(101416001)(110136001)(77156002)(62966003)(120916001)(99396003)(14496001)(46102003)(77096005)(40100003)(1411001)(122386002)(230783001)(76176999)(81816999)(92566001)(50986999)(62236002)(44716002)(44736004)(93886004)(81686999)(31966008)(107046002)(21056001)(89996001)(42186005)(20776003)(50226001)(86362001)(64706001)(50466002)(23676002)(61296003)(4396001)(47776003)(116806002)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2014 10:28:16.5762 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/UDfeNd3WdThya2WZLVY6j56eq2A Cc: Rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:33:29 -0000 ----- Original Message ----- From: "Alia Atlas" To: "t.petch" Cc: Sent: Thursday, December 18, 2014 6:38 PM > Tom, > > On Thu, Dec 18, 2014 at 1:05 PM, t.petch wrote: > > > > > ----- Original Message ----- > > From: "Alia Atlas" > > To: > > Sent: Thursday, December 18, 2014 4:28 PM > > > > > Are there routing YANG models that are running into concerns around > > > floating point? > > > > Alia > > > > 24Apr14 netmod WG list Robert Varga > > "while modeling some protocols (notably RSVP), we came across the need > > to represent IEEE754-2008 floating types without losing precision. I'd > > like > > to ask what is the group's sentiment regarding extending the base types > > with at least binary{32,64} (which have their counterparts in XML schema > > datatypes)." > > > > which suggests that the answer is yes. > > > > Indeed it does. Assuming these TE extensions are modeled, there'll be at > least > 4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE. ... to which might be added IDR's flow spec (RFC5575) along with GMPLS's ted-mib (which cites RFC6340 - but I expect that that is your OSPF and ISIS) Historically, MEF's CIR has been expressed in floating point but I don't think that that is part of current CCAMP work. Tom Petch > > I might have posed a slightly different question, such as - does > > anyone outside a few on the netmod WG list realise that YANG has no > > support for floating point, just decimal-64? > > > > If they didn't before, they should be aware now. > > Alia From nobody Fri Dec 19 02:38:10 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282F81A8770 for ; Fri, 19 Dec 2014 02:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es99jXAtUBLi for ; Fri, 19 Dec 2014 02:38:05 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EE01A8775 for ; Fri, 19 Dec 2014 02:38:04 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id B151E142881; Fri, 19 Dec 2014 11:38:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418985481; bh=AegIhz0Y4W3Ic2FAJPpGvn3ZrGVWxUM9M0ypM3f6ae0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EmfKEEgm6OzgN31yoA/dN88kx23yh2LaCQlIkSLMogBd7scuzLvEHW+IuOWnoODwW KYE+kn3igsQs/G8AQ+KrDHjyhvVSPoZ0YxPxDQ5+oZItWupV7dRUNgybG82Q8HO0no huWq3J8CLS99jfFkbYEDVw3Nc3U+V9QmJ/1rFUJ4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 19 Dec 2014 11:38:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: Robert Raszuk X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/ZtE3iozRNFuMzxX_EOvQtrgX9xc Cc: "rtg-yang-coord@ietf.org" , "" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:38:07 -0000 > On 19 Dec 2014, at 11:10, Robert Raszuk wrote: >=20 > Hi Stephane, >=20 > That is going to be very interesting indeed. Considering that number > of customers have paid vendors millions for customized extensions and > only some of them made it to IETF drafts/rfcs. >=20 > So what will most likely happen is general YANG model of not much use > and zoo of proprietary vendor YANG extensions not compatible between > implementations. Right, configuration of route filters is an area where various = implementations widely differ. That=E2=80=99s why the route filter in = ietf-routing has the =E2=80=9Ctype=E2=80=9D parameter so that = alternative filtering frameworks could be used. >=20 > Is this really where we want to go with this entire effort ? My suggestion would be that each vendor create their own =E2=80=9Clegacy=E2= =80=9D model(s) and the new IETF data model would be recommended for new = implementations. Lada >=20 > Best, > r. >=20 >=20 > On Fri, Dec 19, 2014 at 11:03 AM, = wrote: >> Hi, >>=20 >> I think working of BGP YANG is a good opportunity to start working on = policy framework. >> Work on protocols YANG is already hard due to vendor config = disprecancies, I expect policy work to be much harder ... >>=20 >> But I think, there is an opportunity to start something new for = everyone (that may coexist with existing CLI policies) and not looking = at CLI translation (it will be impossible with policies). Then it would = be up to service providers to request the support of this by their = favorite vendors. >>=20 >> Best Regards, >>=20 >> Stephane >>=20 >>=20 >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of = Robert Raszuk >> Sent: Wednesday, December 17, 2014 23:28 >> To: Jeff Tantsura >> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; = LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>=20 >> So are you saying that formal YANG specification say for BGP by = design will not be compatible with some implementations ? >>=20 >> Or are you saying that formal design say of BGP protocol will have to = wait few years till YANG for policy spec is complete ? >>=20 >> Cheers, >> r. >>=20 >> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura = wrote: >>> Yes, exactly, Robert - the behavior you have described is an = implementation, not a formal specification. >>>=20 >>> Regards, >>> Jeff >>>=20 >>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) = wrote: >>>>=20 >>>> Why is this a problem if the default is to not to redistribute = routes between RIBs? Note that it isn=E2=80=99t like we have a set of = approved routing protocol models that are dependent on this behavior. >>>> Acee >>>>=20 >>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic = wrote: >>>>>=20 >>>>> Robert, >>>>>=20 >>>>> Your proposal is very sensible and I think this is the best option >>>>>=20 >>>>> Dean >>>>>=20 >>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk = wrote: >>>>>>=20 >>>>>> Dean, all >>>>>>=20 >>>>>> The way I read it currently in section 5.5 there are only two = route >>>>>> filters proposed (deny-all or allow-all). As we know some routing >>>>>> protocols require explicit permission to operate (example: EBGP). >>>>>> If we remove even those two primitive filters there can be impact >>>>>> to other components. >>>>>>=20 >>>>>> But I do support a separate work for YANG model for policy. I do >>>>>> expect this to be a very interesting and involved work = considering >>>>>> significant diversity of policy languages across all >>>>>> implementations today. >>>>>>=20 >>>>>> Once that work is done we could retire section 5.5 of >>>>>> *-netmod-routing-* >>>>>>=20 >>>>>> Regards, >>>>>> r. >>>>>>=20 >>>>>>=20 >>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic = wrote: >>>>>>> I'm in support of removing route filters from the routing cfg = model. Route filters should be IMO part of the policy model, in which = also ACL model belongs too. Actually, I would argue that the current ACL = model is very suitable for route filters. >>>>>>>=20 >>>>>>> Dean >>>>>=20 >>>>> _______________________________________________ >>>>> Rtg-yang-coord mailing list >>>>> Rtg-yang-coord@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 19 02:53:55 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE611A8A0F for ; Fri, 19 Dec 2014 02:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYJqyOzIx3fL for ; Fri, 19 Dec 2014 02:53:50 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C751A8AA7 for ; Fri, 19 Dec 2014 02:53:50 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so481033iec.1 for ; Fri, 19 Dec 2014 02:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IGHCc9ahg/ooStov4NiYrKQyNXJsOhPKo3VyX5RfQ88=; b=RzRYDG75Kh4sUhTTVMpKHtlPW5Gt5bpweOY2kIuvIL0xob3miEkXp47kM5rpMDsHVv QaYmu5eFIEI9vcgDBAjaEfIrGUUf57lxlHh9c9dAXp6kSQjxAfJXKOcvLDjGOImBiJRF izas5WbUoFK68qjEC7Cdv1ixeKCQ/kYrG4xkP9uDA3LKRmHVCM2QcErYNEpVdO0ReSLq 9vtMbakMZegiNzrvRtZT9hqmRp9H408m4FfRCXJcAk3m2VdA6Qy3Y7jBP+LDypcjqZxp eP4YPlHbTO0xNO39eblt3DwRpQsmYAuKUqENc7GMBv0jeFKXIcLWGZz9KEBEwGI+YaTy WT/Q== MIME-Version: 1.0 X-Received: by 10.107.165.75 with SMTP id o72mr6338455ioe.33.1418986429125; Fri, 19 Dec 2014 02:53:49 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.152.130 with HTTP; Fri, 19 Dec 2014 02:53:49 -0800 (PST) In-Reply-To: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Fri, 19 Dec 2014 11:53:49 +0100 X-Google-Sender-Auth: t2eIPY6iIz0p-Io9WrxP6AGQeH0 Message-ID: From: Robert Raszuk To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/zMInOXE_BIkkpz1ZKbxYhB-zUoU Cc: "rtg-yang-coord@ietf.org" , "" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 10:53:52 -0000 Ladislav, But vendors live and gain by being better then their immediate competition. Both in routing protocols features as well as policy flexibility. For them what you call "legacy" is the secret sauce they want to keep for years to come. I am afraid attempt to place them under common denominator will just not work from business point of view. Otherwise how they are going to make money and differentiate themselves from open source control plane efforts and growing market of ODM/OCP based hardware ? Cheers, R. On Fri, Dec 19, 2014 at 11:38 AM, Ladislav Lhotka wrote: > >> On 19 Dec 2014, at 11:10, Robert Raszuk wrote: >> >> Hi Stephane, >> >> That is going to be very interesting indeed. Considering that number >> of customers have paid vendors millions for customized extensions and >> only some of them made it to IETF drafts/rfcs. >> >> So what will most likely happen is general YANG model of not much use >> and zoo of proprietary vendor YANG extensions not compatible between >> implementations. > > Right, configuration of route filters is an area where various implementa= tions widely differ. That=E2=80=99s why the route filter in ietf-routing ha= s the =E2=80=9Ctype=E2=80=9D parameter so that alternative filtering framew= orks could be used. > >> >> Is this really where we want to go with this entire effort ? > > My suggestion would be that each vendor create their own =E2=80=9Clegacy= =E2=80=9D model(s) and the new IETF data model would be recommended for new= implementations. > > Lada > >> >> Best, >> r. >> >> >> On Fri, Dec 19, 2014 at 11:03 AM, wrote= : >>> Hi, >>> >>> I think working of BGP YANG is a good opportunity to start working on p= olicy framework. >>> Work on protocols YANG is already hard due to vendor config disprecanci= es, I expect policy work to be much harder ... >>> >>> But I think, there is an opportunity to start something new for everyon= e (that may coexist with existing CLI policies) and not looking at CLI tran= slation (it will be impossible with policies). Then it would be up to servi= ce providers to request the support of this by their favorite vendors. >>> >>> Best Regards, >>> >>> Stephane >>> >>> >>> -----Original Message----- >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk >>> Sent: Wednesday, December 17, 2014 23:28 >>> To: Jeff Tantsura >>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; LITKO= WSKI Stephane SCE/IBNF; Ladislav Lhotka >>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>> >>> So are you saying that formal YANG specification say for BGP by design = will not be compatible with some implementations ? >>> >>> Or are you saying that formal design say of BGP protocol will have to w= ait few years till YANG for policy spec is complete ? >>> >>> Cheers, >>> r. >>> >>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura wrote: >>>> Yes, exactly, Robert - the behavior you have described is an implement= ation, not a formal specification. >>>> >>>> Regards, >>>> Jeff >>>> >>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) wrot= e: >>>>> >>>>> Why is this a problem if the default is to not to redistribute routes= between RIBs? Note that it isn=E2=80=99t like we have a set of approved ro= uting protocol models that are dependent on this behavior. >>>>> Acee >>>>> >>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic wro= te: >>>>>> >>>>>> Robert, >>>>>> >>>>>> Your proposal is very sensible and I think this is the best option >>>>>> >>>>>> Dean >>>>>> >>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk wrot= e: >>>>>>> >>>>>>> Dean, all >>>>>>> >>>>>>> The way I read it currently in section 5.5 there are only two route >>>>>>> filters proposed (deny-all or allow-all). As we know some routing >>>>>>> protocols require explicit permission to operate (example: EBGP). >>>>>>> If we remove even those two primitive filters there can be impact >>>>>>> to other components. >>>>>>> >>>>>>> But I do support a separate work for YANG model for policy. I do >>>>>>> expect this to be a very interesting and involved work considering >>>>>>> significant diversity of policy languages across all >>>>>>> implementations today. >>>>>>> >>>>>>> Once that work is done we could retire section 5.5 of >>>>>>> *-netmod-routing-* >>>>>>> >>>>>>> Regards, >>>>>>> r. >>>>>>> >>>>>>> >>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic wrote: >>>>>>>> I'm in support of removing route filters from the routing cfg mode= l. Route filters should be IMO part of the policy model, in which also ACL = model belongs too. Actually, I would argue that the current ACL model is ve= ry suitable for route filters. >>>>>>>> >>>>>>>> Dean >>>>>> >>>>>> _______________________________________________ >>>>>> Rtg-yang-coord mailing list >>>>>> Rtg-yang-coord@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>> >>> >>> _______________________________________________________________________= __________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged= information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Dec 19 03:16:48 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCA31A8AB6 for ; Fri, 19 Dec 2014 03:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQMvAtDAYjKM for ; Fri, 19 Dec 2014 03:16:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E851A901E for ; Fri, 19 Dec 2014 03:16:37 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 7701B141107; Fri, 19 Dec 2014 12:16:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1418987795; bh=YAfYXFVTcHnUOi0hgtZFgWyxdjHys3EN5HHLOmRsGWQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KwgGI3x1MCnMDcS+SMr3lPFBcJjQeNy/HmEE9kgLKY5zlx8M67LT+jU9TQpl1l/aE ikIOvFQq+wW1HOcm9cM1RzPYsBz1iT5mN0SIviHe9q3FsSKPh/LE0TZPmTwba7g/Lk gQ34keJg+LigjixSi73rNAi/U+LJde67mXYzbRN4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 19 Dec 2014 12:16:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: Robert Raszuk X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/cY8tm63bSH-1weeSVPDeypg2U1U Cc: "rtg-yang-coord@ietf.org" , "" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:16:40 -0000 > On 19 Dec 2014, at 11:53, Robert Raszuk wrote: >=20 > Ladislav, >=20 > But vendors live and gain by being better then their immediate > competition. Both in routing protocols features as well as policy > flexibility. >=20 > For them what you call "legacy" is the secret sauce they want to keep > for years to come. I am afraid attempt to place them under common > denominator will just not work from business point of view. Of course, that=E2=80=99s everybody=E2=80=99s choice. I didn=E2=80=99t = mean a common denominator though but rather a simple and powerful data = model developed from scratch that will be arguably better than the = existing options. >=20 > Otherwise how they are going to make money and differentiate > themselves from open source control plane efforts and growing market > of ODM/OCP based hardware ? Unix history shows that it can also be an open source alternative that = survives. Lada >=20 > Cheers, > R. >=20 >=20 >=20 > On Fri, Dec 19, 2014 at 11:38 AM, Ladislav Lhotka = wrote: >>=20 >>> On 19 Dec 2014, at 11:10, Robert Raszuk wrote: >>>=20 >>> Hi Stephane, >>>=20 >>> That is going to be very interesting indeed. Considering that number >>> of customers have paid vendors millions for customized extensions = and >>> only some of them made it to IETF drafts/rfcs. >>>=20 >>> So what will most likely happen is general YANG model of not much = use >>> and zoo of proprietary vendor YANG extensions not compatible between >>> implementations. >>=20 >> Right, configuration of route filters is an area where various = implementations widely differ. That=E2=80=99s why the route filter in = ietf-routing has the =E2=80=9Ctype=E2=80=9D parameter so that = alternative filtering frameworks could be used. >>=20 >>>=20 >>> Is this really where we want to go with this entire effort ? >>=20 >> My suggestion would be that each vendor create their own =E2=80=9Clegac= y=E2=80=9D model(s) and the new IETF data model would be recommended for = new implementations. >>=20 >> Lada >>=20 >>>=20 >>> Best, >>> r. >>>=20 >>>=20 >>> On Fri, Dec 19, 2014 at 11:03 AM, = wrote: >>>> Hi, >>>>=20 >>>> I think working of BGP YANG is a good opportunity to start working = on policy framework. >>>> Work on protocols YANG is already hard due to vendor config = disprecancies, I expect policy work to be much harder ... >>>>=20 >>>> But I think, there is an opportunity to start something new for = everyone (that may coexist with existing CLI policies) and not looking = at CLI translation (it will be impossible with policies). Then it would = be up to service providers to request the support of this by their = favorite vendors. >>>>=20 >>>> Best Regards, >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of = Robert Raszuk >>>> Sent: Wednesday, December 17, 2014 23:28 >>>> To: Jeff Tantsura >>>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; = LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >>>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>>>=20 >>>> So are you saying that formal YANG specification say for BGP by = design will not be compatible with some implementations ? >>>>=20 >>>> Or are you saying that formal design say of BGP protocol will have = to wait few years till YANG for policy spec is complete ? >>>>=20 >>>> Cheers, >>>> r. >>>>=20 >>>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura = wrote: >>>>> Yes, exactly, Robert - the behavior you have described is an = implementation, not a formal specification. >>>>>=20 >>>>> Regards, >>>>> Jeff >>>>>=20 >>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) = wrote: >>>>>>=20 >>>>>> Why is this a problem if the default is to not to redistribute = routes between RIBs? Note that it isn=E2=80=99t like we have a set of = approved routing protocol models that are dependent on this behavior. >>>>>> Acee >>>>>>=20 >>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic = wrote: >>>>>>>=20 >>>>>>> Robert, >>>>>>>=20 >>>>>>> Your proposal is very sensible and I think this is the best = option >>>>>>>=20 >>>>>>> Dean >>>>>>>=20 >>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk = wrote: >>>>>>>>=20 >>>>>>>> Dean, all >>>>>>>>=20 >>>>>>>> The way I read it currently in section 5.5 there are only two = route >>>>>>>> filters proposed (deny-all or allow-all). As we know some = routing >>>>>>>> protocols require explicit permission to operate (example: = EBGP). >>>>>>>> If we remove even those two primitive filters there can be = impact >>>>>>>> to other components. >>>>>>>>=20 >>>>>>>> But I do support a separate work for YANG model for policy. I = do >>>>>>>> expect this to be a very interesting and involved work = considering >>>>>>>> significant diversity of policy languages across all >>>>>>>> implementations today. >>>>>>>>=20 >>>>>>>> Once that work is done we could retire section 5.5 of >>>>>>>> *-netmod-routing-* >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> r. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic = wrote: >>>>>>>>> I'm in support of removing route filters from the routing cfg = model. Route filters should be IMO part of the policy model, in which = also ACL model belongs too. Actually, I would argue that the current ACL = model is very suitable for route filters. >>>>>>>>>=20 >>>>>>>>> Dean >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Rtg-yang-coord mailing list >>>>>>> Rtg-yang-coord@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>>>=20 >>>>=20 >>>> = __________________________________________________________________________= _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>> they should not be distributed, used or copied without = authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 19 03:18:03 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C51A8AE0 for ; Fri, 19 Dec 2014 03:18:01 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x13VwQ8wKCPr for ; Fri, 19 Dec 2014 03:17:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C86AF1A8AB6 for ; Fri, 19 Dec 2014 03:17:57 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id CBAAF1280996; Fri, 19 Dec 2014 12:17:56 +0100 (CET) Date: Fri, 19 Dec 2014 12:17:57 +0100 (CET) Message-Id: <20141219.121757.446280395682448005.mbj@tail-f.com> To: robert@raszuk.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/WUkdjlim4_zP7HEOdI4UZPMrSOw Cc: rtg-yang-coord@ietf.org, stephane.litkowski@orange.com, lhotka@nic.cz, jeff.tantsura@ericsson.com, deanb@juniper.net, acee@cisco.com Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:18:02 -0000 SGksDQoNCkl0IGlzIGV4cGVjdGVkIHRoYXQgdmVuZG9ycyBjcmVhdGUgdGhlaXIgb3duIFlBTkcg bW9kdWxlcyB0aGF0IGV4dGVuZA0KdGhlIHN0YW5kYXJkIG1vZGVscyB3aXRoIHdoYXRldmVyIGZl YXR1cmVzIHRoZSB2ZW5kb3JzIGhhdmUuICBCeQ0KaGF2aW5nIGEgY29tbW9uIHNldCBvZiBzdGFu ZGFyZCBtb2RlbHMsIHRoZXJlIHdpbGwgYmUgY29tbW9uYWxpdHkgaW4NCnRoZSBzdHJ1Y3R1cmUg YW5kIGhvdyB0aGluZ3MgYXJlIG5hbWVkLCB3aGljaCBoZWxwcyBvcGVyYXRvcnMgd2l0aG91dA0K cmVzdHJpY3RpbmcgdmVuZG9ycy4NCg0KSW4gdGhlIHNwZWNpZmljIGNhc2Ugb2Ygcm91dGluZyBw b2xpY3ksIEkgdGhpbmsgd2hhdCBMYWRhIHNheXMgaXMgdGhhdA0KdGhlcmUgY2FuIGJlIHZlbmRv ci1zcGVjaWZpYyBwb2xpY3kgbW9kZWxzIGluIGFkZGl0aW9uIHRvIHRoZSBzdGFuZGFyZA0KbW9k ZWwuICBUaGUgc3RhbmRhcmQgaXMgdGhlICJiYXNlbGluZSIsIGJ1dCBvcGVyYXRvcnMgY2FuIGNo b29zZSB0bw0KdXNlIHRoZSB2ZW5kb3Itc3BlY2lmaWMgbW9kZWwgaWYgaXQgcHJvdmlkZXMgYWRk aXRpb25hbCBiZW5maXRzLg0KDQoNCi9tYXJ0aW4NCg0KDQpSb2JlcnQgUmFzenVrIDxyb2JlcnRA cmFzenVrLm5ldD4gd3JvdGU6DQo+IExhZGlzbGF2LA0KPiANCj4gQnV0IHZlbmRvcnMgbGl2ZSBh bmQgZ2FpbiBieSBiZWluZyBiZXR0ZXIgdGhlbiB0aGVpciBpbW1lZGlhdGUNCj4gY29tcGV0aXRp b24uIEJvdGggaW4gcm91dGluZyBwcm90b2NvbHMgZmVhdHVyZXMgYXMgd2VsbCBhcyBwb2xpY3kN Cj4gZmxleGliaWxpdHkuDQo+IA0KPiBGb3IgdGhlbSB3aGF0IHlvdSBjYWxsICJsZWdhY3kiIGlz IHRoZSBzZWNyZXQgc2F1Y2UgdGhleSB3YW50IHRvIGtlZXANCj4gZm9yIHllYXJzIHRvIGNvbWUu IEkgYW0gYWZyYWlkIGF0dGVtcHQgdG8gcGxhY2UgdGhlbSB1bmRlciBjb21tb24NCj4gZGVub21p bmF0b3Igd2lsbCBqdXN0IG5vdCB3b3JrIGZyb20gYnVzaW5lc3MgcG9pbnQgb2Ygdmlldy4NCj4g DQo+IE90aGVyd2lzZSBob3cgdGhleSBhcmUgZ29pbmcgdG8gbWFrZSBtb25leSBhbmQgZGlmZmVy ZW50aWF0ZQ0KPiB0aGVtc2VsdmVzIGZyb20gb3BlbiBzb3VyY2UgY29udHJvbCBwbGFuZSBlZmZv cnRzIGFuZCBncm93aW5nIG1hcmtldA0KPiBvZiBPRE0vT0NQIGJhc2VkIGhhcmR3YXJlID8NCj4g DQo+IENoZWVycywNCj4gUi4NCj4gDQo+IA0KPiANCj4gT24gRnJpLCBEZWMgMTksIDIwMTQgYXQg MTE6MzggQU0sIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4NCj4g Pj4gT24gMTkgRGVjIDIwMTQsIGF0IDExOjEwLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVr Lm5ldD4gd3JvdGU6DQo+ID4+DQo+ID4+IEhpIFN0ZXBoYW5lLA0KPiA+Pg0KPiA+PiBUaGF0IGlz IGdvaW5nIHRvIGJlIHZlcnkgaW50ZXJlc3RpbmcgaW5kZWVkLiBDb25zaWRlcmluZyB0aGF0IG51 bWJlcg0KPiA+PiBvZiBjdXN0b21lcnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWlsbGlvbnMgZm9yIGN1 c3RvbWl6ZWQgZXh0ZW5zaW9ucyBhbmQNCj4gPj4gb25seSBzb21lIG9mIHRoZW0gbWFkZSBpdCB0 byBJRVRGIGRyYWZ0cy9yZmNzLg0KPiA+Pg0KPiA+PiBTbyB3aGF0IHdpbGwgbW9zdCBsaWtlbHkg aGFwcGVuIGlzIGdlbmVyYWwgWUFORyBtb2RlbCBvZiBub3QgbXVjaCB1c2UNCj4gPj4gYW5kIHpv byBvZiBwcm9wcmlldGFyeSB2ZW5kb3IgWUFORyBleHRlbnNpb25zIG5vdCBjb21wYXRpYmxlIGJl dHdlZW4NCj4gPj4gaW1wbGVtZW50YXRpb25zLg0KPiA+DQo+ID4gUmlnaHQsIGNvbmZpZ3VyYXRp b24gb2Ygcm91dGUgZmlsdGVycyBpcyBhbiBhcmVhIHdoZXJlIHZhcmlvdXMgaW1wbGVtZW50YXRp b25zIHdpZGVseSBkaWZmZXIuIFRoYXTigJlzIHdoeSB0aGUgcm91dGUgZmlsdGVyIGluIGlldGYt cm91dGluZyBoYXMgdGhlIOKAnHR5cGXigJ0gcGFyYW1ldGVyIHNvIHRoYXQgYWx0ZXJuYXRpdmUg ZmlsdGVyaW5nIGZyYW1ld29ya3MgY291bGQgYmUgdXNlZC4NCj4gPg0KPiA+Pg0KPiA+PiBJcyB0 aGlzIHJlYWxseSB3aGVyZSB3ZSB3YW50IHRvIGdvIHdpdGggdGhpcyBlbnRpcmUgZWZmb3J0ID8N Cj4gPg0KPiA+IE15IHN1Z2dlc3Rpb24gd291bGQgYmUgdGhhdCBlYWNoIHZlbmRvciBjcmVhdGUg dGhlaXIgb3duIOKAnGxlZ2FjeeKAnSBtb2RlbChzKSBhbmQgdGhlIG5ldyBJRVRGIGRhdGEgbW9k ZWwgd291bGQgYmUgcmVjb21tZW5kZWQgZm9yIG5ldyBpbXBsZW1lbnRhdGlvbnMuDQo+ID4NCj4g PiBMYWRhDQo+ID4NCj4gPj4NCj4gPj4gQmVzdCwNCj4gPj4gci4NCj4gPj4NCj4gPj4NCj4gPj4g T24gRnJpLCBEZWMgMTksIDIwMTQgYXQgMTE6MDMgQU0sICA8c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20+IHdyb3RlOg0KPiA+Pj4gSGksDQo+ID4+Pg0KPiA+Pj4gSSB0aGluayB3b3JraW5n IG9mIEJHUCBZQU5HIGlzIGEgZ29vZCBvcHBvcnR1bml0eSB0byBzdGFydCB3b3JraW5nIG9uIHBv bGljeSBmcmFtZXdvcmsuDQo+ID4+PiBXb3JrIG9uIHByb3RvY29scyBZQU5HIGlzIGFscmVhZHkg aGFyZCBkdWUgdG8gdmVuZG9yIGNvbmZpZyBkaXNwcmVjYW5jaWVzLCBJIGV4cGVjdCBwb2xpY3kg d29yayB0byBiZSBtdWNoIGhhcmRlciAuLi4NCj4gPj4+DQo+ID4+PiBCdXQgSSB0aGluaywgdGhl cmUgaXMgYW4gb3Bwb3J0dW5pdHkgdG8gc3RhcnQgc29tZXRoaW5nIG5ldyBmb3IgZXZlcnlvbmUg KHRoYXQgbWF5IGNvZXhpc3Qgd2l0aCBleGlzdGluZyBDTEkgcG9saWNpZXMpIGFuZCBub3QgbG9v a2luZyBhdCBDTEkgdHJhbnNsYXRpb24gKGl0IHdpbGwgYmUgaW1wb3NzaWJsZSB3aXRoIHBvbGlj aWVzKS4gVGhlbiBpdCB3b3VsZCBiZSB1cCB0byBzZXJ2aWNlIHByb3ZpZGVycyB0byByZXF1ZXN0 IHRoZSBzdXBwb3J0IG9mIHRoaXMgYnkgdGhlaXIgZmF2b3JpdGUgdmVuZG9ycy4NCj4gPj4+DQo+ ID4+PiBCZXN0IFJlZ2FyZHMsDQo+ID4+Pg0KPiA+Pj4gU3RlcGhhbmUNCj4gPj4+DQo+ID4+Pg0K PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IHJyYXN6dWtAZ21h aWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFz enVrDQo+ID4+PiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE3LCAyMDE0IDIzOjI4DQo+ID4+ PiBUbzogSmVmZiBUYW50c3VyYQ0KPiA+Pj4gQ2M6IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBC b2dkYW5vdmljOyBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgTElUS09XU0tJIFN0ZXBoYW5lIFND RS9JQk5GOyBMYWRpc2xhdiBMaG90a2ENCj4gPj4+IFN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29v cmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4gPj4+DQo+ID4+PiBTbyBhcmUgeW91IHNh eWluZyB0aGF0IGZvcm1hbCBZQU5HIHNwZWNpZmljYXRpb24gc2F5IGZvciBCR1AgYnkgZGVzaWdu IHdpbGwgbm90IGJlIGNvbXBhdGlibGUgd2l0aCBzb21lIGltcGxlbWVudGF0aW9ucyA/DQo+ID4+ Pg0KPiA+Pj4gT3IgYXJlIHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwgZGVzaWduIHNheSBvZiBCR1Ag cHJvdG9jb2wgd2lsbCBoYXZlIHRvIHdhaXQgZmV3IHllYXJzIHRpbGwgWUFORyBmb3IgcG9saWN5 IHNwZWMgaXMgY29tcGxldGUgPw0KPiA+Pj4NCj4gPj4+IENoZWVycywNCj4gPj4+IHIuDQo+ID4+ Pg0KPiA+Pj4gT24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgMTE6MTQgUE0sIEplZmYgVGFudHN1cmEg PGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gPj4+PiBZZXMsIGV4YWN0bHks IFJvYmVydCAtIHRoZSBiZWhhdmlvciB5b3UgaGF2ZSBkZXNjcmliZWQgaXMgYW4gaW1wbGVtZW50 YXRpb24sIG5vdCBhIGZvcm1hbCBzcGVjaWZpY2F0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gUmVnYXJk cywNCj4gPj4+PiBKZWZmDQo+ID4+Pj4NCj4gPj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCAyOjEy IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gPj4+Pj4N Cj4gPj4+Pj4gV2h5IGlzIHRoaXMgYSBwcm9ibGVtIGlmIHRoZSBkZWZhdWx0IGlzIHRvIG5vdCB0 byByZWRpc3RyaWJ1dGUgcm91dGVzIGJldHdlZW4gUklCcz8gTm90ZSB0aGF0IGl0IGlzbuKAmXQg bGlrZSB3ZSBoYXZlIGEgc2V0IG9mIGFwcHJvdmVkIHJvdXRpbmcgcHJvdG9jb2wgbW9kZWxzIHRo YXQgYXJlIGRlcGVuZGVudCBvbiB0aGlzIGJlaGF2aW9yLg0KPiA+Pj4+PiBBY2VlDQo+ID4+Pj4+ DQo+ID4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDU6MDcgUE0sIERlYW4gQm9nZGFub3ZpYyA8 ZGVhbmJAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFJvYmVydCwNCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBZb3VyIHByb3Bvc2FsIGlzIHZlcnkgc2Vuc2libGUgYW5kIEkgdGhp bmsgdGhpcyBpcyB0aGUgYmVzdCBvcHRpb24NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBEZWFuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNDo0OSBQTSwgUm9iZXJ0IFJhc3p1 ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gRGVhbiwg YWxsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGUgd2F5IEkgcmVhZCBpdCBjdXJyZW50bHkgaW4g c2VjdGlvbiA1LjUgdGhlcmUgYXJlIG9ubHkgdHdvIHJvdXRlDQo+ID4+Pj4+Pj4gZmlsdGVycyBw cm9wb3NlZCAoZGVueS1hbGwgb3IgYWxsb3ctYWxsKS4gQXMgd2Uga25vdyBzb21lIHJvdXRpbmcN Cj4gPj4+Pj4+PiBwcm90b2NvbHMgcmVxdWlyZSBleHBsaWNpdCBwZXJtaXNzaW9uIHRvIG9wZXJh dGUgKGV4YW1wbGU6IEVCR1ApLg0KPiA+Pj4+Pj4+IElmIHdlIHJlbW92ZSBldmVuIHRob3NlIHR3 byBwcmltaXRpdmUgZmlsdGVycyB0aGVyZSBjYW4gYmUgaW1wYWN0DQo+ID4+Pj4+Pj4gdG8gb3Ro ZXIgY29tcG9uZW50cy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEJ1dCBJIGRvIHN1cHBvcnQgYSBz ZXBhcmF0ZSB3b3JrIGZvciBZQU5HIG1vZGVsIGZvciBwb2xpY3kuIEkgZG8NCj4gPj4+Pj4+PiBl eHBlY3QgdGhpcyB0byBiZSBhIHZlcnkgaW50ZXJlc3RpbmcgYW5kIGludm9sdmVkIHdvcmsgY29u c2lkZXJpbmcNCj4gPj4+Pj4+PiBzaWduaWZpY2FudCBkaXZlcnNpdHkgb2YgcG9saWN5IGxhbmd1 YWdlcyBhY3Jvc3MgYWxsDQo+ID4+Pj4+Pj4gaW1wbGVtZW50YXRpb25zIHRvZGF5Lg0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4gT25jZSB0aGF0IHdvcmsgaXMgZG9uZSB3ZSBjb3VsZCByZXRpcmUgc2Vj dGlvbiA1LjUgb2YNCj4gPj4+Pj4+PiAqLW5ldG1vZC1yb3V0aW5nLSoNCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4+Pj4gci4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDEwOjA5IFBNLCBEZWFuIEJvZ2Rhbm92aWMg PGRlYW5iQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPj4+Pj4+Pj4gSSdtIGluIHN1cHBvcnQgb2Yg cmVtb3Zpbmcgcm91dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0aW5nIGNmZyBtb2RlbC4gUm91dGUg ZmlsdGVycyBzaG91bGQgYmUgSU1PIHBhcnQgb2YgdGhlIHBvbGljeSBtb2RlbCwgaW4gd2hpY2gg YWxzbyBBQ0wgbW9kZWwgYmVsb25ncyB0b28uIEFjdHVhbGx5LCBJIHdvdWxkIGFyZ3VlIHRoYXQg dGhlIGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3VpdGFibGUgZm9yIHJvdXRlIGZpbHRlcnMu DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IERlYW4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gUnRnLXlh bmctY29vcmQgbWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0K PiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1j b29yZA0KPiA+Pj4+Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+DQo+ID4+PiBDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4g Pj4+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyDQo+ID4+PiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiA+Pj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KPiA+Pj4NCj4gPj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+ID4+PiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPj4+IElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+Pj4gQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+Pj4gVGhh bmsgeW91Lg0KPiA+Pj4NCj4gPg0KPiA+IC0tDQo+ID4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMg TGFicw0KPiA+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJ0Zy15 YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo= From nobody Fri Dec 19 03:58:35 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C331A9129 for ; Fri, 19 Dec 2014 03:58: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovBRyDO34AKE for ; Fri, 19 Dec 2014 03:58:30 -0800 (PST) Received: from ivanoab3.miniserver.com (ivanoab3.miniserver.com [89.200.143.206]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6221A9115 for ; Fri, 19 Dec 2014 03:58:28 -0800 (PST) Received: from [192.168.17.10] (helo=localhost.localdomain) by ivanoab3.miniserver.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Y1wA5-0000M8-Ma; Fri, 19 Dec 2014 11:56:01 +0000 Received: from 173-38-208-169.cisco.com ([173.38.208.169] helo=ams-giheron-89110.cisco.com) by localhost.localdomain with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Y1wDt-0003q6-4a; Fri, 19 Dec 2014 11:59:57 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Giles Heron In-Reply-To: <20141219.121757.446280395682448005.mbj@tail-f.com> Date: Fri, 19 Dec 2014 11:58:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <94DF27F6-3E15-42F8-9180-70137AD5AA81@layerfree.net> References: <20141219.121757.446280395682448005.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/sJqoWjRzOyNq5ROZmCzq_5TtjoI Cc: rtg-yang-coord@ietf.org, stephane.litkowski@orange.com, robert@raszuk.net, lhotka@nic.cz, jeff.tantsura@ericsson.com, deanb@juniper.net, acee@cisco.com Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:58:33 -0000 But isn't there a fairly common case where multiple vendors have a = common "knob" (e.g. because a big carrier has asked all of them to add = it), but where that knob isn't documented in an RFC anywhere? In that instance I'd presume we want that knob to be part of the IETF = standard model - or at least part of a common augment on a github = somewhere - rather than each vendor defining their own potentially = incompatible augment. Giles On 19 Dec 2014, at 11:17, Martin Bjorklund wrote: > Hi, >=20 > It is expected that vendors create their own YANG modules that extend > the standard models with whatever features the vendors have. By > having a common set of standard models, there will be commonality in > the structure and how things are named, which helps operators without > restricting vendors. >=20 > In the specific case of routing policy, I think what Lada says is that > there can be vendor-specific policy models in addition to the standard > model. The standard is the "baseline", but operators can choose to > use the vendor-specific model if it provides additional benfits. >=20 >=20 > /martin >=20 >=20 > Robert Raszuk wrote: >> Ladislav, >>=20 >> But vendors live and gain by being better then their immediate >> competition. Both in routing protocols features as well as policy >> flexibility. >>=20 >> For them what you call "legacy" is the secret sauce they want to keep >> for years to come. I am afraid attempt to place them under common >> denominator will just not work from business point of view. >>=20 >> Otherwise how they are going to make money and differentiate >> themselves from open source control plane efforts and growing market >> of ODM/OCP based hardware ? >>=20 >> Cheers, >> R. >>=20 >>=20 >>=20 >> On Fri, Dec 19, 2014 at 11:38 AM, Ladislav Lhotka = wrote: >>>=20 >>>> On 19 Dec 2014, at 11:10, Robert Raszuk wrote: >>>>=20 >>>> Hi Stephane, >>>>=20 >>>> That is going to be very interesting indeed. Considering that = number >>>> of customers have paid vendors millions for customized extensions = and >>>> only some of them made it to IETF drafts/rfcs. >>>>=20 >>>> So what will most likely happen is general YANG model of not much = use >>>> and zoo of proprietary vendor YANG extensions not compatible = between >>>> implementations. >>>=20 >>> Right, configuration of route filters is an area where various = implementations widely differ. That=92s why the route filter in = ietf-routing has the =93type=94 parameter so that alternative filtering = frameworks could be used. >>>=20 >>>>=20 >>>> Is this really where we want to go with this entire effort ? >>>=20 >>> My suggestion would be that each vendor create their own =93legacy=94 = model(s) and the new IETF data model would be recommended for new = implementations. >>>=20 >>> Lada >>>=20 >>>>=20 >>>> Best, >>>> r. >>>>=20 >>>>=20 >>>> On Fri, Dec 19, 2014 at 11:03 AM, = wrote: >>>>> Hi, >>>>>=20 >>>>> I think working of BGP YANG is a good opportunity to start working = on policy framework. >>>>> Work on protocols YANG is already hard due to vendor config = disprecancies, I expect policy work to be much harder ... >>>>>=20 >>>>> But I think, there is an opportunity to start something new for = everyone (that may coexist with existing CLI policies) and not looking = at CLI translation (it will be impossible with policies). Then it would = be up to service providers to request the support of this by their = favorite vendors. >>>>>=20 >>>>> Best Regards, >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of = Robert Raszuk >>>>> Sent: Wednesday, December 17, 2014 23:28 >>>>> To: Jeff Tantsura >>>>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; = LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >>>>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>>>>=20 >>>>> So are you saying that formal YANG specification say for BGP by = design will not be compatible with some implementations ? >>>>>=20 >>>>> Or are you saying that formal design say of BGP protocol will have = to wait few years till YANG for policy spec is complete ? >>>>>=20 >>>>> Cheers, >>>>> r. >>>>>=20 >>>>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura = wrote: >>>>>> Yes, exactly, Robert - the behavior you have described is an = implementation, not a formal specification. >>>>>>=20 >>>>>> Regards, >>>>>> Jeff >>>>>>=20 >>>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) = wrote: >>>>>>>=20 >>>>>>> Why is this a problem if the default is to not to redistribute = routes between RIBs? Note that it isn=92t like we have a set of approved = routing protocol models that are dependent on this behavior. >>>>>>> Acee >>>>>>>=20 >>>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic = wrote: >>>>>>>>=20 >>>>>>>> Robert, >>>>>>>>=20 >>>>>>>> Your proposal is very sensible and I think this is the best = option >>>>>>>>=20 >>>>>>>> Dean >>>>>>>>=20 >>>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk = wrote: >>>>>>>>>=20 >>>>>>>>> Dean, all >>>>>>>>>=20 >>>>>>>>> The way I read it currently in section 5.5 there are only two = route >>>>>>>>> filters proposed (deny-all or allow-all). As we know some = routing >>>>>>>>> protocols require explicit permission to operate (example: = EBGP). >>>>>>>>> If we remove even those two primitive filters there can be = impact >>>>>>>>> to other components. >>>>>>>>>=20 >>>>>>>>> But I do support a separate work for YANG model for policy. I = do >>>>>>>>> expect this to be a very interesting and involved work = considering >>>>>>>>> significant diversity of policy languages across all >>>>>>>>> implementations today. >>>>>>>>>=20 >>>>>>>>> Once that work is done we could retire section 5.5 of >>>>>>>>> *-netmod-routing-* >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> r. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic = wrote: >>>>>>>>>> I'm in support of removing route filters from the routing cfg = model. Route filters should be IMO part of the policy model, in which = also ACL model belongs too. Actually, I would argue that the current ACL = model is very suitable for route filters. >>>>>>>>>>=20 >>>>>>>>>> Dean >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Rtg-yang-coord mailing list >>>>>>>> Rtg-yang-coord@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>>>>=20 >>>>>=20 >>>>> = __________________________________________________________________________= _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>>> they should not be distributed, used or copied without = authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Fri Dec 19 03:58:48 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0881F1A90EE for ; Fri, 19 Dec 2014 03:58:46 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo9hGXIYB6pK for ; Fri, 19 Dec 2014 03:58:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50091A8F50 for ; Fri, 19 Dec 2014 03:58:42 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D11672DC1FC; Fri, 19 Dec 2014 12:58:40 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A1D4B27C0D4; Fri, 19 Dec 2014 12:58:40 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0210.002; Fri, 19 Dec 2014 12:58:40 +0100 From: To: Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBA= Date: Fri, 19 Dec 2014 11:58:40 +0000 Message-ID: <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.19.102119 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/C96LvfivdU6Rp8qE8pD9JDu5w0Q Cc: "rtg-yang-coord@ietf.org" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 11:58:46 -0000 Um9iZXJ0LA0KDQpZb3UgYXJlIHRvdWNoaW5nIGFuIGludGVyZXN0aW5nIHBvaW50IDopDQpJbiBm YWN0IHRoZXJlIGFyZSB0d28gd2F5cyBvZiB2aWV3aW5nIHRoaW5rcyA6DQotIHNlcnZpY2UgcHJv dmlkZXJzL2N1c3RvbWVycyB3aG8gd291bGQgbGlrZSB0byB1c2Ugb25seSBzdGFuZGFyZCBtb2Rl bHMgdG8gZmFjaWxpdGF0ZSBuZXR3b3JrIHByb3Zpc2lvbiAmIG9wZXJhdGlvbg0KLSB2ZW5kb3Jz IHdobyBtYXkgbm90IHdhbnQgdG8gbWFrZSBkZXZlbG9wbWVudCB0byBpbXBsZW1lbnQgbmV3IGZl YXR1cmVzIHRvIGJlIGNvbXBsaWFudCB3aXRoIGEgc3RhbmRhcmQgeWFuZyBtb2RlbCAgKGFzIGRl diBjb3N0IG1vbmV5KS4gQXMgeW91IG1lbnRpb25lZCwgb3BlcmF0aW9uIG9mIGJveGVzIGlzIHRv ZGF5IGEga2V5IGRpZmZlcmVudGlhdG9yIHdoZW4gY2hvb3NpbmcgYSB2ZW5kb3IuIA0KV2UgY2xl YXJseSB0aGlzIGRpdmVyZ2VuY2UgdG9kYXkgaW4gcHJvZHVjZWQgWWFuZyBtb2RlbCAob3BlcmF0 b3IgYXV0aG9ycyBtb2RlbHMgdnMgdmVuZG9yIGF1dGhvcnMgbW9kZWwpDQoNCkFzIGEgc2Vydmlj ZSBwcm92aWRlciwgSSdtIGNsZWFybHkgcHVzaGluZyB0byB1c2Ugb25seSBzdGFuZGFyZCBtb2Rl bCBhdCBsZWFzdCBmb3IgbW9zdCBvZiB0aGUgYmFzZSBzdHJ1Y3R1cmUgb2Ygc2VydmljZXMgYW5k IEkgd2lsbCBwdXNoIG15IHZlbmRvcnMgdG8gc3VwcG9ydCBpdCBhcyBtb3JlIGFzIHBvc3NpYmxl LiBJIHdvdWxkIHNheSB0aGF0IG1vcmUgdGhhbiA5MCUgb2YgcGFyYW1ldGVycyBvZiBhIHNlcnZp Y2UgYXJlIGNvbW1vbiB0byBhbGwgaW1wbGVtZW50YXRpb25zIChqdXN0IGRldGFpbHMgYXJlIGNo YW5naW5nICA6IGxvY2FsaXphdGlvbiBvZiB0aGUgY29uZmlnIHN0YXRlbWVudCBvciBncmFudWxh cml0eSBvZiB0aGUgcGFyYW1ldGVyKS4gU28gSSB0aGluayB0aGF0IGNyZWF0aW5nIHVzYWJsZSBz dGFuZGFyZCBtb2RlbCBjYW4gd29yay4gVGhlIHJlbWFpbmluZyB4JSBjYW4gYmUgYWRkcmVzc2Vk IGJ5IHZlbmRvciBleHRlbnNpb25zLg0KDQpDb21pbmcgYmFjayB0byByb3V0aW5nIHBvbGljaWVz LiBJIGRvIHRoaW5rIHRoYXQgcmVzdGFydGluZyBhIG5ldyBmcmFtZXdvcmsgZnJvbSBzdHJhdGNo IGlzIHRoZSByaWdodCB3YXkgdG8gZG8gaXQuIEFuZCBhcyBhbnkgcHJvdG9jb2wgZXh0ZW5zaW9u IG9yIGZlYXR1cmUgc3RhbmRhcmRpemVkIGluIElFVEYsIGl0IHdpbGwgYmUgdXAgdG8gY3VzdG9t ZXJzIHRvIHJlcXVlc3QgdGhlaXIgdmVuZG9ycyBmb3IgaW1wbGVtZW50YXRpb25zLg0KDQpUb2Rh eSByb3V0aW5nIHBvbGljeSBtYW5hZ2VtZW50IGJldHdlZW4gZGlmZmVyZW50IHZlbmRvcnMgaXMg Y3JhenkuIENvbnNpZGVyIHlvdSBoYXZlIGEgVmVuZG9yIFggbmV0d29yayB3aXRoIHdpZGVseSBk ZXBsb3llZCBjb21wbGV4IHJvdXRpbmcgcG9saWNpZXMsIGFuZCB5b3Ugd2FudCB0byBpbnRyb2R1 Y2UgdG8gdmVuZG9yIFksIHRyYW5zbGF0aW9uIG9mIHJvdXRpbmcgcG9saWNpZXMgZnJvbSBsYW5n dWFnZSBYIHRvIFkgaXMgYSB2ZXJ5IGNvbXBsZXggd29yay4gDQoNCk1vcmVvdmVyIHdlIGNhbiBz ZWUgdGhhdCBmcmFtZXdvcmsgb2YgcG9saWN5IG1vZGVsIGlzIGFscmVhZHkgZXhpc3RpbmcgZm9y IGludGVybmV0IHJlZ2lzdHJpZXMgdXNpbmcgUlBTTC4NCg0KSSBkbyBub3Qga25vdyB0b2RheSB3 aGVyZSB0aGlzIFlhbmcgaW5pdGlhdGl2ZSB3aWxsIGdvIC4uLiBidXQgSSB3aWxsIHByb25lIGEg Y29uc2Vuc3VzIG9uIHN0cm9uZyBhZG9wdGlvbiBvZiBzdGFuZGFyZCBZQU5HIG1vZGVscyByYXRo ZXIgdGhhbiB2ZW5kb3Igc3BlY2lmaWMgb25seS4NCg0KDQpTdGVwaGFuZQ0KIA0KIA0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRv OnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogRnJp ZGF5LCBEZWNlbWJlciAxOSwgMjAxNCAxMToxMA0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0Uv SUJORg0KQ2M6IEplZmYgVGFudHN1cmE7IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5v dmljOyBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgTGFkaXNsYXYgTGhvdGthDQpTdWJqZWN0OiBS ZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0ZXJzDQoNCkhpIFN0ZXBo YW5lLA0KDQpUaGF0IGlzIGdvaW5nIHRvIGJlIHZlcnkgaW50ZXJlc3RpbmcgaW5kZWVkLiBDb25z aWRlcmluZyB0aGF0IG51bWJlciBvZiBjdXN0b21lcnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWlsbGlv bnMgZm9yIGN1c3RvbWl6ZWQgZXh0ZW5zaW9ucyBhbmQgb25seSBzb21lIG9mIHRoZW0gbWFkZSBp dCB0byBJRVRGIGRyYWZ0cy9yZmNzLg0KDQpTbyB3aGF0IHdpbGwgbW9zdCBsaWtlbHkgaGFwcGVu IGlzIGdlbmVyYWwgWUFORyBtb2RlbCBvZiBub3QgbXVjaCB1c2UgYW5kIHpvbyBvZiBwcm9wcmll dGFyeSB2ZW5kb3IgWUFORyBleHRlbnNpb25zIG5vdCBjb21wYXRpYmxlIGJldHdlZW4gaW1wbGVt ZW50YXRpb25zLg0KDQpJcyB0aGlzIHJlYWxseSB3aGVyZSB3ZSB3YW50IHRvIGdvIHdpdGggdGhp cyBlbnRpcmUgZWZmb3J0ID8NCg0KQmVzdCwNCnIuDQoNCg0KT24gRnJpLCBEZWMgMTksIDIwMTQg YXQgMTE6MDMgQU0sICA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IHdyb3RlOg0KPiBI aSwNCj4NCj4gSSB0aGluayB3b3JraW5nIG9mIEJHUCBZQU5HIGlzIGEgZ29vZCBvcHBvcnR1bml0 eSB0byBzdGFydCB3b3JraW5nIG9uIHBvbGljeSBmcmFtZXdvcmsuDQo+IFdvcmsgb24gcHJvdG9j b2xzIFlBTkcgaXMgYWxyZWFkeSBoYXJkIGR1ZSB0byB2ZW5kb3IgY29uZmlnIGRpc3ByZWNhbmNp ZXMsIEkgZXhwZWN0IHBvbGljeSB3b3JrIHRvIGJlIG11Y2ggaGFyZGVyIC4uLg0KPg0KPiBCdXQg SSB0aGluaywgdGhlcmUgaXMgYW4gb3Bwb3J0dW5pdHkgdG8gc3RhcnQgc29tZXRoaW5nIG5ldyBm b3IgZXZlcnlvbmUgKHRoYXQgbWF5IGNvZXhpc3Qgd2l0aCBleGlzdGluZyBDTEkgcG9saWNpZXMp IGFuZCBub3QgbG9va2luZyBhdCBDTEkgdHJhbnNsYXRpb24gKGl0IHdpbGwgYmUgaW1wb3NzaWJs ZSB3aXRoIHBvbGljaWVzKS4gVGhlbiBpdCB3b3VsZCBiZSB1cCB0byBzZXJ2aWNlIHByb3ZpZGVy cyB0byByZXF1ZXN0IHRoZSBzdXBwb3J0IG9mIHRoaXMgYnkgdGhlaXIgZmF2b3JpdGUgdmVuZG9y cy4NCj4NCj4gQmVzdCBSZWdhcmRzLA0KPg0KPiBTdGVwaGFuZQ0KPg0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IA0KPiBSYXN6dWsNCj4gU2VudDogV2Vk bmVzZGF5LCBEZWNlbWJlciAxNywgMjAxNCAyMzoyOA0KPiBUbzogSmVmZiBUYW50c3VyYQ0KPiBD YzogQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJvZ2Rhbm92aWM7IHJ0Zy15YW5nLWNvb3JkQGll dGYub3JnOyANCj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBMYWRpc2xhdiBMaG90a2EN Cj4gU3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVy cw0KPg0KPiBTbyBhcmUgeW91IHNheWluZyB0aGF0IGZvcm1hbCBZQU5HIHNwZWNpZmljYXRpb24g c2F5IGZvciBCR1AgYnkgZGVzaWduIHdpbGwgbm90IGJlIGNvbXBhdGlibGUgd2l0aCBzb21lIGlt cGxlbWVudGF0aW9ucyA/DQo+DQo+IE9yIGFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9ybWFsIGRlc2ln biBzYXkgb2YgQkdQIHByb3RvY29sIHdpbGwgaGF2ZSB0byB3YWl0IGZldyB5ZWFycyB0aWxsIFlB TkcgZm9yIHBvbGljeSBzcGVjIGlzIGNvbXBsZXRlID8NCj4NCj4gQ2hlZXJzLA0KPiByLg0KPg0K PiBPbiBXZWQsIERlYyAxNywgMjAxNCBhdCAxMToxNCBQTSwgSmVmZiBUYW50c3VyYSA8amVmZi50 YW50c3VyYUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gWWVzLCBleGFjdGx5LCBSb2JlcnQgLSB0 aGUgYmVoYXZpb3IgeW91IGhhdmUgZGVzY3JpYmVkIGlzIGFuIGltcGxlbWVudGF0aW9uLCBub3Qg YSBmb3JtYWwgc3BlY2lmaWNhdGlvbi4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gSmVmZg0KPj4NCj4+ PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDI6MTIgUE0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBj aXNjby5jb20+IHdyb3RlOg0KPj4+DQo+Pj4gV2h5IGlzIHRoaXMgYSBwcm9ibGVtIGlmIHRoZSBk ZWZhdWx0IGlzIHRvIG5vdCB0byByZWRpc3RyaWJ1dGUgcm91dGVzIGJldHdlZW4gUklCcz8gTm90 ZSB0aGF0IGl0IGlzbuKAmXQgbGlrZSB3ZSBoYXZlIGEgc2V0IG9mIGFwcHJvdmVkIHJvdXRpbmcg cHJvdG9jb2wgbW9kZWxzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiB0aGlzIGJlaGF2aW9yLg0KPj4+ IEFjZWUNCj4+Pg0KPj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDU6MDcgUE0sIERlYW4gQm9nZGFu b3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+Pg0KPj4+PiBSb2JlcnQsDQo+Pj4+ DQo+Pj4+IFlvdXIgcHJvcG9zYWwgaXMgdmVyeSBzZW5zaWJsZSBhbmQgSSB0aGluayB0aGlzIGlz IHRoZSBiZXN0IG9wdGlvbg0KPj4+Pg0KPj4+PiBEZWFuDQo+Pj4+DQo+Pj4+PiBPbiBEZWMgMTcs IDIwMTQsIGF0IDQ6NDkgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PiB3cm90 ZToNCj4+Pj4+DQo+Pj4+PiBEZWFuLCBhbGwNCj4+Pj4+DQo+Pj4+PiBUaGUgd2F5IEkgcmVhZCBp dCBjdXJyZW50bHkgaW4gc2VjdGlvbiA1LjUgdGhlcmUgYXJlIG9ubHkgdHdvIA0KPj4+Pj4gcm91 dGUgZmlsdGVycyBwcm9wb3NlZCAoZGVueS1hbGwgb3IgYWxsb3ctYWxsKS4gQXMgd2Uga25vdyBz b21lIA0KPj4+Pj4gcm91dGluZyBwcm90b2NvbHMgcmVxdWlyZSBleHBsaWNpdCBwZXJtaXNzaW9u IHRvIG9wZXJhdGUgKGV4YW1wbGU6IEVCR1ApLg0KPj4+Pj4gSWYgd2UgcmVtb3ZlIGV2ZW4gdGhv c2UgdHdvIHByaW1pdGl2ZSBmaWx0ZXJzIHRoZXJlIGNhbiBiZSBpbXBhY3QgDQo+Pj4+PiB0byBv dGhlciBjb21wb25lbnRzLg0KPj4+Pj4NCj4+Pj4+IEJ1dCBJIGRvIHN1cHBvcnQgYSBzZXBhcmF0 ZSB3b3JrIGZvciBZQU5HIG1vZGVsIGZvciBwb2xpY3kuIEkgZG8gDQo+Pj4+PiBleHBlY3QgdGhp cyB0byBiZSBhIHZlcnkgaW50ZXJlc3RpbmcgYW5kIGludm9sdmVkIHdvcmsgY29uc2lkZXJpbmcg DQo+Pj4+PiBzaWduaWZpY2FudCBkaXZlcnNpdHkgb2YgcG9saWN5IGxhbmd1YWdlcyBhY3Jvc3Mg YWxsIA0KPj4+Pj4gaW1wbGVtZW50YXRpb25zIHRvZGF5Lg0KPj4+Pj4NCj4+Pj4+IE9uY2UgdGhh dCB3b3JrIGlzIGRvbmUgd2UgY291bGQgcmV0aXJlIHNlY3Rpb24gNS41IG9mDQo+Pj4+PiAqLW5l dG1vZC1yb3V0aW5nLSoNCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4gci4NCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDEwOjA5IFBNLCBEZWFuIEJvZ2Rh bm92aWMgPGRlYW5iQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+Pj4+PiBJJ20gaW4gc3VwcG9ydCBv ZiByZW1vdmluZyByb3V0ZSBmaWx0ZXJzIGZyb20gdGhlIHJvdXRpbmcgY2ZnIG1vZGVsLiBSb3V0 ZSBmaWx0ZXJzIHNob3VsZCBiZSBJTU8gcGFydCBvZiB0aGUgcG9saWN5IG1vZGVsLCBpbiB3aGlj aCBhbHNvIEFDTCBtb2RlbCBiZWxvbmdzIHRvby4gQWN0dWFsbHksIEkgd291bGQgYXJndWUgdGhh dCB0aGUgY3VycmVudCBBQ0wgbW9kZWwgaXMgdmVyeSBzdWl0YWJsZSBmb3Igcm91dGUgZmlsdGVy cy4NCj4+Pj4+Pg0KPj4+Pj4+IERlYW4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gUnRnLXlhbmctY29vcmQgbWFpbGluZyBs aXN0DQo+Pj4+IFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4+Pg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPg0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCANCj4gZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSANCj4gcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLg0KPg0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCj4NCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Dec 19 04:00:58 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9313D1A913A for ; Fri, 19 Dec 2014 04:00:56 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeT0oSXx7kcG for ; Fri, 19 Dec 2014 04:00:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94F51A8F50 for ; Fri, 19 Dec 2014 04:00:49 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4E2743B4120; Fri, 19 Dec 2014 13:00:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 08C982380FC; Fri, 19 Dec 2014 13:00:48 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.149]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 19 Dec 2014 13:00:47 +0100 From: To: LITKOWSKI Stephane SCE/IBNF , Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwA== Date: Fri, 19 Dec 2014 12:00:47 +0000 Message-ID: <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.112421 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/AKlPYUMqdJoYGYwYF2OBsE3YWCo Cc: "rtg-yang-coord@ietf.org" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 12:00:57 -0000 QW5kIHF1ZXN0aW9uIDogV2hvIGlzIGludGVyZXN0ZWQgdG8gc3RhcnQgbm93IHRoZSB3b3JrIG9u IHN0YW5kYXJkIHJvdXRpbmcgcG9saWN5ID8NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogUnRnLXlhbmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20NClNlbnQ6 IEZyaWRheSwgRGVjZW1iZXIgMTksIDIwMTQgMTI6NTkNClRvOiBSb2JlcnQgUmFzenVrDQpDYzog cnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5v dmljOyBKZWZmIFRhbnRzdXJhOyBMYWRpc2xhdiBMaG90a2ENClN1YmplY3Q6IFJlOiBbUnRnLXlh bmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCg0KUm9iZXJ0LA0KDQpZb3UgYXJl IHRvdWNoaW5nIGFuIGludGVyZXN0aW5nIHBvaW50IDopIEluIGZhY3QgdGhlcmUgYXJlIHR3byB3 YXlzIG9mIHZpZXdpbmcgdGhpbmtzIDoNCi0gc2VydmljZSBwcm92aWRlcnMvY3VzdG9tZXJzIHdo byB3b3VsZCBsaWtlIHRvIHVzZSBvbmx5IHN0YW5kYXJkIG1vZGVscyB0byBmYWNpbGl0YXRlIG5l dHdvcmsgcHJvdmlzaW9uICYgb3BlcmF0aW9uDQotIHZlbmRvcnMgd2hvIG1heSBub3Qgd2FudCB0 byBtYWtlIGRldmVsb3BtZW50IHRvIGltcGxlbWVudCBuZXcgZmVhdHVyZXMgdG8gYmUgY29tcGxp YW50IHdpdGggYSBzdGFuZGFyZCB5YW5nIG1vZGVsICAoYXMgZGV2IGNvc3QgbW9uZXkpLiBBcyB5 b3UgbWVudGlvbmVkLCBvcGVyYXRpb24gb2YgYm94ZXMgaXMgdG9kYXkgYSBrZXkgZGlmZmVyZW50 aWF0b3Igd2hlbiBjaG9vc2luZyBhIHZlbmRvci4gDQpXZSBjbGVhcmx5IHRoaXMgZGl2ZXJnZW5j ZSB0b2RheSBpbiBwcm9kdWNlZCBZYW5nIG1vZGVsIChvcGVyYXRvciBhdXRob3JzIG1vZGVscyB2 cyB2ZW5kb3IgYXV0aG9ycyBtb2RlbCkNCg0KQXMgYSBzZXJ2aWNlIHByb3ZpZGVyLCBJJ20gY2xl YXJseSBwdXNoaW5nIHRvIHVzZSBvbmx5IHN0YW5kYXJkIG1vZGVsIGF0IGxlYXN0IGZvciBtb3N0 IG9mIHRoZSBiYXNlIHN0cnVjdHVyZSBvZiBzZXJ2aWNlcyBhbmQgSSB3aWxsIHB1c2ggbXkgdmVu ZG9ycyB0byBzdXBwb3J0IGl0IGFzIG1vcmUgYXMgcG9zc2libGUuIEkgd291bGQgc2F5IHRoYXQg bW9yZSB0aGFuIDkwJSBvZiBwYXJhbWV0ZXJzIG9mIGEgc2VydmljZSBhcmUgY29tbW9uIHRvIGFs bCBpbXBsZW1lbnRhdGlvbnMgKGp1c3QgZGV0YWlscyBhcmUgY2hhbmdpbmcgIDogbG9jYWxpemF0 aW9uIG9mIHRoZSBjb25maWcgc3RhdGVtZW50IG9yIGdyYW51bGFyaXR5IG9mIHRoZSBwYXJhbWV0 ZXIpLiBTbyBJIHRoaW5rIHRoYXQgY3JlYXRpbmcgdXNhYmxlIHN0YW5kYXJkIG1vZGVsIGNhbiB3 b3JrLiBUaGUgcmVtYWluaW5nIHglIGNhbiBiZSBhZGRyZXNzZWQgYnkgdmVuZG9yIGV4dGVuc2lv bnMuDQoNCkNvbWluZyBiYWNrIHRvIHJvdXRpbmcgcG9saWNpZXMuIEkgZG8gdGhpbmsgdGhhdCBy ZXN0YXJ0aW5nIGEgbmV3IGZyYW1ld29yayBmcm9tIHN0cmF0Y2ggaXMgdGhlIHJpZ2h0IHdheSB0 byBkbyBpdC4gQW5kIGFzIGFueSBwcm90b2NvbCBleHRlbnNpb24gb3IgZmVhdHVyZSBzdGFuZGFy ZGl6ZWQgaW4gSUVURiwgaXQgd2lsbCBiZSB1cCB0byBjdXN0b21lcnMgdG8gcmVxdWVzdCB0aGVp ciB2ZW5kb3JzIGZvciBpbXBsZW1lbnRhdGlvbnMuDQoNClRvZGF5IHJvdXRpbmcgcG9saWN5IG1h bmFnZW1lbnQgYmV0d2VlbiBkaWZmZXJlbnQgdmVuZG9ycyBpcyBjcmF6eS4gQ29uc2lkZXIgeW91 IGhhdmUgYSBWZW5kb3IgWCBuZXR3b3JrIHdpdGggd2lkZWx5IGRlcGxveWVkIGNvbXBsZXggcm91 dGluZyBwb2xpY2llcywgYW5kIHlvdSB3YW50IHRvIGludHJvZHVjZSB0byB2ZW5kb3IgWSwgdHJh bnNsYXRpb24gb2Ygcm91dGluZyBwb2xpY2llcyBmcm9tIGxhbmd1YWdlIFggdG8gWSBpcyBhIHZl cnkgY29tcGxleCB3b3JrLiANCg0KTW9yZW92ZXIgd2UgY2FuIHNlZSB0aGF0IGZyYW1ld29yayBv ZiBwb2xpY3kgbW9kZWwgaXMgYWxyZWFkeSBleGlzdGluZyBmb3IgaW50ZXJuZXQgcmVnaXN0cmll cyB1c2luZyBSUFNMLg0KDQpJIGRvIG5vdCBrbm93IHRvZGF5IHdoZXJlIHRoaXMgWWFuZyBpbml0 aWF0aXZlIHdpbGwgZ28gLi4uIGJ1dCBJIHdpbGwgcHJvbmUgYSBjb25zZW5zdXMgb24gc3Ryb25n IGFkb3B0aW9uIG9mIHN0YW5kYXJkIFlBTkcgbW9kZWxzIHJhdGhlciB0aGFuIHZlbmRvciBzcGVj aWZpYyBvbmx5Lg0KDQoNClN0ZXBoYW5lDQogDQogDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21d IE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDE5LCAy MDE0IDExOjEwDQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogSmVmZiBUYW50 c3VyYTsgQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJvZ2Rhbm92aWM7IHJ0Zy15YW5nLWNvb3Jk QGlldGYub3JnOyBMYWRpc2xhdiBMaG90a2ENClN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRd IGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCg0KSGkgU3RlcGhhbmUsDQoNClRoYXQgaXMgZ29p bmcgdG8gYmUgdmVyeSBpbnRlcmVzdGluZyBpbmRlZWQuIENvbnNpZGVyaW5nIHRoYXQgbnVtYmVy IG9mIGN1c3RvbWVycyBoYXZlIHBhaWQgdmVuZG9ycyBtaWxsaW9ucyBmb3IgY3VzdG9taXplZCBl eHRlbnNpb25zIGFuZCBvbmx5IHNvbWUgb2YgdGhlbSBtYWRlIGl0IHRvIElFVEYgZHJhZnRzL3Jm Y3MuDQoNClNvIHdoYXQgd2lsbCBtb3N0IGxpa2VseSBoYXBwZW4gaXMgZ2VuZXJhbCBZQU5HIG1v ZGVsIG9mIG5vdCBtdWNoIHVzZSBhbmQgem9vIG9mIHByb3ByaWV0YXJ5IHZlbmRvciBZQU5HIGV4 dGVuc2lvbnMgbm90IGNvbXBhdGlibGUgYmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMuDQoNCklzIHRo aXMgcmVhbGx5IHdoZXJlIHdlIHdhbnQgdG8gZ28gd2l0aCB0aGlzIGVudGlyZSBlZmZvcnQgPw0K DQpCZXN0LA0Kci4NCg0KDQpPbiBGcmksIERlYyAxOSwgMjAxNCBhdCAxMTowMyBBTSwgIDxzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+IEhpLA0KPg0KPiBJIHRoaW5rIHdv cmtpbmcgb2YgQkdQIFlBTkcgaXMgYSBnb29kIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHdvcmtpbmcg b24gcG9saWN5IGZyYW1ld29yay4NCj4gV29yayBvbiBwcm90b2NvbHMgWUFORyBpcyBhbHJlYWR5 IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWcgZGlzcHJlY2FuY2llcywgSSBleHBlY3QgcG9saWN5 IHdvcmsgdG8gYmUgbXVjaCBoYXJkZXIgLi4uDQo+DQo+IEJ1dCBJIHRoaW5rLCB0aGVyZSBpcyBh biBvcHBvcnR1bml0eSB0byBzdGFydCBzb21ldGhpbmcgbmV3IGZvciBldmVyeW9uZSAodGhhdCBt YXkgY29leGlzdCB3aXRoIGV4aXN0aW5nIENMSSBwb2xpY2llcykgYW5kIG5vdCBsb29raW5nIGF0 IENMSSB0cmFuc2xhdGlvbiAoaXQgd2lsbCBiZSBpbXBvc3NpYmxlIHdpdGggcG9saWNpZXMpLiBU aGVuIGl0IHdvdWxkIGJlIHVwIHRvIHNlcnZpY2UgcHJvdmlkZXJzIHRvIHJlcXVlc3QgdGhlIHN1 cHBvcnQgb2YgdGhpcyBieSB0aGVpciBmYXZvcml0ZSB2ZW5kb3JzLg0KPg0KPiBCZXN0IFJlZ2Fy ZHMsDQo+DQo+IFN0ZXBoYW5lDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJl aGFsZiBPZiBSb2JlcnQgDQo+IFJhc3p1aw0KPiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE3 LCAyMDE0IDIzOjI4DQo+IFRvOiBKZWZmIFRhbnRzdXJhDQo+IENjOiBBY2VlIExpbmRlbSAoYWNl ZSk7IERlYW4gQm9nZGFub3ZpYzsgcnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IA0KPiBMSVRLT1dT S0kgU3RlcGhhbmUgU0NFL0lCTkY7IExhZGlzbGF2IExob3RrYQ0KPiBTdWJqZWN0OiBSZTogW1J0 Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0ZXJzDQo+DQo+IFNvIGFyZSB5b3Ug c2F5aW5nIHRoYXQgZm9ybWFsIFlBTkcgc3BlY2lmaWNhdGlvbiBzYXkgZm9yIEJHUCBieSBkZXNp Z24gd2lsbCBub3QgYmUgY29tcGF0aWJsZSB3aXRoIHNvbWUgaW1wbGVtZW50YXRpb25zID8NCj4N Cj4gT3IgYXJlIHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwgZGVzaWduIHNheSBvZiBCR1AgcHJvdG9j b2wgd2lsbCBoYXZlIHRvIHdhaXQgZmV3IHllYXJzIHRpbGwgWUFORyBmb3IgcG9saWN5IHNwZWMg aXMgY29tcGxldGUgPw0KPg0KPiBDaGVlcnMsDQo+IHIuDQo+DQo+IE9uIFdlZCwgRGVjIDE3LCAy MDE0IGF0IDExOjE0IFBNLCBKZWZmIFRhbnRzdXJhIDxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNv bT4gd3JvdGU6DQo+PiBZZXMsIGV4YWN0bHksIFJvYmVydCAtIHRoZSBiZWhhdmlvciB5b3UgaGF2 ZSBkZXNjcmliZWQgaXMgYW4gaW1wbGVtZW50YXRpb24sIG5vdCBhIGZvcm1hbCBzcGVjaWZpY2F0 aW9uLg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBKZWZmDQo+Pg0KPj4+IE9uIERlYyAxNywgMjAxNCwg YXQgMjoxMiBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ Pj4NCj4+PiBXaHkgaXMgdGhpcyBhIHByb2JsZW0gaWYgdGhlIGRlZmF1bHQgaXMgdG8gbm90IHRv IHJlZGlzdHJpYnV0ZSByb3V0ZXMgYmV0d2VlbiBSSUJzPyBOb3RlIHRoYXQgaXQgaXNu4oCZdCBs aWtlIHdlIGhhdmUgYSBzZXQgb2YgYXBwcm92ZWQgcm91dGluZyBwcm90b2NvbCBtb2RlbHMgdGhh dCBhcmUgZGVwZW5kZW50IG9uIHRoaXMgYmVoYXZpb3IuDQo+Pj4gQWNlZQ0KPj4+DQo+Pj4+IE9u IERlYyAxNywgMjAxNCwgYXQgNTowNyBQTSwgRGVhbiBCb2dkYW5vdmljIDxkZWFuYkBqdW5pcGVy Lm5ldD4gd3JvdGU6DQo+Pj4+DQo+Pj4+IFJvYmVydCwNCj4+Pj4NCj4+Pj4gWW91ciBwcm9wb3Nh bCBpcyB2ZXJ5IHNlbnNpYmxlIGFuZCBJIHRoaW5rIHRoaXMgaXMgdGhlIGJlc3Qgb3B0aW9uDQo+ Pj4+DQo+Pj4+IERlYW4NCj4+Pj4NCj4+Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNDo0OSBQTSwg Um9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IERl YW4sIGFsbA0KPj4+Pj4NCj4+Pj4+IFRoZSB3YXkgSSByZWFkIGl0IGN1cnJlbnRseSBpbiBzZWN0 aW9uIDUuNSB0aGVyZSBhcmUgb25seSB0d28gDQo+Pj4+PiByb3V0ZSBmaWx0ZXJzIHByb3Bvc2Vk IChkZW55LWFsbCBvciBhbGxvdy1hbGwpLiBBcyB3ZSBrbm93IHNvbWUgDQo+Pj4+PiByb3V0aW5n IHByb3RvY29scyByZXF1aXJlIGV4cGxpY2l0IHBlcm1pc3Npb24gdG8gb3BlcmF0ZSAoZXhhbXBs ZTogRUJHUCkuDQo+Pj4+PiBJZiB3ZSByZW1vdmUgZXZlbiB0aG9zZSB0d28gcHJpbWl0aXZlIGZp bHRlcnMgdGhlcmUgY2FuIGJlIGltcGFjdCANCj4+Pj4+IHRvIG90aGVyIGNvbXBvbmVudHMuDQo+ Pj4+Pg0KPj4+Pj4gQnV0IEkgZG8gc3VwcG9ydCBhIHNlcGFyYXRlIHdvcmsgZm9yIFlBTkcgbW9k ZWwgZm9yIHBvbGljeS4gSSBkbyANCj4+Pj4+IGV4cGVjdCB0aGlzIHRvIGJlIGEgdmVyeSBpbnRl cmVzdGluZyBhbmQgaW52b2x2ZWQgd29yayBjb25zaWRlcmluZyANCj4+Pj4+IHNpZ25pZmljYW50 IGRpdmVyc2l0eSBvZiBwb2xpY3kgbGFuZ3VhZ2VzIGFjcm9zcyBhbGwgDQo+Pj4+PiBpbXBsZW1l bnRhdGlvbnMgdG9kYXkuDQo+Pj4+Pg0KPj4+Pj4gT25jZSB0aGF0IHdvcmsgaXMgZG9uZSB3ZSBj b3VsZCByZXRpcmUgc2VjdGlvbiA1LjUgb2YNCj4+Pj4+ICotbmV0bW9kLXJvdXRpbmctKg0KPj4+ Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiByLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4gT24gV2Vk LCBEZWMgMTcsIDIwMTQgYXQgMTA6MDkgUE0sIERlYW4gQm9nZGFub3ZpYyA8ZGVhbmJAanVuaXBl ci5uZXQ+IHdyb3RlOg0KPj4+Pj4+IEknbSBpbiBzdXBwb3J0IG9mIHJlbW92aW5nIHJvdXRlIGZp bHRlcnMgZnJvbSB0aGUgcm91dGluZyBjZmcgbW9kZWwuIFJvdXRlIGZpbHRlcnMgc2hvdWxkIGJl IElNTyBwYXJ0IG9mIHRoZSBwb2xpY3kgbW9kZWwsIGluIHdoaWNoIGFsc28gQUNMIG1vZGVsIGJl bG9uZ3MgdG9vLiBBY3R1YWxseSwgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSBjdXJyZW50IEFDTCBt b2RlbCBpcyB2ZXJ5IHN1aXRhYmxlIGZvciByb3V0ZSBmaWx0ZXJzLg0KPj4+Pj4+DQo+Pj4+Pj4g RGVhbg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+PiBSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+Pj4gUnRnLXlhbmct Y29vcmRAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGcteWFuZy1jb29yZA0KPj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IENlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyAN Cj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFz IGV0cmUgZGlmZnVzZXMsIA0KPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+ IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciANCj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBh IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5 b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpS dGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNClJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LgpUaGFuayB5b3UuCgo= From nobody Fri Dec 19 06:09:10 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A31A88A5 for ; Fri, 19 Dec 2014 06:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPJlOyqAAuka for ; Fri, 19 Dec 2014 06:09:03 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7E91A88BC for ; Fri, 19 Dec 2014 06:08:59 -0800 (PST) Received: by mail-yk0-f179.google.com with SMTP id 19so397462ykq.10 for ; Fri, 19 Dec 2014 06:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CU9r6oH1MxisyojRnep4k/eeQJ2h92raLh3VYUckbow=; b=V7sf9CquE0zdiffTjbcZqmYTVkbpkpVpjYlmRB58c/lAP9KSei3f+9NWIESsuI/fou lmycLvKW/OmxGnQ4F49yUKw567fZf5i597UDfECVgQM4KRRok3e1jHr8dTHjKUIp0WOi MhW8Vikl/gGyU7wEZxXcEfHbo42qicOSAs+tOSSbRCDmXEEsXNxOFmB7k622kKBm/yVx rGDkNCk+V1uRPocROqWA1MJwYWyEB9Mlh7xE7JXincmNfUxkW3gtM/chdgv6d2eVBz1g HmXcogugw7MGmNheP6cnHtZybQgoNTjE/+uni19bSa6wHp+sIZZwxiZtP4Qdm8s+g1nv 9GUQ== MIME-Version: 1.0 X-Received: by 10.236.109.7 with SMTP id r7mr6341222yhg.107.1418998139146; Fri, 19 Dec 2014 06:08:59 -0800 (PST) Received: by 10.170.136.132 with HTTP; Fri, 19 Dec 2014 06:08:59 -0800 (PST) In-Reply-To: <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> Date: Fri, 19 Dec 2014 09:08:59 -0500 Message-ID: From: Alia Atlas To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c2c596055837050a92400f Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/0Sn6Ke0hN1uDGJZH6Kzk2an-ssY Cc: "Rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 14:09:06 -0000 --001a11c2c596055837050a92400f Content-Type: text/plain; charset=UTF-8 Juergen, It sounds like the lack of floating point is a gap. For values such as bandwidth, we do need to express rather wide ranges. I do agree that fixed point can work well - but that is not what is configured or carried in the protocols. In particular, given that converting to/from fixed-point may not give the same starting values, the lack of support seems like it will cause difficulties and confusion. Alia On Fri, Dec 19, 2014 at 5:08 AM, t.petch wrote: > ----- Original Message ----- > From: "Alia Atlas" > To: "t.petch" > Cc: > Sent: Thursday, December 18, 2014 6:38 PM > > > Tom, > > > > On Thu, Dec 18, 2014 at 1:05 PM, t.petch wrote: > > > > > > > > ----- Original Message ----- > > > From: "Alia Atlas" > > > To: > > > Sent: Thursday, December 18, 2014 4:28 PM > > > > > > > Are there routing YANG models that are running into concerns > around > > > > floating point? > > > > > > Alia > > > > > > 24Apr14 netmod WG list Robert Varga > > > "while modeling some protocols (notably RSVP), we came across the > need > > > to represent IEEE754-2008 floating types without losing precision. > I'd > > > like > > > to ask what is the group's sentiment regarding extending the base > types > > > with at least binary{32,64} (which have their counterparts in XML > schema > > > datatypes)." > > > > > > which suggests that the answer is yes. > > > > > > > Indeed it does. Assuming these TE extensions are modeled, there'll be > at > > least > > 4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE. > > ... to which might be added IDR's flow spec (RFC5575) along with > GMPLS's ted-mib (which cites RFC6340 - but I expect that that is your > OSPF and ISIS) > > Historically, MEF's CIR has been expressed in floating point but I don't > think that that is part of current CCAMP work. > > Tom Petch > > > > I might have posed a slightly different question, such as - does > > > anyone outside a few on the netmod WG list realise that YANG has no > > > support for floating point, just decimal-64? > > > > > > > If they didn't before, they should be aware now. > > > > Alia > > --001a11c2c596055837050a92400f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

It sounds like the lack of flo= ating point is a gap.

For values such as bandwidth= , we do need to express rather wide ranges.
I do agree that fixed= point can work well - but that is not what is configured
or carr= ied in the protocols. =C2=A0

In particular, g= iven that converting to/from fixed-point may not give
the same st= arting values, the lack of support seems like it will
cause diffi= culties and confusion.

Alia

On Fri, Dec 19, 2014 a= t 5:08 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Alia Atlas" <akatl= as@gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: <Rtg-yang-coord@ietf.org<= /a>>
Sent: Thursday, December 18, 2014 6:38 PM

> Tom,
>
> On Thu, Dec 18, 2014 at 1:05 PM, t.petch <ietfc@btconnect.com> wrote:
>
> >
> > ----- Original Message -----
> > From: "Alia Atlas" <akatlas@gmail.com>
> > To: <Rtg-yang-coord= @ietf.org>
> > Sent: Thursday, December 18, 2014 4:28 PM
> >
> > > Are there routing YANG models that are running into concerns=
around
> > > floating point?
> >
> > Alia
> >
> > 24Apr14 netmod WG list Robert Varga
> > "while modeling some protocols (notably RSVP), we came acros= s the
need
> > to represent IEEE754-2008 floating types without losing precision= .
I'd
> > like
> > to ask what is the group's sentiment regarding extending the = base
types
> > with at least binary{32,64} (which have their counterparts in XML=
schema
> > datatypes)."
> >
> > which suggests that the answer is yes.
> >
>
> Indeed it does.=C2=A0 Assuming these TE extensions are modeled, there&= #39;ll be
at
> least
> 4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE.

...=C2=A0 to which might be added IDR's flow spec (RFC5575)= along with
GMPLS's ted-mib (which cites RFC6340 - but I expect that that is your OSPF and ISIS)

Historically, MEF's CIR has been expressed in floating point but I don&= #39;t
think that that is part of current CCAMP work.

Tom Petch

> > I might have posed a slightly different question, such as - does<= br> > > anyone outside a few on the netmod WG list realise that YANG has = no
> > support for floating point, just decimal-64?
> >
>
> If they didn't before, they should be aware now.
>
> Alia


--001a11c2c596055837050a92400f-- From nobody Fri Dec 19 08:11:21 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC6C1A00FE for ; Fri, 19 Dec 2014 08:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uecnnXdw_JeU for ; Fri, 19 Dec 2014 08:11:19 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05851A6F9B for ; Fri, 19 Dec 2014 08:11:18 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so1093421lab.27 for ; Fri, 19 Dec 2014 08:11:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wFj8MWRv/PduyoKni4DX5Le9TD4VZGNKmRivmn3hrNI=; b=U0LI6YvN5R06rwnpWcRoKJWJN4Is0ET40aOxlZ1Q3pb9RIfxEc6tGZZuRQbbZXXMg1 ICSoBc04f6gNYjbl/UTUa8xBooWMP/2PUujyke3MEwWN0UroKyxD5ko7spQ3yfrD6DYa BqMTscP/AscK+FfKVFxzDEGCkHvLHfDD03sx1D6V6yeBfADEj/aIgQBUz8dNGzqcJ67x L3dX2vVcG6Pn5cXaUyXe1o8/dJA8iZz2kecV6cKCECTC256KGFaoauWu8p7j7OGA9lrx V2eKNTQoboDLXuKaEbd1w3jKTaS5EpCKS7O+MKCFKoHl8FY7M8PyboexjXJnZpiX9r1y zZbA== X-Gm-Message-State: ALoCoQmVVJBcYSIVGWtxvU2MnIUKaD/GlpaqsmbTXVWb2KdHgF1bF/uJ2kthkA/t67RDS+krYoyU MIME-Version: 1.0 X-Received: by 10.152.87.142 with SMTP id ay14mr8599840lab.45.1419005477303; Fri, 19 Dec 2014 08:11:17 -0800 (PST) Received: by 10.112.157.233 with HTTP; Fri, 19 Dec 2014 08:11:17 -0800 (PST) In-Reply-To: References: <018b01d014ce$06215290$1263f7b0$@olddog.co.uk> <07ae01d01636$ac853340$4001a8c0@gateway.2wire.net> <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> Date: Fri, 19 Dec 2014 08:11:17 -0800 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/GMZwu8eUCxoji5g0OiePxx4qNac Cc: "Rtg-yang-coord@ietf.org" , "t.petch" Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:11:20 -0000 On Fri, Dec 19, 2014 at 6:08 AM, Alia Atlas wrote: > Juergen, > > It sounds like the lack of floating point is a gap. > > For values such as bandwidth, we do need to express rather wide ranges. > I do agree that fixed point can work well - but that is not what is > configured > or carried in the protocols. > > In particular, given that converting to/from fixed-point may not give > the same starting values, the lack of support seems like it will > cause difficulties and confusion. > http://www.ietf.org/mail-archive/web/netmod/current/msg02685.html This describes a typedef replacement for float that was discussed in the NETMOD WG in 2009. > Alia Andy > > On Fri, Dec 19, 2014 at 5:08 AM, t.petch wrote: >> >> ----- Original Message ----- >> From: "Alia Atlas" >> To: "t.petch" >> Cc: >> Sent: Thursday, December 18, 2014 6:38 PM >> >> > Tom, >> > >> > On Thu, Dec 18, 2014 at 1:05 PM, t.petch wrote: >> > >> > > >> > > ----- Original Message ----- >> > > From: "Alia Atlas" >> > > To: >> > > Sent: Thursday, December 18, 2014 4:28 PM >> > > >> > > > Are there routing YANG models that are running into concerns >> around >> > > > floating point? >> > > >> > > Alia >> > > >> > > 24Apr14 netmod WG list Robert Varga >> > > "while modeling some protocols (notably RSVP), we came across the >> need >> > > to represent IEEE754-2008 floating types without losing precision. >> I'd >> > > like >> > > to ask what is the group's sentiment regarding extending the base >> types >> > > with at least binary{32,64} (which have their counterparts in XML >> schema >> > > datatypes)." >> > > >> > > which suggests that the answer is yes. >> > > >> > >> > Indeed it does. Assuming these TE extensions are modeled, there'll be >> at >> > least >> > 4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE. >> >> ... to which might be added IDR's flow spec (RFC5575) along with >> GMPLS's ted-mib (which cites RFC6340 - but I expect that that is your >> OSPF and ISIS) >> >> Historically, MEF's CIR has been expressed in floating point but I don't >> think that that is part of current CCAMP work. >> >> Tom Petch >> >> > > I might have posed a slightly different question, such as - does >> > > anyone outside a few on the netmod WG list realise that YANG has no >> > > support for floating point, just decimal-64? >> > > >> > >> > If they didn't before, they should be aware now. >> > >> > Alia >> > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Fri Dec 19 08:12:42 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F681A701F for ; Fri, 19 Dec 2014 08:12:29 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0D2LiesV_hy for ; Fri, 19 Dec 2014 08:12:25 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB84C1A6FAA for ; Fri, 19 Dec 2014 08:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10192; q=dns/txt; s=iport; t=1419005545; x=1420215145; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sgzCc2LuvcfDhRapzbp7TiVmtuVH0U3zM9SCh8HezxY=; b=GxOhT9vUQ71OIZx2bhBScg1iLn7kiKYgEx+l40nyQzR5Q9FPNbCLwdSf +tgOo2+fOo1oIwgg77fydOgpftr4b6DFpByRgO4nuEe27gSjRq0s303o2 8ooHCwIvozqINuREhKZwHvGyv8lyo4InoWj91ORUgleJ1nvq8YxCjyCB5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIFADFNlFStJA2B/2dsb2JhbABagwZSWATGFwqFcQKBHBYBAQEBAX2EDAEBAQQBAQFrCwwEAgEIEQQBAQEnByEGCxQJCAIEAQ0FiBgDEQ3LEw2FPwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEigqDQIFGEQFQBwaEIwWJHIRxhy6BRIENgmKCM4VSghuDOSKDbm+BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,607,1413244800"; d="scan'208";a="106954026" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 19 Dec 2014 16:12:24 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBJGCOux006512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 16:12:24 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 10:12:24 -0600 From: "Acee Lindem (acee)" To: "stephane.litkowski@orange.com" , "Robert Raszuk" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4IAAZ1oAgAAeTgCAAACXgP//8nkA Date: Fri, 19 Dec 2014 16:12:24 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/gqkTCytqMlKHT1n6ZZ2woc6dg_o Cc: "rtg-yang-coord@ietf.org" , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:12:30 -0000 I would like to be involved. Thanks, Acee=20 On 12/19/14, 7:00 AM, "stephane.litkowski@orange.com" wrote: >And question : Who is interested to start now the work on standard >routing policy ? > > >-----Original Message----- >From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf >Of stephane.litkowski@orange.com >Sent: Friday, December 19, 2014 12:59 >To: Robert Raszuk >Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff >Tantsura; Ladislav Lhotka >Subject: Re: [Rtg-yang-coord] issue :R01: route filters > >Robert, > >You are touching an interesting point :) In fact there are two ways of >viewing thinks : >- service providers/customers who would like to use only standard models >to facilitate network provision & operation >- vendors who may not want to make development to implement new features >to be compliant with a standard yang model (as dev cost money). As you >mentioned, operation of boxes is today a key differentiator when choosing >a vendor.=20 >We clearly this divergence today in produced Yang model (operator authors >models vs vendor authors model) > >As a service provider, I'm clearly pushing to use only standard model at >least for most of the base structure of services and I will push my >vendors to support it as more as possible. I would say that more than 90% >of parameters of a service are common to all implementations (just >details are changing : localization of the config statement or >granularity of the parameter). So I think that creating usable standard >model can work. The remaining x% can be addressed by vendor extensions. > >Coming back to routing policies. I do think that restarting a new >framework from stratch is the right way to do it. And as any protocol >extension or feature standardized in IETF, it will be up to customers to >request their vendors for implementations. > >Today routing policy management between different vendors is crazy. >Consider you have a Vendor X network with widely deployed complex routing >policies, and you want to introduce to vendor Y, translation of routing >policies from language X to Y is a very complex work. > >Moreover we can see that framework of policy model is already existing >for internet registries using RPSL. > >I do not know today where this Yang initiative will go ... but I will >prone a consensus on strong adoption of standard YANG models rather than >vendor specific only. > > >Stephane >=20 >=20 > > >-----Original Message----- >From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >Raszuk >Sent: Friday, December 19, 2014 11:10 >To: LITKOWSKI Stephane SCE/IBNF >Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic; >rtg-yang-coord@ietf.org; Ladislav Lhotka >Subject: Re: [Rtg-yang-coord] issue :R01: route filters > >Hi Stephane, > >That is going to be very interesting indeed. Considering that number of >customers have paid vendors millions for customized extensions and only >some of them made it to IETF drafts/rfcs. > >So what will most likely happen is general YANG model of not much use and >zoo of proprietary vendor YANG extensions not compatible between >implementations. > >Is this really where we want to go with this entire effort ? > >Best, >r. > > >On Fri, Dec 19, 2014 at 11:03 AM, wrote: >> Hi, >> >> I think working of BGP YANG is a good opportunity to start working on >>policy framework. >> Work on protocols YANG is already hard due to vendor config >>disprecancies, I expect policy work to be much harder ... >> >> But I think, there is an opportunity to start something new for >>everyone (that may coexist with existing CLI policies) and not looking >>at CLI translation (it will be impossible with policies). Then it would >>be up to service providers to request the support of this by their >>favorite vendors. >> >> Best Regards, >> >> Stephane >> >> >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Wednesday, December 17, 2014 23:28 >> To: Jeff Tantsura >> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; >> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >> >> So are you saying that formal YANG specification say for BGP by design >>will not be compatible with some implementations ? >> >> Or are you saying that formal design say of BGP protocol will have to >>wait few years till YANG for policy spec is complete ? >> >> Cheers, >> r. >> >> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura >> wrote: >>> Yes, exactly, Robert - the behavior you have described is an >>>implementation, not a formal specification. >>> >>> Regards, >>> Jeff >>> >>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) >>>>wrote: >>>> >>>> Why is this a problem if the default is to not to redistribute routes >>>>between RIBs? Note that it isn=B9t like we have a set of approved >>>>routing protocol models that are dependent on this behavior. >>>> Acee >>>> >>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic >>>>>wrote: >>>>> >>>>> Robert, >>>>> >>>>> Your proposal is very sensible and I think this is the best option >>>>> >>>>> Dean >>>>> >>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk >>>>>>wrote: >>>>>> >>>>>> Dean, all >>>>>> >>>>>> The way I read it currently in section 5.5 there are only two >>>>>> route filters proposed (deny-all or allow-all). As we know some >>>>>> routing protocols require explicit permission to operate (example: >>>>>>EBGP). >>>>>> If we remove even those two primitive filters there can be impact >>>>>> to other components. >>>>>> >>>>>> But I do support a separate work for YANG model for policy. I do >>>>>> expect this to be a very interesting and involved work considering >>>>>> significant diversity of policy languages across all >>>>>> implementations today. >>>>>> >>>>>> Once that work is done we could retire section 5.5 of >>>>>> *-netmod-routing-* >>>>>> >>>>>> Regards, >>>>>> r. >>>>>> >>>>>> >>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic >>>>>>> wrote: >>>>>>> I'm in support of removing route filters from the routing cfg >>>>>>>model. Route filters should be IMO part of the policy model, in >>>>>>>which also ACL model belongs too. Actually, I would argue that the >>>>>>>current ACL model is very suitable for route filters. >>>>>>> >>>>>>> Dean >>>>> >>>>> _______________________________________________ >>>>> Rtg-yang-coord mailing list >>>>> Rtg-yang-coord@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>> >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>que les pieces jointes. Les messages electroniques etant susceptibles >>d'alteration, Orange decline toute responsabilite si ce message a ete >>altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be >>distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >>delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been modified, changed or falsified. >> Thank you. >> > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >exploites ou copies sans autorisation. Si vous avez recu ce message par >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les >pieces jointes. Les messages electroniques etant susceptibles >d'alteration, Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; they should not be distributed, >used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > >_______________________________________________ >Rtg-yang-coord mailing list >Rtg-yang-coord@ietf.org >https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > From nobody Fri Dec 19 08:19:10 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D941A879C for ; Fri, 19 Dec 2014 08:19:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM2BjXKpXOik for ; Fri, 19 Dec 2014 08:19:03 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15BF1A895D for ; Fri, 19 Dec 2014 08:19:02 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 19 Dec 2014 16:19:00 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.217]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.217]) with mapi id 15.01.0031.000; Fri, 19 Dec 2014 16:18:59 +0000 From: Dean Bogdanovic To: "Acee Lindem (acee)" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFqvvyajyxwZEG8ZV6J8cb4/5ySQhKAgAEq6ICAAP0CAIAAC2GAgAAE9ICAAAFRAIAAALEAgAADy4CAAlSsgIAAAcYAgAAeTgCAAACYgIAARk0AgAAB1gA= Date: Fri, 19 Dec 2014 16:18:59 +0000 Message-ID: <1B6DA539-B7C4-4021-A8E8-6F852FE889F5@juniper.net> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(479174004)(24454002)(199003)(164054003)(51444003)(189002)(68736005)(120916001)(561944003)(21056001)(106356001)(36756003)(40100003)(122556002)(31966008)(4396001)(66066001)(110136001)(57306001)(99286002)(87936001)(106116001)(105586002)(89996001)(62966003)(92566001)(102836002)(93886004)(99396003)(20776003)(77156002)(19580405001)(50226001)(86362001)(33656002)(97736003)(64706001)(50986999)(83716003)(76176999)(101416001)(230783001)(46102003)(82746002)(107046002)(15975445007)(2950100001)(19580395003)(2900100001)(2656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <041255C92B4C4C4092050DB735236770@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/xV_YqmSr9YBWQSR2IITAyx9MF10 Cc: "rtg-yang-coord@ietf.org" , "stephane.litkowski@orange.com" , Jeff Tantsura , Robert Raszuk , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:19:09 -0000 I would like to be involved as well :-) On Dec 19, 2014, at 11:12 AM, "Acee Lindem (acee)" wrote: > I would like to be involved. > Thanks, > Acee=20 >=20 > On 12/19/14, 7:00 AM, "stephane.litkowski@orange.com" > wrote: >=20 >> And question : Who is interested to start now the work on standard >> routing policy ? >>=20 >>=20 >> -----Original Message----- >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf >> Of stephane.litkowski@orange.com >> Sent: Friday, December 19, 2014 12:59 >> To: Robert Raszuk >> Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff >> Tantsura; Ladislav Lhotka >> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>=20 >> Robert, >>=20 >> You are touching an interesting point :) In fact there are two ways of >> viewing thinks : >> - service providers/customers who would like to use only standard models >> to facilitate network provision & operation >> - vendors who may not want to make development to implement new features >> to be compliant with a standard yang model (as dev cost money). As you >> mentioned, operation of boxes is today a key differentiator when choosin= g >> a vendor.=20 >> We clearly this divergence today in produced Yang model (operator author= s >> models vs vendor authors model) >>=20 >> As a service provider, I'm clearly pushing to use only standard model at >> least for most of the base structure of services and I will push my >> vendors to support it as more as possible. I would say that more than 90= % >> of parameters of a service are common to all implementations (just >> details are changing : localization of the config statement or >> granularity of the parameter). So I think that creating usable standard >> model can work. The remaining x% can be addressed by vendor extensions. >>=20 >> Coming back to routing policies. I do think that restarting a new >> framework from stratch is the right way to do it. And as any protocol >> extension or feature standardized in IETF, it will be up to customers to >> request their vendors for implementations. >>=20 >> Today routing policy management between different vendors is crazy. >> Consider you have a Vendor X network with widely deployed complex routin= g >> policies, and you want to introduce to vendor Y, translation of routing >> policies from language X to Y is a very complex work. >>=20 >> Moreover we can see that framework of policy model is already existing >> for internet registries using RPSL. >>=20 >> I do not know today where this Yang initiative will go ... but I will >> prone a consensus on strong adoption of standard YANG models rather than >> vendor specific only. >>=20 >>=20 >> Stephane >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Friday, December 19, 2014 11:10 >> To: LITKOWSKI Stephane SCE/IBNF >> Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic; >> rtg-yang-coord@ietf.org; Ladislav Lhotka >> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>=20 >> Hi Stephane, >>=20 >> That is going to be very interesting indeed. Considering that number of >> customers have paid vendors millions for customized extensions and only >> some of them made it to IETF drafts/rfcs. >>=20 >> So what will most likely happen is general YANG model of not much use an= d >> zoo of proprietary vendor YANG extensions not compatible between >> implementations. >>=20 >> Is this really where we want to go with this entire effort ? >>=20 >> Best, >> r. >>=20 >>=20 >> On Fri, Dec 19, 2014 at 11:03 AM, wrote= : >>> Hi, >>>=20 >>> I think working of BGP YANG is a good opportunity to start working on >>> policy framework. >>> Work on protocols YANG is already hard due to vendor config >>> disprecancies, I expect policy work to be much harder ... >>>=20 >>> But I think, there is an opportunity to start something new for >>> everyone (that may coexist with existing CLI policies) and not looking >>> at CLI translation (it will be impossible with policies). Then it would >>> be up to service providers to request the support of this by their >>> favorite vendors. >>>=20 >>> Best Regards, >>>=20 >>> Stephane >>>=20 >>>=20 >>> -----Original Message----- >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>> Raszuk >>> Sent: Wednesday, December 17, 2014 23:28 >>> To: Jeff Tantsura >>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; >>> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>>=20 >>> So are you saying that formal YANG specification say for BGP by design >>> will not be compatible with some implementations ? >>>=20 >>> Or are you saying that formal design say of BGP protocol will have to >>> wait few years till YANG for policy spec is complete ? >>>=20 >>> Cheers, >>> r. >>>=20 >>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura >>> wrote: >>>> Yes, exactly, Robert - the behavior you have described is an >>>> implementation, not a formal specification. >>>>=20 >>>> Regards, >>>> Jeff >>>>=20 >>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) >>>>> wrote: >>>>>=20 >>>>> Why is this a problem if the default is to not to redistribute routes >>>>> between RIBs? Note that it isn=B9t like we have a set of approved >>>>> routing protocol models that are dependent on this behavior. >>>>> Acee >>>>>=20 >>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic >>>>>> wrote: >>>>>>=20 >>>>>> Robert, >>>>>>=20 >>>>>> Your proposal is very sensible and I think this is the best option >>>>>>=20 >>>>>> Dean >>>>>>=20 >>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk >>>>>>> wrote: >>>>>>>=20 >>>>>>> Dean, all >>>>>>>=20 >>>>>>> The way I read it currently in section 5.5 there are only two >>>>>>> route filters proposed (deny-all or allow-all). As we know some >>>>>>> routing protocols require explicit permission to operate (example: >>>>>>> EBGP). >>>>>>> If we remove even those two primitive filters there can be impact >>>>>>> to other components. >>>>>>>=20 >>>>>>> But I do support a separate work for YANG model for policy. I do >>>>>>> expect this to be a very interesting and involved work considering >>>>>>> significant diversity of policy languages across all >>>>>>> implementations today. >>>>>>>=20 >>>>>>> Once that work is done we could retire section 5.5 of >>>>>>> *-netmod-routing-* >>>>>>>=20 >>>>>>> Regards, >>>>>>> r. >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic >>>>>>>> wrote: >>>>>>>> I'm in support of removing route filters from the routing cfg >>>>>>>> model. Route filters should be IMO part of the policy model, in >>>>>>>> which also ACL model belongs too. Actually, I would argue that the >>>>>>>> current ACL model is very suitable for route filters. >>>>>>>>=20 >>>>>>>> Dean >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Rtg-yang-coord mailing list >>>>>> Rtg-yang-coord@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>>=20 >>>=20 >>> ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>> que les pieces jointes. Les messages electroniques etant susceptibles >>> d'alteration, Orange decline toute responsabilite si ce message a ete >>> altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be >>> distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>> been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >> ________________________________________________________________________= __ >> _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message par >> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les >> pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; they should not be distributed= , >> used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >> ________________________________________________________________________= __ >> _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >>=20 >=20 From nobody Fri Dec 19 08:27:32 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B191A89EB for ; Fri, 19 Dec 2014 08:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClhbOFAGGA6h for ; Fri, 19 Dec 2014 08:27:26 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870EE1A89C4 for ; Fri, 19 Dec 2014 08:27:26 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so902602igj.4 for ; Fri, 19 Dec 2014 08:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Bw0gIId0Ax/srvXiGR2pQJfFcY2B6wRgBE48rcYWQTg=; b=yKiWMV49uRV0zFO1DLFZ60/F5TQMogUzVInXoJMBRxou9qgsRRXdWysqZooMD3nj1Y gkADGCodVfv7gf3zOAyhfoSnUdoj8IaQpcetKFCsKxWJU6HDlaLtJjyarOfLKR/Lfn1j vBBQlSrpDO4gy2rFEpu5g/UtlLGDso4eNop+kosiLOU49cgcwpitlwRCP6UR1Cxo06Cs c5OJRRnQc3DJ6+Il9vaghprE7Mh43wdyBO0kwGDcqaFRezhsAhP/dnGQbZoG3lpFQT20 iVvL0u6SE4KvTXIsYrYweTeB8vFgTB9ueiNKbtbq/QboJwCos3R7AhCV0544HM+IbOdN M0XA== MIME-Version: 1.0 X-Received: by 10.107.165.75 with SMTP id o72mr7938261ioe.33.1419006445600; Fri, 19 Dec 2014 08:27:25 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.152.130 with HTTP; Fri, 19 Dec 2014 08:27:25 -0800 (PST) In-Reply-To: <1B6DA539-B7C4-4021-A8E8-6F852FE889F5@juniper.net> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> <1B6DA539-B7C4-4021-A8E8-6F852FE889F5@juniper.net> Date: Fri, 19 Dec 2014 17:27:25 +0100 X-Google-Sender-Auth: lPY3LWQ8Ox7xF9a97GqSOXM-FX0 Message-ID: From: Robert Raszuk To: Dean Bogdanovic Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/YT7EiWgfV6470nchXhTJG8EPQwY Cc: "rtg-yang-coord@ietf.org" , "stephane.litkowski@orange.com" , "Acee Lindem \(acee\)" , Ladislav Lhotka , Jeff Tantsura Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:27:29 -0000 Looks like a dream crew already ... +1 :) r. On Fri, Dec 19, 2014 at 5:18 PM, Dean Bogdanovic wrote: > I would like to be involved as well :-) > > On Dec 19, 2014, at 11:12 AM, "Acee Lindem (acee)" > wrote: > >> I would like to be involved. >> Thanks, >> Acee >> >> On 12/19/14, 7:00 AM, "stephane.litkowski@orange.com" >> wrote: >> >>> And question : Who is interested to start now the work on standard >>> routing policy ? >>> >>> >>> -----Original Message----- >>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf >>> Of stephane.litkowski@orange.com >>> Sent: Friday, December 19, 2014 12:59 >>> To: Robert Raszuk >>> Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff >>> Tantsura; Ladislav Lhotka >>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>> >>> Robert, >>> >>> You are touching an interesting point :) In fact there are two ways of >>> viewing thinks : >>> - service providers/customers who would like to use only standard model= s >>> to facilitate network provision & operation >>> - vendors who may not want to make development to implement new feature= s >>> to be compliant with a standard yang model (as dev cost money). As you >>> mentioned, operation of boxes is today a key differentiator when choosi= ng >>> a vendor. >>> We clearly this divergence today in produced Yang model (operator autho= rs >>> models vs vendor authors model) >>> >>> As a service provider, I'm clearly pushing to use only standard model a= t >>> least for most of the base structure of services and I will push my >>> vendors to support it as more as possible. I would say that more than 9= 0% >>> of parameters of a service are common to all implementations (just >>> details are changing : localization of the config statement or >>> granularity of the parameter). So I think that creating usable standard >>> model can work. The remaining x% can be addressed by vendor extensions. >>> >>> Coming back to routing policies. I do think that restarting a new >>> framework from stratch is the right way to do it. And as any protocol >>> extension or feature standardized in IETF, it will be up to customers t= o >>> request their vendors for implementations. >>> >>> Today routing policy management between different vendors is crazy. >>> Consider you have a Vendor X network with widely deployed complex routi= ng >>> policies, and you want to introduce to vendor Y, translation of routing >>> policies from language X to Y is a very complex work. >>> >>> Moreover we can see that framework of policy model is already existing >>> for internet registries using RPSL. >>> >>> I do not know today where this Yang initiative will go ... but I will >>> prone a consensus on strong adoption of standard YANG models rather tha= n >>> vendor specific only. >>> >>> >>> Stephane >>> >>> >>> >>> >>> -----Original Message----- >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>> Raszuk >>> Sent: Friday, December 19, 2014 11:10 >>> To: LITKOWSKI Stephane SCE/IBNF >>> Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic; >>> rtg-yang-coord@ietf.org; Ladislav Lhotka >>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>> >>> Hi Stephane, >>> >>> That is going to be very interesting indeed. Considering that number of >>> customers have paid vendors millions for customized extensions and only >>> some of them made it to IETF drafts/rfcs. >>> >>> So what will most likely happen is general YANG model of not much use a= nd >>> zoo of proprietary vendor YANG extensions not compatible between >>> implementations. >>> >>> Is this really where we want to go with this entire effort ? >>> >>> Best, >>> r. >>> >>> >>> On Fri, Dec 19, 2014 at 11:03 AM, wrot= e: >>>> Hi, >>>> >>>> I think working of BGP YANG is a good opportunity to start working on >>>> policy framework. >>>> Work on protocols YANG is already hard due to vendor config >>>> disprecancies, I expect policy work to be much harder ... >>>> >>>> But I think, there is an opportunity to start something new for >>>> everyone (that may coexist with existing CLI policies) and not looking >>>> at CLI translation (it will be impossible with policies). Then it woul= d >>>> be up to service providers to request the support of this by their >>>> favorite vendors. >>>> >>>> Best Regards, >>>> >>>> Stephane >>>> >>>> >>>> -----Original Message----- >>>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>>> Raszuk >>>> Sent: Wednesday, December 17, 2014 23:28 >>>> To: Jeff Tantsura >>>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; >>>> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >>>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>>> >>>> So are you saying that formal YANG specification say for BGP by design >>>> will not be compatible with some implementations ? >>>> >>>> Or are you saying that formal design say of BGP protocol will have to >>>> wait few years till YANG for policy spec is complete ? >>>> >>>> Cheers, >>>> r. >>>> >>>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura >>>> wrote: >>>>> Yes, exactly, Robert - the behavior you have described is an >>>>> implementation, not a formal specification. >>>>> >>>>> Regards, >>>>> Jeff >>>>> >>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) >>>>>> wrote: >>>>>> >>>>>> Why is this a problem if the default is to not to redistribute route= s >>>>>> between RIBs? Note that it isn=C2=B9t like we have a set of approved >>>>>> routing protocol models that are dependent on this behavior. >>>>>> Acee >>>>>> >>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic >>>>>>> wrote: >>>>>>> >>>>>>> Robert, >>>>>>> >>>>>>> Your proposal is very sensible and I think this is the best option >>>>>>> >>>>>>> Dean >>>>>>> >>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk >>>>>>>> wrote: >>>>>>>> >>>>>>>> Dean, all >>>>>>>> >>>>>>>> The way I read it currently in section 5.5 there are only two >>>>>>>> route filters proposed (deny-all or allow-all). As we know some >>>>>>>> routing protocols require explicit permission to operate (example: >>>>>>>> EBGP). >>>>>>>> If we remove even those two primitive filters there can be impact >>>>>>>> to other components. >>>>>>>> >>>>>>>> But I do support a separate work for YANG model for policy. I do >>>>>>>> expect this to be a very interesting and involved work considering >>>>>>>> significant diversity of policy languages across all >>>>>>>> implementations today. >>>>>>>> >>>>>>>> Once that work is done we could retire section 5.5 of >>>>>>>> *-netmod-routing-* >>>>>>>> >>>>>>>> Regards, >>>>>>>> r. >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic >>>>>>>>> wrote: >>>>>>>>> I'm in support of removing route filters from the routing cfg >>>>>>>>> model. Route filters should be IMO part of the policy model, in >>>>>>>>> which also ACL model belongs too. Actually, I would argue that th= e >>>>>>>>> current ACL model is very suitable for route filters. >>>>>>>>> >>>>>>>>> Dean >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtg-yang-coord mailing list >>>>>>> Rtg-yang-coord@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>>> >>>> >>>> ______________________________________________________________________ >>>> ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>>> que les pieces jointes. Les messages electroniques etant susceptibles >>>> d'alteration, Orange decline toute responsabilite si ce message a ete >>>> altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e >>>> distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and >>>> delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have >>>> been modified, changed or falsified. >>>> Thank you. >>>> >>> >>> _______________________________________________________________________= ___ >>> _______________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message par >>> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que le= s >>> pieces jointes. Les messages electroniques etant susceptibles >>> d'alteration, Orange decline toute responsabilite si ce message a ete >>> altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; they should not be distribute= d, >>> used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>> been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> >>> _______________________________________________________________________= ___ >>> _______________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s >>> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme >>> ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>> been modified, changed or falsified. >>> Thank you. >>> >> > From nobody Fri Dec 19 13:36:12 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BD01AC3D2 for ; Fri, 19 Dec 2014 13:36:12 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O8AOofaJPYl for ; Fri, 19 Dec 2014 13:36:09 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E15B1AC3F4 for ; Fri, 19 Dec 2014 13:36:06 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-b3-549449610e0e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 91.0A.03307.16944945; Fri, 19 Dec 2014 16:50:57 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 16:35:57 -0500 From: Jeff Tantsura To: "Acee Lindem (acee)" , "stephane.litkowski@orange.com" , Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFq3DAI1iR4rkSO5UpxSSPkb5ySleSAgADXF9+AAVDYAIAAC1uAgAAE9YCAAAFRAP//rN+ngABXnYCAAlSsgIAAAcYAgAAeTgCAAACXgIAARk4A///UR4A= Date: Fri, 19 Dec 2014 21:35:56 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="euc-kr" Content-ID: <2C887E4A69AFEA4C916B39A0F745DD10@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyuXRPoG6i55QQg53rFSwmv53HbPG4fQ6z xYVVc9ksmhY2MVv8fn6b2eLr3oesDmweU35vZPVYsuQnk8f1pqvsHpsu32H0aHl2ks1j98YF TAFsUVw2Kak5mWWpRfp2CVwZv5tPsBccKqjY1bufpYHxQm4XIyeHhICJxO952xghbDGJC/fW s3UxcnEICRxhlGiYd4YJwlnOKLFr7SUmkCo2AQOJ/9+Os4AkRAT6GSWOt75lBkkwC9RLHN/8 GGyUsIC5RMeP3WBxEQELiR//zrBBNHQxSlw89A6oiIODRUBV4ss3J5AaXqD6z2+3skNsm8Eh sWzOZLBmTgFtiZ3tPWCbGYHu+35qDRPEMnGJW0/mM0HcLSCxZM95ZghbVOLl43+sILaogJ7E sw2b2SHiShJzXl+DOlRL4suPfWwQtrXEth+zGSFsRYkp3Q/ZIQ4SlDg58wnLBEaJWUjWzULS PgtJ+ywk7bOQtC9gZF3FyFFanFqWm25ksIkRGMPHJNh0dzDueWl5iFGAg1GJh9dAZXKIEGti WXFl7iFGaQ4WJXHeWbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwitiGZa3Wz2D2W5e3 aOubfXMnmVVUJMW03a3q6T5jZ/SzVcwxvpPNizOgyF+sSycl8kdXPOf1IzH8NwKOZMvtuvjq M+eVz3xuL7JCGeZwdW0RnHU3XNLIt/yUp5rqjz69Hqne9ux+rwshSSFxaVI/S1fd3fPVNcRs +/Y3msu0KziWB3+0O6fEUpyRaKjFXFScCABq6ARewgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/vO1-bzdj6d_TbwtNlAdHG8OK0n0 Cc: "rtg-yang-coord@ietf.org" , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 21:36:12 -0000 SaGvZCBsaWtlIHRvIGJlIGludm9sdmVkLCBhcyB3ZWxsIGFzIGdpdmluZyBpdCBhIGhvbWUgaW4g cnRnd2cNCg0KQ2hlZXJzLA0KSmVmZg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KDQo+DQo+T24gMTIvMTkvMTQsIDc6MDAgQU0sICJzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbSINCj48c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IHdyb3RlOg0KPg0KPj5BbmQg cXVlc3Rpb24gOiBXaG8gaXMgaW50ZXJlc3RlZCB0byBzdGFydCBub3cgdGhlIHdvcmsgb24gc3Rh bmRhcmQNCj4+cm91dGluZyBwb2xpY3kgPw0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PkZyb206IFJ0Zy15YW5nLWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pk9mIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tDQo+PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTksIDIwMTQgMTI6NTkNCj4+VG86IFJvYmVy dCBSYXN6dWsNCj4+Q2M6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBBY2VlIExpbmRlbSAoYWNl ZSk7IERlYW4gQm9nZGFub3ZpYzsgSmVmZg0KPj5UYW50c3VyYTsgTGFkaXNsYXYgTGhvdGthDQo+ PlN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMN Cj4+DQo+PlJvYmVydCwNCj4+DQo+PllvdSBhcmUgdG91Y2hpbmcgYW4gaW50ZXJlc3RpbmcgcG9p bnQgOikgSW4gZmFjdCB0aGVyZSBhcmUgdHdvIHdheXMgb2YNCj4+dmlld2luZyB0aGlua3MgOg0K Pj4tIHNlcnZpY2UgcHJvdmlkZXJzL2N1c3RvbWVycyB3aG8gd291bGQgbGlrZSB0byB1c2Ugb25s eSBzdGFuZGFyZCBtb2RlbHMNCj4+dG8gZmFjaWxpdGF0ZSBuZXR3b3JrIHByb3Zpc2lvbiAmIG9w ZXJhdGlvbg0KPj4tIHZlbmRvcnMgd2hvIG1heSBub3Qgd2FudCB0byBtYWtlIGRldmVsb3BtZW50 IHRvIGltcGxlbWVudCBuZXcgZmVhdHVyZXMNCj4+dG8gYmUgY29tcGxpYW50IHdpdGggYSBzdGFu ZGFyZCB5YW5nIG1vZGVsICAoYXMgZGV2IGNvc3QgbW9uZXkpLiBBcyB5b3UNCj4+bWVudGlvbmVk LCBvcGVyYXRpb24gb2YgYm94ZXMgaXMgdG9kYXkgYSBrZXkgZGlmZmVyZW50aWF0b3Igd2hlbiBj aG9vc2luZw0KPj5hIHZlbmRvci4gDQo+PldlIGNsZWFybHkgdGhpcyBkaXZlcmdlbmNlIHRvZGF5 IGluIHByb2R1Y2VkIFlhbmcgbW9kZWwgKG9wZXJhdG9yIGF1dGhvcnMNCj4+bW9kZWxzIHZzIHZl bmRvciBhdXRob3JzIG1vZGVsKQ0KPj4NCj4+QXMgYSBzZXJ2aWNlIHByb3ZpZGVyLCBJJ20gY2xl YXJseSBwdXNoaW5nIHRvIHVzZSBvbmx5IHN0YW5kYXJkIG1vZGVsIGF0DQo+PmxlYXN0IGZvciBt b3N0IG9mIHRoZSBiYXNlIHN0cnVjdHVyZSBvZiBzZXJ2aWNlcyBhbmQgSSB3aWxsIHB1c2ggbXkN Cj4+dmVuZG9ycyB0byBzdXBwb3J0IGl0IGFzIG1vcmUgYXMgcG9zc2libGUuIEkgd291bGQgc2F5 IHRoYXQgbW9yZSB0aGFuIDkwJQ0KPj5vZiBwYXJhbWV0ZXJzIG9mIGEgc2VydmljZSBhcmUgY29t bW9uIHRvIGFsbCBpbXBsZW1lbnRhdGlvbnMgKGp1c3QNCj4+ZGV0YWlscyBhcmUgY2hhbmdpbmcg IDogbG9jYWxpemF0aW9uIG9mIHRoZSBjb25maWcgc3RhdGVtZW50IG9yDQo+PmdyYW51bGFyaXR5 IG9mIHRoZSBwYXJhbWV0ZXIpLiBTbyBJIHRoaW5rIHRoYXQgY3JlYXRpbmcgdXNhYmxlIHN0YW5k YXJkDQo+Pm1vZGVsIGNhbiB3b3JrLiBUaGUgcmVtYWluaW5nIHglIGNhbiBiZSBhZGRyZXNzZWQg YnkgdmVuZG9yIGV4dGVuc2lvbnMuDQo+Pg0KPj5Db21pbmcgYmFjayB0byByb3V0aW5nIHBvbGlj aWVzLiBJIGRvIHRoaW5rIHRoYXQgcmVzdGFydGluZyBhIG5ldw0KPj5mcmFtZXdvcmsgZnJvbSBz dHJhdGNoIGlzIHRoZSByaWdodCB3YXkgdG8gZG8gaXQuIEFuZCBhcyBhbnkgcHJvdG9jb2wNCj4+ ZXh0ZW5zaW9uIG9yIGZlYXR1cmUgc3RhbmRhcmRpemVkIGluIElFVEYsIGl0IHdpbGwgYmUgdXAg dG8gY3VzdG9tZXJzIHRvDQo+PnJlcXVlc3QgdGhlaXIgdmVuZG9ycyBmb3IgaW1wbGVtZW50YXRp b25zLg0KPj4NCj4+VG9kYXkgcm91dGluZyBwb2xpY3kgbWFuYWdlbWVudCBiZXR3ZWVuIGRpZmZl cmVudCB2ZW5kb3JzIGlzIGNyYXp5Lg0KPj5Db25zaWRlciB5b3UgaGF2ZSBhIFZlbmRvciBYIG5l dHdvcmsgd2l0aCB3aWRlbHkgZGVwbG95ZWQgY29tcGxleCByb3V0aW5nDQo+PnBvbGljaWVzLCBh bmQgeW91IHdhbnQgdG8gaW50cm9kdWNlIHRvIHZlbmRvciBZLCB0cmFuc2xhdGlvbiBvZiByb3V0 aW5nDQo+PnBvbGljaWVzIGZyb20gbGFuZ3VhZ2UgWCB0byBZIGlzIGEgdmVyeSBjb21wbGV4IHdv cmsuDQo+Pg0KPj5Nb3Jlb3ZlciB3ZSBjYW4gc2VlIHRoYXQgZnJhbWV3b3JrIG9mIHBvbGljeSBt b2RlbCBpcyBhbHJlYWR5IGV4aXN0aW5nDQo+PmZvciBpbnRlcm5ldCByZWdpc3RyaWVzIHVzaW5n IFJQU0wuDQo+Pg0KPj5JIGRvIG5vdCBrbm93IHRvZGF5IHdoZXJlIHRoaXMgWWFuZyBpbml0aWF0 aXZlIHdpbGwgZ28gLi4uIGJ1dCBJIHdpbGwNCj4+cHJvbmUgYSBjb25zZW5zdXMgb24gc3Ryb25n IGFkb3B0aW9uIG9mIHN0YW5kYXJkIFlBTkcgbW9kZWxzIHJhdGhlciB0aGFuDQo+PnZlbmRvciBz cGVjaWZpYyBvbmx5Lg0KPj4NCj4+DQo+PlN0ZXBoYW5lDQo+PiANCj4+IA0KPj4NCj4+DQo+Pi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWls dG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQNCj4+UmFzenVrDQo+PlNl bnQ6IEZyaWRheSwgRGVjZW1iZXIgMTksIDIwMTQgMTE6MTANCj4+VG86IExJVEtPV1NLSSBTdGVw aGFuZSBTQ0UvSUJORg0KPj5DYzogSmVmZiBUYW50c3VyYTsgQWNlZSBMaW5kZW0gKGFjZWUpOyBE ZWFuIEJvZ2Rhbm92aWM7DQo+PnJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBMYWRpc2xhdiBMaG90 a2ENCj4+U3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmls dGVycw0KPj4NCj4+SGkgU3RlcGhhbmUsDQo+Pg0KPj5UaGF0IGlzIGdvaW5nIHRvIGJlIHZlcnkg aW50ZXJlc3RpbmcgaW5kZWVkLiBDb25zaWRlcmluZyB0aGF0IG51bWJlciBvZg0KPj5jdXN0b21l cnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWlsbGlvbnMgZm9yIGN1c3RvbWl6ZWQgZXh0ZW5zaW9ucyBh bmQgb25seQ0KPj5zb21lIG9mIHRoZW0gbWFkZSBpdCB0byBJRVRGIGRyYWZ0cy9yZmNzLg0KPj4N Cj4+U28gd2hhdCB3aWxsIG1vc3QgbGlrZWx5IGhhcHBlbiBpcyBnZW5lcmFsIFlBTkcgbW9kZWwg b2Ygbm90IG11Y2ggdXNlIGFuZA0KPj56b28gb2YgcHJvcHJpZXRhcnkgdmVuZG9yIFlBTkcgZXh0 ZW5zaW9ucyBub3QgY29tcGF0aWJsZSBiZXR3ZWVuDQo+PmltcGxlbWVudGF0aW9ucy4NCj4+DQo+ PklzIHRoaXMgcmVhbGx5IHdoZXJlIHdlIHdhbnQgdG8gZ28gd2l0aCB0aGlzIGVudGlyZSBlZmZv cnQgPw0KPj4NCj4+QmVzdCwNCj4+ci4NCj4+DQo+Pg0KPj5PbiBGcmksIERlYyAxOSwgMjAxNCBh dCAxMTowMyBBTSwgIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pj4g SGksDQo+Pj4NCj4+PiBJIHRoaW5rIHdvcmtpbmcgb2YgQkdQIFlBTkcgaXMgYSBnb29kIG9wcG9y dHVuaXR5IHRvIHN0YXJ0IHdvcmtpbmcgb24NCj4+PnBvbGljeSBmcmFtZXdvcmsuDQo+Pj4gV29y ayBvbiBwcm90b2NvbHMgWUFORyBpcyBhbHJlYWR5IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWcN Cj4+PmRpc3ByZWNhbmNpZXMsIEkgZXhwZWN0IHBvbGljeSB3b3JrIHRvIGJlIG11Y2ggaGFyZGVy IC4uLg0KPj4+DQo+Pj4gQnV0IEkgdGhpbmssIHRoZXJlIGlzIGFuIG9wcG9ydHVuaXR5IHRvIHN0 YXJ0IHNvbWV0aGluZyBuZXcgZm9yDQo+Pj5ldmVyeW9uZSAodGhhdCBtYXkgY29leGlzdCB3aXRo IGV4aXN0aW5nIENMSSBwb2xpY2llcykgYW5kIG5vdCBsb29raW5nDQo+Pj5hdCBDTEkgdHJhbnNs YXRpb24gKGl0IHdpbGwgYmUgaW1wb3NzaWJsZSB3aXRoIHBvbGljaWVzKS4gVGhlbiBpdCB3b3Vs ZA0KPj4+YmUgdXAgdG8gc2VydmljZSBwcm92aWRlcnMgdG8gcmVxdWVzdCB0aGUgc3VwcG9ydCBv ZiB0aGlzIGJ5IHRoZWlyDQo+Pj5mYXZvcml0ZSB2ZW5kb3JzLg0KPj4+DQo+Pj4gQmVzdCBSZWdh cmRzLA0KPj4+DQo+Pj4gU3RlcGhhbmUNCj4+Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+PiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0DQo+Pj4gUmFzenVrDQo+Pj4gU2VudDogV2VkbmVz ZGF5LCBEZWNlbWJlciAxNywgMjAxNCAyMzoyOA0KPj4+IFRvOiBKZWZmIFRhbnRzdXJhDQo+Pj4g Q2M6IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOyBydGcteWFuZy1jb29yZEBp ZXRmLm9yZzsNCj4+PiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IExhZGlzbGF2IExob3Rr YQ0KPj4+IFN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZp bHRlcnMNCj4+Pg0KPj4+IFNvIGFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9ybWFsIFlBTkcgc3BlY2lm aWNhdGlvbiBzYXkgZm9yIEJHUCBieSBkZXNpZ24NCj4+PndpbGwgbm90IGJlIGNvbXBhdGlibGUg d2l0aCBzb21lIGltcGxlbWVudGF0aW9ucyA/DQo+Pj4NCj4+PiBPciBhcmUgeW91IHNheWluZyB0 aGF0IGZvcm1hbCBkZXNpZ24gc2F5IG9mIEJHUCBwcm90b2NvbCB3aWxsIGhhdmUgdG8NCj4+Pndh aXQgZmV3IHllYXJzIHRpbGwgWUFORyBmb3IgcG9saWN5IHNwZWMgaXMgY29tcGxldGUgPw0KPj4+ DQo+Pj4gQ2hlZXJzLA0KPj4+IHIuDQo+Pj4NCj4+PiBPbiBXZWQsIERlYyAxNywgMjAxNCBhdCAx MToxNCBQTSwgSmVmZiBUYW50c3VyYQ0KPj4+PGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPiB3 cm90ZToNCj4+Pj4gWWVzLCBleGFjdGx5LCBSb2JlcnQgLSB0aGUgYmVoYXZpb3IgeW91IGhhdmUg ZGVzY3JpYmVkIGlzIGFuDQo+Pj4+aW1wbGVtZW50YXRpb24sIG5vdCBhIGZvcm1hbCBzcGVjaWZp Y2F0aW9uLg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBKZWZmDQo+Pj4+DQo+Pj4+PiBPbiBE ZWMgMTcsIDIwMTQsIGF0IDI6MTIgUE0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5j b20+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4NCj4+Pj4+IFdoeSBpcyB0aGlzIGEgcHJvYmxlbSBpZiB0 aGUgZGVmYXVsdCBpcyB0byBub3QgdG8gcmVkaXN0cmlidXRlIHJvdXRlcw0KPj4+Pj5iZXR3ZWVu IFJJQnM/IE5vdGUgdGhhdCBpdCBpc26p9nQgbGlrZSB3ZSBoYXZlIGEgc2V0IG9mIGFwcHJvdmVk DQo+Pj4+PnJvdXRpbmcgcHJvdG9jb2wgbW9kZWxzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiB0aGlz IGJlaGF2aW9yLg0KPj4+Pj4gQWNlZQ0KPj4+Pj4NCj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0 IDU6MDcgUE0sIERlYW4gQm9nZGFub3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ+DQo+Pj4+Pj53cm90 ZToNCj4+Pj4+Pg0KPj4+Pj4+IFJvYmVydCwNCj4+Pj4+Pg0KPj4+Pj4+IFlvdXIgcHJvcG9zYWwg aXMgdmVyeSBzZW5zaWJsZSBhbmQgSSB0aGluayB0aGlzIGlzIHRoZSBiZXN0IG9wdGlvbg0KPj4+ Pj4+DQo+Pj4+Pj4gRGVhbg0KPj4+Pj4+DQo+Pj4+Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNDo0 OSBQTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQo+Pj4+Pj4+d3JvdGU6DQo+ Pj4+Pj4+DQo+Pj4+Pj4+IERlYW4sIGFsbA0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGUgd2F5IEkgcmVh ZCBpdCBjdXJyZW50bHkgaW4gc2VjdGlvbiA1LjUgdGhlcmUgYXJlIG9ubHkgdHdvDQo+Pj4+Pj4+ IHJvdXRlIGZpbHRlcnMgcHJvcG9zZWQgKGRlbnktYWxsIG9yIGFsbG93LWFsbCkuIEFzIHdlIGtu b3cgc29tZQ0KPj4+Pj4+PiByb3V0aW5nIHByb3RvY29scyByZXF1aXJlIGV4cGxpY2l0IHBlcm1p c3Npb24gdG8gb3BlcmF0ZSAoZXhhbXBsZToNCj4+Pj4+Pj5FQkdQKS4NCj4+Pj4+Pj4gSWYgd2Ug cmVtb3ZlIGV2ZW4gdGhvc2UgdHdvIHByaW1pdGl2ZSBmaWx0ZXJzIHRoZXJlIGNhbiBiZSBpbXBh Y3QNCj4+Pj4+Pj4gdG8gb3RoZXIgY29tcG9uZW50cy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQnV0IEkg ZG8gc3VwcG9ydCBhIHNlcGFyYXRlIHdvcmsgZm9yIFlBTkcgbW9kZWwgZm9yIHBvbGljeS4gSSBk bw0KPj4+Pj4+PiBleHBlY3QgdGhpcyB0byBiZSBhIHZlcnkgaW50ZXJlc3RpbmcgYW5kIGludm9s dmVkIHdvcmsgY29uc2lkZXJpbmcNCj4+Pj4+Pj4gc2lnbmlmaWNhbnQgZGl2ZXJzaXR5IG9mIHBv bGljeSBsYW5ndWFnZXMgYWNyb3NzIGFsbA0KPj4+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgdG9kYXku DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uY2UgdGhhdCB3b3JrIGlzIGRvbmUgd2UgY291bGQgcmV0aXJl IHNlY3Rpb24gNS41IG9mDQo+Pj4+Pj4+ICotbmV0bW9kLXJvdXRpbmctKg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+PiByLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gT24g V2VkLCBEZWMgMTcsIDIwMTQgYXQgMTA6MDkgUE0sIERlYW4gQm9nZGFub3ZpYw0KPj4+Pj4+Pj48 ZGVhbmJAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+Pj4+Pj4gSSdtIGluIHN1cHBvcnQgb2YgcmVt b3Zpbmcgcm91dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0aW5nIGNmZw0KPj4+Pj4+Pj5tb2RlbC4g Um91dGUgZmlsdGVycyBzaG91bGQgYmUgSU1PIHBhcnQgb2YgdGhlIHBvbGljeSBtb2RlbCwgaW4N Cj4+Pj4+Pj4+d2hpY2ggYWxzbyBBQ0wgbW9kZWwgYmVsb25ncyB0b28uIEFjdHVhbGx5LCBJIHdv dWxkIGFyZ3VlIHRoYXQgdGhlDQo+Pj4+Pj4+PmN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3Vp dGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRGVhbg0KPj4+Pj4+ DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+PiBSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBSdGcteWFuZy1jb29y ZEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRnLXlhbmctY29vcmQNCj4+Pj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4NCj4+PiBD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMNCj4+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywNCj4+PiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlDQo+Pj4gcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kNCj4+PnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcw0KPj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+Pj5hbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4+DQo+Pj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+Pj4gcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUNCj4+ PmRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+Pj4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZA0KPj4+ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz Lg0KPj4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPj4+YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQo+Pj4gVGhhbmsgeW91Lg0KPj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pl8NCj4+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+DQo+PkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucw0KPj5jb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywNCj4+ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXINCj4+ZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzDQo+PnBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMNCj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+PmFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuDQo+Pg0KPj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPj5pbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsDQo+PnVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+SWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPj5k ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+PkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0K Pj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+VGhhbmsgeW91Lg0KPj4N Cj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+UnRn LXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQo+PlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQo+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4+DQo+ Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Xw0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4NCj4+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+PmNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+PnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoNCj4+cmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+PmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcw0KPj5lbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+ Pk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lDQo+Pm91IGZhbHNpZmllLiBNZXJjaS4NCj4+DQo+PlRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkDQo+PmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+PnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KPj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQo+PmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCj4+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+PmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLg0KPj5UaGFuayB5b3UuDQo+Pg0KPg0KDQo= From nobody Fri Dec 19 15:09:28 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E999A1A90A9 for ; Fri, 19 Dec 2014 15:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOUvx2www50U for ; Fri, 19 Dec 2014 15:09:21 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6771B1A90A5 for ; Fri, 19 Dec 2014 15:09:20 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeff Tantsura'" , "'Acee Lindem \(acee\)'" , , "'Robert Raszuk'" References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 19 Dec 2014 18:09:04 -0500 Message-ID: <00c701d01be0$cbdd5a10$63980e30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEIDBB/TGvNHeSPeZwW5lE6vXixBwHqCVvpAlm2jlECCXsBigGpLNaUAwGOAMYBY0O1dgF/6gziAmC0m60Bdg69jwLmU45gATj0W/gBegqHewEw/4DNAWZpvuudWJKxYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/29LoMaWW6SCgRsZBONOQxY4_-84 Cc: rtg-yang-coord@ietf.org, 'Dean Bogdanovic' , 'Ladislav Lhotka' Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 23:09:24 -0000 Stephen:=20 I am interested. We having routing policy discussion in I2RS relating = PBR and policy. It needs to link to a base specification.=20 Sue=20 -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Jeff Tantsura Sent: Friday, December 19, 2014 4:36 PM To: Acee Lindem (acee); stephane.litkowski@orange.com; Robert Raszuk Cc: rtg-yang-coord@ietf.org; Dean Bogdanovic; Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters I=92d like to be involved, as well as giving it a home in rtgwg Cheers, Jeff -----Original Message----- > >On 12/19/14, 7:00 AM, "stephane.litkowski@orange.com" > wrote: > >>And question : Who is interested to start now the work on standard=20 >>routing policy ? >> >> >>-----Original Message----- >>From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 >>Behalf Of stephane.litkowski@orange.com >>Sent: Friday, December 19, 2014 12:59 >>To: Robert Raszuk >>Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff = >>Tantsura; Ladislav Lhotka >>Subject: Re: [Rtg-yang-coord] issue :R01: route filters >> >>Robert, >> >>You are touching an interesting point :) In fact there are two ways of = >>viewing thinks : >>- service providers/customers who would like to use only standard=20 >>models to facilitate network provision & operation >>- vendors who may not want to make development to implement new=20 >>features to be compliant with a standard yang model (as dev cost=20 >>money). As you mentioned, operation of boxes is today a key=20 >>differentiator when choosing a vendor. >>We clearly this divergence today in produced Yang model (operator=20 >>authors models vs vendor authors model) >> >>As a service provider, I'm clearly pushing to use only standard model=20 >>at least for most of the base structure of services and I will push my = >>vendors to support it as more as possible. I would say that more than=20 >>90% of parameters of a service are common to all implementations (just = >>details are changing : localization of the config statement or=20 >>granularity of the parameter). So I think that creating usable=20 >>standard model can work. The remaining x% can be addressed by vendor extensions. >> >>Coming back to routing policies. I do think that restarting a new=20 >>framework from stratch is the right way to do it. And as any protocol=20 >>extension or feature standardized in IETF, it will be up to customers=20 >>to request their vendors for implementations. >> >>Today routing policy management between different vendors is crazy. >>Consider you have a Vendor X network with widely deployed complex=20 >>routing policies, and you want to introduce to vendor Y, translation=20 >>of routing policies from language X to Y is a very complex work. >> >>Moreover we can see that framework of policy model is already existing = >>for internet registries using RPSL. >> >>I do not know today where this Yang initiative will go ... but I will=20 >>prone a consensus on strong adoption of standard YANG models rather=20 >>than vendor specific only. >> >> >>Stephane >>=20 >>=20 >> >> >>-----Original Message----- >>From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = >>Raszuk >>Sent: Friday, December 19, 2014 11:10 >>To: LITKOWSKI Stephane SCE/IBNF >>Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic;=20 >>rtg-yang-coord@ietf.org; Ladislav Lhotka >>Subject: Re: [Rtg-yang-coord] issue :R01: route filters >> >>Hi Stephane, >> >>That is going to be very interesting indeed. Considering that number=20 >>of customers have paid vendors millions for customized extensions and=20 >>only some of them made it to IETF drafts/rfcs. >> >>So what will most likely happen is general YANG model of not much use=20 >>and zoo of proprietary vendor YANG extensions not compatible between=20 >>implementations. >> >>Is this really where we want to go with this entire effort ? >> >>Best, >>r. >> >> >>On Fri, Dec 19, 2014 at 11:03 AM, = wrote: >>> Hi, >>> >>> I think working of BGP YANG is a good opportunity to start working=20 >>>on policy framework. >>> Work on protocols YANG is already hard due to vendor config=20 >>>disprecancies, I expect policy work to be much harder ... >>> >>> But I think, there is an opportunity to start something new for=20 >>>everyone (that may coexist with existing CLI policies) and not=20 >>>looking at CLI translation (it will be impossible with policies).=20 >>>Then it would be up to service providers to request the support of=20 >>>this by their favorite vendors. >>> >>> Best Regards, >>> >>> Stephane >>> >>> >>> -----Original Message----- >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of=20 >>> Robert Raszuk >>> Sent: Wednesday, December 17, 2014 23:28 >>> To: Jeff Tantsura >>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org;=20 >>> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>> >>> So are you saying that formal YANG specification say for BGP by=20 >>>design will not be compatible with some implementations ? >>> >>> Or are you saying that formal design say of BGP protocol will have=20 >>>to wait few years till YANG for policy spec is complete ? >>> >>> Cheers, >>> r. >>> >>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura=20 >>> wrote: >>>> Yes, exactly, Robert - the behavior you have described is an=20 >>>>implementation, not a formal specification. >>>> >>>> Regards, >>>> Jeff >>>> >>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) >>>>>wrote: >>>>> >>>>> Why is this a problem if the default is to not to redistribute=20 >>>>>routes between RIBs? Note that it isn=B9t like we have a set of=20 >>>>>approved routing protocol models that are dependent on this = behavior. >>>>> Acee >>>>> >>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic >>>>>>wrote: >>>>>> >>>>>> Robert, >>>>>> >>>>>> Your proposal is very sensible and I think this is the best=20 >>>>>> option >>>>>> >>>>>> Dean >>>>>> >>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk >>>>>>>wrote: >>>>>>> >>>>>>> Dean, all >>>>>>> >>>>>>> The way I read it currently in section 5.5 there are only two =20 >>>>>>>route filters proposed (deny-all or allow-all). As we know some =20 >>>>>>>routing protocols require explicit permission to operate = (example: >>>>>>>EBGP). >>>>>>> If we remove even those two primitive filters there can be=20 >>>>>>>impact to other components. >>>>>>> >>>>>>> But I do support a separate work for YANG model for policy. I do = >>>>>>> expect this to be a very interesting and involved work=20 >>>>>>> considering significant diversity of policy languages across all = >>>>>>> implementations today. >>>>>>> >>>>>>> Once that work is done we could retire section 5.5 of >>>>>>> *-netmod-routing-* >>>>>>> >>>>>>> Regards, >>>>>>> r. >>>>>>> >>>>>>> >>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic=20 >>>>>>>> wrote: >>>>>>>> I'm in support of removing route filters from the routing cfg=20 >>>>>>>>model. Route filters should be IMO part of the policy model, in=20 >>>>>>>>which also ACL model belongs too. Actually, I would argue that=20 >>>>>>>>the current ACL model is very suitable for route filters. >>>>>>>> >>>>>>>> Dean >>>>>> >>>>>> _______________________________________________ >>>>>> Rtg-yang-coord mailing list >>>>>> Rtg-yang-coord@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>> >>> >>> ____________________________________________________________________ >>> __ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations =20 >>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = =20 >>>exploites ou copies sans autorisation. Si vous avez recu ce message =20 >>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >>>que les pieces jointes. Les messages electroniques etant susceptibles = >>>d'alteration, Orange decline toute responsabilite si ce message a ete = >>>altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or =20 >>>privileged information that may be protected by law; they should not=20 >>>be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender=20 >>>and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that=20 >>>have been modified, changed or falsified. >>> Thank you. >>> >> >>______________________________________________________________________ >>___ >>_ >>_______________________________________________ >> >>Ce message et ses pieces jointes peuvent contenir des informations=20 >>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >>que les pieces jointes. Les messages electroniques etant susceptibles=20 >>d'alteration, Orange decline toute responsabilite si ce message a ete=20 >>altere, deforme ou falsifie. Merci. >> >>This message and its attachments may contain confidential or=20 >>privileged information that may be protected by law; they should not=20 >>be distributed, used or copied without authorisation. >>If you have received this email in error, please notify the sender and = >>delete this message and its attachments. >>As emails may be altered, Orange is not liable for messages that have=20 >>been modified, changed or falsified. >>Thank you. >> >>_______________________________________________ >>Rtg-yang-coord mailing list >>Rtg-yang-coord@ietf.org >>https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >>______________________________________________________________________ >>___ >>_ >>_______________________________________________ >> >>Ce message et ses pieces jointes peuvent contenir des informations=20 >>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >>que les pieces jointes. Les messages electroniques etant susceptibles=20 >>d'alteration, Orange decline toute responsabilite si ce message a ete=20 >>altere, deforme ou falsifie. Merci. >> >>This message and its attachments may contain confidential or=20 >>privileged information that may be protected by law; they should not=20 >>be distributed, used or copied without authorisation. >>If you have received this email in error, please notify the sender and = >>delete this message and its attachments. >>As emails may be altered, Orange is not liable for messages that have=20 >>been modified, changed or falsified. >>Thank you. >> > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Fri Dec 19 15:09:29 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0BD1A90A9 for ; Fri, 19 Dec 2014 15:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-O_raQ_pI3M for ; Fri, 19 Dec 2014 15:09:22 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54C91A87D4 for ; Fri, 19 Dec 2014 15:09:21 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBJN9Iqk026341 for ; Fri, 19 Dec 2014 23:09:18 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBJN9HRX026325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 19 Dec 2014 23:09:18 GMT From: "Adrian Farrel" To: References: <54945000.3080506@cisco.com> In-Reply-To: <54945000.3080506@cisco.com> Date: Fri, 19 Dec 2014 23:09:08 -0000 Message-ID: <081001d01be0$cbc84b70$6358e250$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJqux1C4BaK0tugYop6gAvDVjYOZZtiSzGw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21188.003 X-TM-AS-Result: No--3.096-10.0-31-10 X-imss-scan-details: No--3.096-10.0-31-10 X-TMASE-MatchedRID: VULvqRy0JHoO0G36v8LMKszWN98iBBeGDWfZBggWU3VO447EfatP8STC VwyY5KnUnUzwkmPsjz/NXfl6ybUe6MhfUFIsoTpV71Wx2uUbPLdBldmDYjwlpjNo9ROY8AwKZJ1 jc8WAvTs0ebVZ7WTyRwnxfqppvFLBr78SC5iivxw5f9Xw/xqKXVsKO+9Zlb5Jme9AzntO/JtQSF bL1bvQASdET58jp62Ssq7/1gi7Hxi3JkX1QvSGc31x3uZpGxND3HKKVUaV7F6TsK7bisNPpwoJt rCooV3p6cWBYxxEsUQXvTq3PzovLS9skRxLiuyITf70HMUKRXM0BbzfNgPD+/U6UIg/Ep+LOeAx ECCt14TJ+RZp4bmn0A== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/FLrze5sg0zFNplh4ovs2FROebN8 Subject: [Rtg-yang-coord] FW: YANG advice and editing session on the next IETF" X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 23:09:25 -0000 FYI > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: 19 December 2014 16:19 > To: IETF-Discussion list > Subject: YANG advice and editing session on the next IETF" > > Dear all, > > Building on the previous positive experiences, we will hosting another > "YANG advice and editing session" at this coming IETF meeting, on Sunday > March 22nd, in the afternoon. > Something similar to > http://www.ietf.org/meeting/91/tutorials/yang-session.html > I wanted to let you know, in case you plan your trip now.... > > Regards, Benoit From nobody Sat Dec 20 01:06:43 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51201A1F70 for ; Sat, 20 Dec 2014 01:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT_b1xB80g-P for ; Sat, 20 Dec 2014 01:06:32 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0940A1A6D3F for ; Sat, 20 Dec 2014 01:06:00 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 37D6D13F9DC; Sat, 20 Dec 2014 10:05:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1419066358; bh=0EyE4PnwwiGP0cldpzmr4tY/jW8tGWqOQvrX8zDL6mg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Z6m2b7ms5/qYDo4TDpdlyN5/gusNWqm2xYYI7zPHu7qLL9rcLsyTCJm4NIoUA+Dxp e9ZHxUmQgGiKNTHwobAq0WKzgdNwJ+5GtGatN8VJuP5CrLuqbcagOVI1kST1+VC1cr P0B5qJI18tMZTesJBOGgMjOcE5ZBzexiO8Oj7iTI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> Date: Sat, 20 Dec 2014 10:05:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <37ABB82B-0934-4AB6-84D5-2F878E9BBCCB@nic.cz> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup > To: stephane.litkowski@orange.com X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/dF-Xv41_JdqphGaRrJFmN-ST-TM Cc: "rtg-yang-coord@ietf.org" , Jeff Tantsura , "Acee Lindem \(acee\)" , Dean Bogdanovic , Robert Raszuk Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 09:06:35 -0000 > On 19 Dec 2014, at 13:00, stephane.litkowski@orange.com wrote: >=20 > And question : Who is interested to start now the work on standard = routing policy ? I am interested. Lada >=20 >=20 > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of stephane.litkowski@orange.com > Sent: Friday, December 19, 2014 12:59 > To: Robert Raszuk > Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff = Tantsura; Ladislav Lhotka > Subject: Re: [Rtg-yang-coord] issue :R01: route filters >=20 > Robert, >=20 > You are touching an interesting point :) In fact there are two ways of = viewing thinks : > - service providers/customers who would like to use only standard = models to facilitate network provision & operation > - vendors who may not want to make development to implement new = features to be compliant with a standard yang model (as dev cost = money). As you mentioned, operation of boxes is today a key = differentiator when choosing a vendor.=20 > We clearly this divergence today in produced Yang model (operator = authors models vs vendor authors model) >=20 > As a service provider, I'm clearly pushing to use only standard model = at least for most of the base structure of services and I will push my = vendors to support it as more as possible. I would say that more than = 90% of parameters of a service are common to all implementations (just = details are changing : localization of the config statement or = granularity of the parameter). So I think that creating usable standard = model can work. The remaining x% can be addressed by vendor extensions. >=20 > Coming back to routing policies. I do think that restarting a new = framework from stratch is the right way to do it. And as any protocol = extension or feature standardized in IETF, it will be up to customers to = request their vendors for implementations. >=20 > Today routing policy management between different vendors is crazy. = Consider you have a Vendor X network with widely deployed complex = routing policies, and you want to introduce to vendor Y, translation of = routing policies from language X to Y is a very complex work.=20 >=20 > Moreover we can see that framework of policy model is already existing = for internet registries using RPSL. >=20 > I do not know today where this Yang initiative will go ... but I will = prone a consensus on strong adoption of standard YANG models rather than = vendor specific only. >=20 >=20 > Stephane >=20 >=20 >=20 >=20 > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk > Sent: Friday, December 19, 2014 11:10 > To: LITKOWSKI Stephane SCE/IBNF > Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic; = rtg-yang-coord@ietf.org; Ladislav Lhotka > Subject: Re: [Rtg-yang-coord] issue :R01: route filters >=20 > Hi Stephane, >=20 > That is going to be very interesting indeed. Considering that number = of customers have paid vendors millions for customized extensions and = only some of them made it to IETF drafts/rfcs. >=20 > So what will most likely happen is general YANG model of not much use = and zoo of proprietary vendor YANG extensions not compatible between = implementations. >=20 > Is this really where we want to go with this entire effort ? >=20 > Best, > r. >=20 >=20 > On Fri, Dec 19, 2014 at 11:03 AM, = wrote: >> Hi, >>=20 >> I think working of BGP YANG is a good opportunity to start working on = policy framework. >> Work on protocols YANG is already hard due to vendor config = disprecancies, I expect policy work to be much harder ... >>=20 >> But I think, there is an opportunity to start something new for = everyone (that may coexist with existing CLI policies) and not looking = at CLI translation (it will be impossible with policies). Then it would = be up to service providers to request the support of this by their = favorite vendors. >>=20 >> Best Regards, >>=20 >> Stephane >>=20 >>=20 >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of = Robert=20 >> Raszuk >> Sent: Wednesday, December 17, 2014 23:28 >> To: Jeff Tantsura >> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org;=20 >> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>=20 >> So are you saying that formal YANG specification say for BGP by = design will not be compatible with some implementations ? >>=20 >> Or are you saying that formal design say of BGP protocol will have to = wait few years till YANG for policy spec is complete ? >>=20 >> Cheers, >> r. >>=20 >> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura = wrote: >>> Yes, exactly, Robert - the behavior you have described is an = implementation, not a formal specification. >>>=20 >>> Regards, >>> Jeff >>>=20 >>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) = wrote: >>>>=20 >>>> Why is this a problem if the default is to not to redistribute = routes between RIBs? Note that it isn=E2=80=99t like we have a set of = approved routing protocol models that are dependent on this behavior. >>>> Acee >>>>=20 >>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic = wrote: >>>>>=20 >>>>> Robert, >>>>>=20 >>>>> Your proposal is very sensible and I think this is the best option >>>>>=20 >>>>> Dean >>>>>=20 >>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk = wrote: >>>>>>=20 >>>>>> Dean, all >>>>>>=20 >>>>>> The way I read it currently in section 5.5 there are only two=20 >>>>>> route filters proposed (deny-all or allow-all). As we know some=20= >>>>>> routing protocols require explicit permission to operate = (example: EBGP). >>>>>> If we remove even those two primitive filters there can be impact=20= >>>>>> to other components. >>>>>>=20 >>>>>> But I do support a separate work for YANG model for policy. I do=20= >>>>>> expect this to be a very interesting and involved work = considering=20 >>>>>> significant diversity of policy languages across all=20 >>>>>> implementations today. >>>>>>=20 >>>>>> Once that work is done we could retire section 5.5 of >>>>>> *-netmod-routing-* >>>>>>=20 >>>>>> Regards, >>>>>> r. >>>>>>=20 >>>>>>=20 >>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic = wrote: >>>>>>> I'm in support of removing route filters from the routing cfg = model. Route filters should be IMO part of the policy model, in which = also ACL model belongs too. Actually, I would argue that the current ACL = model is very suitable for route filters. >>>>>>>=20 >>>>>>> Dean >>>>>=20 >>>>> _______________________________________________ >>>>> Rtg-yang-coord mailing list >>>>> Rtg-yang-coord@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>=20 >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites ou copies sans autorisation. Si vous avez recu ce message par = erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Dec 20 09:03:23 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2201A8A14 for ; Sat, 20 Dec 2014 09:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.505 X-Spam-Level: ** X-Spam-Status: No, score=2.505 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-dLPImk_pwZ for ; Sat, 20 Dec 2014 09:03:20 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6441A8956 for ; Sat, 20 Dec 2014 09:03:20 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 37339787; Sat, 20 Dec 2014 18:03:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id S__pwW_qpAHw; Sat, 20 Dec 2014 18:03:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 20 Dec 2014 18:03:17 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82B6C20034; Sat, 20 Dec 2014 18:03: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 cl9gRPXRPK0V; Sat, 20 Dec 2014 18:03: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 EB6542002C; Sat, 20 Dec 2014 18:03:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CBE883011196; Sat, 20 Dec 2014 18:03:15 +0100 (CET) Date: Sat, 20 Dec 2014 18:03:15 +0100 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20141220170315.GC32457@elstar.local> Mail-Followup-To: Alia Atlas , "t. petch" , "Rtg-yang-coord@ietf.org" References: <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/oVQ-pwO0qcQrPydduveo3UFl97s Cc: "Rtg-yang-coord@ietf.org" , "t. petch" Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Dec 2014 17:03:22 -0000 On Fri, Dec 19, 2014 at 09:08:59AM -0500, Alia Atlas wrote: > Juergen, > > It sounds like the lack of floating point is a gap. > > For values such as bandwidth, we do need to express rather wide ranges. > I do agree that fixed point can work well - but that is not what is > configured or carried in the protocols. Can you tell the range? I would assume that even a simple unsigned 64-bit number might do the job if the unit is bits per second. 1 Tbps = 1000000000000 bps 2^64 bps = 18446744073709551616 bps = 18446744 Tbps Are you sure you need a float? And for probabilities between 0 and 1, are you sure you need a float? > In particular, given that converting to/from fixed-point may not give > the same starting values, the lack of support seems like it will > cause difficulties and confusion. I been told there are boxes shipping values as floats and converting them back and forth to an internal representation that is not using floats (because of custom linecard hardware that did not do floating point math). Anyway, if a WG really believes they need floating point numbers to represent a probability or bandwidth, simply define a typedef. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Dec 20 18:05:24 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF7B1A0101 for ; Sat, 20 Dec 2014 18:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.345 X-Spam-Level: X-Spam-Status: No, score=-12.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bitULWDNKZk5 for ; Sat, 20 Dec 2014 18:05:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7891A00F7 for ; Sat, 20 Dec 2014 18:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1954; q=dns/txt; s=iport; t=1419127502; x=1420337102; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Edq0OdrAjMYgTWZVuUVo7nkpODzzgmG+A/PzGdRFHfk=; b=OfqosU0QwaTcLA7WSp0rgIyqKGkN+wURMDqSXhIXEKFqtNiq+Yq3RhaF grQ22lRnxjlPlgNnZAxgP7EYRobYmjHYnfOd3FsOBrdUIPm2OoPVt8muO TEyJFSPRNqpSeVUHD/g2Jbxs3DT+P3IzqTsJAuqi6Grti58DpqwpKApqn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAG4qllStJV2P/2dsb2JhbABYA4MGUlgExiAKhXACgRIWAQEBAQF9hAwBAQEDAQEBAWQHCw4CAgEIDgIIIwsbDAslAgQBDQWIJAgNzjYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBI9eEAcRhBgFiR6Ec4hykUsigjKBPG+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,615,1413244800"; d="scan'208";a="381727653" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP; 21 Dec 2014 02:05:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBL250r7001821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Dec 2014 02:05:00 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 20:05:00 -0600 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , Alia Atlas Thread-Topic: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard Thread-Index: AQHQFjbHi9X/7NLXKEiSKgwlpJ6WzJyMpteAgAAAwwCABKFMgIACYezSgADtGACAAV+AAP//vz0CgABlKACAAKZDPoAAoMCAgAHDBYCAAEOEAA== Date: Sun, 21 Dec 2014 02:04:59 +0000 Message-ID: References: <89C1D2C3-DC24-4A8F-84F4-EB6CC7DC829D@cisco.com> <064e01d01637$bab52370$301f6a50$@olddog.co.uk> <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> <20141220170315.GC32457@elstar.local> In-Reply-To: <20141220170315.GC32457@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/CY8xYKZ-6JHrALoQQudG3Pqiry4 Cc: "Rtg-yang-coord@ietf.org" , "t. petch" Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 02:05:10 -0000 On 12/20/14, 12:03 PM, "Juergen Schoenwaelder" wrote: >On Fri, Dec 19, 2014 at 09:08:59AM -0500, Alia Atlas wrote: >> Juergen, >>=20 >> It sounds like the lack of floating point is a gap. >>=20 >> For values such as bandwidth, we do need to express rather wide ranges. >> I do agree that fixed point can work well - but that is not what is >> configured or carried in the protocols. > >Can you tell the range? I would assume that even a simple unsigned >64-bit number might do the job if the unit is bits per second. > >1 Tbps =3D 1000000000000 bps >2^64 bps =3D 18446744073709551616 bps =3D 18446744 Tbps > >Are you sure you need a float? And for probabilities between 0 and 1, >are you sure you need a float? The question isn=B9t whether we need a float for the range of value. The RSVP and TE protocol representation has been float for many values has been float since RFC 2210. Why is it a big deal to add a YANG type? Acee=20 > >> In particular, given that converting to/from fixed-point may not give >> the same starting values, the lack of support seems like it will >> cause difficulties and confusion. > >I been told there are boxes shipping values as floats and converting >them back and forth to an internal representation that is not using >floats (because of custom linecard hardware that did not do floating >point math). > >Anyway, if a WG really believes they need floating point numbers to >represent a probability or bandwidth, simply define a typedef. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Rtg-yang-coord mailing list >Rtg-yang-coord@ietf.org >https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Sun Dec 21 04:57:09 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4537F1A03F9 for ; Sun, 21 Dec 2014 04:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq64D4PbE0GF for ; Sun, 21 Dec 2014 04:57:06 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A841A03E1 for ; Sun, 21 Dec 2014 04:57:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8DBEEF8B; Sun, 21 Dec 2014 13:57:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IYAYOtVzCiLQ; Sun, 21 Dec 2014 13:56:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 21 Dec 2014 13:57:03 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEE7B2002C; Sun, 21 Dec 2014 13:57:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ne06bZ1pRe6o; Sun, 21 Dec 2014 13:57:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94BB720017; Sun, 21 Dec 2014 13:57:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BE2CD3011661; Sun, 21 Dec 2014 13:57:01 +0100 (CET) Date: Sun, 21 Dec 2014 13:57:01 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20141221125701.GB34048@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Alia Atlas , "Rtg-yang-coord@ietf.org" , "t. petch" References: <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> <20141220170315.GC32457@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Tt80RKuCKXChSNd5eGe8Rk03FYQ Cc: "Rtg-yang-coord@ietf.org" , "t. petch" , Alia Atlas Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 12:57:08 -0000 On Sun, Dec 21, 2014 at 02:04:59AM +0000, Acee Lindem (acee) wrote: > > > On 12/20/14, 12:03 PM, "Juergen Schoenwaelder" > wrote: > > >On Fri, Dec 19, 2014 at 09:08:59AM -0500, Alia Atlas wrote: > >> Juergen, > >> > >> It sounds like the lack of floating point is a gap. > >> > >> For values such as bandwidth, we do need to express rather wide ranges. > >> I do agree that fixed point can work well - but that is not what is > >> configured or carried in the protocols. > > > >Can you tell the range? I would assume that even a simple unsigned > >64-bit number might do the job if the unit is bits per second. > > > >1 Tbps = 1000000000000 bps > >2^64 bps = 18446744073709551616 bps = 18446744 Tbps > > > >Are you sure you need a float? And for probabilities between 0 and 1, > >are you sure you need a float? > > The question isn¹t whether we need a float for the range of value. The > RSVP and TE protocol representation has been float for many values has > been float since RFC 2210. Why is it a big deal to add a YANG type? > It is not a big deal. I just wanted to point out that what RSVP and TE protocols do is, from a viewpoint of accuracy and efficiency, somewhat questionable. /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 21 08:24:03 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EE61A1B6E for ; Sun, 21 Dec 2014 08:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whp7N5Ur73BB for ; Sun, 21 Dec 2014 08:23:51 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDBA1A1B69 for ; Sun, 21 Dec 2014 08:23:48 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so2862510lbg.5 for ; Sun, 21 Dec 2014 08:23:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=GNhUArsvrKHvZIPEMnCoyKlnX4nLvEQfWoBxz1P7CaU=; b=apIJuJVi8DINa2EwFTvWKORx7d6Yhm71VMzmczK33MFbe+TCpjxxDt6qB60pjY2j86 PmWk2Rrfd8RpawgrSmd+zNeCA1cABsthtoVZwwJTAdfhlZyGFNBr0XLWt0cxqXlVjkn+ rqQaJQIXV9RQmlfHxk0dII/ui3BBqsPzf+4VG9rlYg4EcuoquAlyxc7Uti7ySO1rbp8C e+zNlYPZzJvPsYxtkMgcQhIKx4Ept4FYylAvmrZWp3b88GExIEjR7wuphHYvF0wLDa0i z2CmvS4JQ7JmX82vS/YLFfmqZfVtBzhtGX2PITeKnEup0PniYt+r21lp+vxabykld2U4 ZFhA== X-Gm-Message-State: ALoCoQmaj6I4gVRhfgXpz0elfSwVOYpJrYXEMm+DJ49O0Z/fpLVtNou+6TWPFX3uy+WFtPrDYl80 MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr17822573lac.3.1419179027102; Sun, 21 Dec 2014 08:23:47 -0800 (PST) Received: by 10.112.157.233 with HTTP; Sun, 21 Dec 2014 08:23:46 -0800 (PST) In-Reply-To: <20141221125701.GB34048@elstar.local> References: <1D523223-38FB-4FEE-9B59-CB1930FDDC82@cisco.com> <053001d019eb$92845760$4001a8c0@gateway.2wire.net> <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> <20141220170315.GC32457@elstar.local> <20141221125701.GB34048@elstar.local> Date: Sun, 21 Dec 2014 08:23:46 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Acee Lindem (acee)" , Alia Atlas , "Rtg-yang-coord@ietf.org" , "t. petch" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/U4k-NlBLoA2KR_Mqvlg-qFag3QE Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 16:23:52 -0000 On Sun, Dec 21, 2014 at 4:57 AM, Juergen Schoenwaelder wrote: > On Sun, Dec 21, 2014 at 02:04:59AM +0000, Acee Lindem (acee) wrote: >> >> >> On 12/20/14, 12:03 PM, "Juergen Schoenwaelder" >> wrote: >> >> >On Fri, Dec 19, 2014 at 09:08:59AM -0500, Alia Atlas wrote: >> >> Juergen, >> >> >> >> It sounds like the lack of floating point is a gap. >> >> >> >> For values such as bandwidth, we do need to express rather wide range= s. >> >> I do agree that fixed point can work well - but that is not what is >> >> configured or carried in the protocols. >> > >> >Can you tell the range? I would assume that even a simple unsigned >> >64-bit number might do the job if the unit is bits per second. >> > >> >1 Tbps =3D 1000000000000 bps >> >2^64 bps =3D 18446744073709551616 bps =3D 18446744 Tbps >> > >> >Are you sure you need a float? And for probabilities between 0 and 1, >> >are you sure you need a float? >> >> The question isn=C2=B9t whether we need a float for the range of value. = The >> RSVP and TE protocol representation has been float for many values has >> been float since RFC 2210. Why is it a big deal to add a YANG type? >> > > It is not a big deal. I just wanted to point out that what RSVP and TE > protocols do is, from a viewpoint of accuracy and efficiency, somewhat > questionable. > It is a big deal to add a base type. It can only be used in the new language version which will not be available in tools for a long time, and could create compatibility issues. However, a typedef can be added now and will work with YANG 1.0. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Sun Dec 21 13:32:49 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492281A8703 for ; Sun, 21 Dec 2014 13:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONlU2umCyVJc for ; Sun, 21 Dec 2014 13:32:47 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482A51A6FDE for ; Sun, 21 Dec 2014 13:32:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E3E4A8A3; Sun, 21 Dec 2014 22:32:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tlz6dISuhHWD; Sun, 21 Dec 2014 22:32:26 +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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 21 Dec 2014 22:32:44 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23FC22002C; Sun, 21 Dec 2014 22:32:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mKYGbNI9obs2; Sun, 21 Dec 2014 22:32: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 B067320017; Sun, 21 Dec 2014 22:32:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 45A8230118B5; Sun, 21 Dec 2014 22:32:40 +0100 (CET) Date: Sun, 21 Dec 2014 22:32:40 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141221213240.GA34831@elstar.local> Mail-Followup-To: Andy Bierman , "Acee Lindem (acee)" , Alia Atlas , "Rtg-yang-coord@ietf.org" , "t. petch" References: <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> <20141220170315.GC32457@elstar.local> <20141221125701.GB34048@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/pG5JkNQbsITYrY82l9nr-_8cxvM Cc: "Rtg-yang-coord@ietf.org" , "Acee Lindem \(acee\)" , "t. petch" , Alia Atlas Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 21:32:49 -0000 On Sun, Dec 21, 2014 at 08:23:46AM -0800, Andy Bierman wrote: > On Sun, Dec 21, 2014 at 4:57 AM, Juergen Schoenwaelder > wrote: > > > > It is not a big deal. I just wanted to point out that what RSVP and TE > > protocols do is, from a viewpoint of accuracy and efficiency, somewhat > > questionable. > > It is a big deal to add a base type. It can only be used in the new > language version which will not be available in tools for a long time, > and could create compatibility issues. Yes, and note that I did not write 'base type'. > However, a typedef can be added now and will work with YANG 1.0. Exactly. I still remain unconvinced that IEEE floats are technically the correct solution for token buckets and the like. I doubt that the Linux netlink interface into the kernel uses floats. But then TE must decide whether they like to see a float, even though they may give a false sense of precision. /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 21 16:06:52 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34F1A7001 for ; Sun, 21 Dec 2014 16:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.345 X-Spam-Level: X-Spam-Status: No, score=-12.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JDej8ZsQiyv for ; Sun, 21 Dec 2014 16:06:47 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EB51A6F2C for ; Sun, 21 Dec 2014 16:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1594; q=dns/txt; s=iport; t=1419206807; x=1420416407; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MzjzWDle3R7EQ6VUV6LNbcKrSGLAV/s3mxqu2bqui1Y=; b=FnNwKMgVWVwz/9zXQEel7K0xKGE2hvHv14O7/aJMQ7R7Er+FN294pWf+ jQleZiBw/YmTkFirMkAw17XCJUq9ZusSPjTtmRKK9cw4Iu31oMJvNdN9h xi28t1E/AxU3lP5eVDYDCdxX3znXwsA+giVETY1X1/PUKfPYJ0Sj6W9in Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8FAARgl1StJV2S/2dsb2JhbABYA4MGUlgExjmFdAKBExYBAQEBAX2EDQEBBHkOAgIBCA4CCCMLGxclAgQBDQUbiBHOQQEBAQEBAQEBAQEBAQEBAQEBAQEBARcEj14QBxGEGAWJHoRziHKRSyKCMoE8b4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,619,1413244800"; d="scan'208";a="381784758" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 22 Dec 2014 00:06:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBM06iJq006394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 00:06:45 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sun, 21 Dec 2014 18:06:44 -0600 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , Andy Bierman Thread-Topic: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard Thread-Index: AQHQFjbHi9X/7NLXKEiSKgwlpJ6WzJyMpteAgAAAwwCABKFMgIACYezSgADtGACAAV+AAP//vz0CgABlKACAAKZDPoAAoMCAgAHDBYCAAEOEAIABCgWAgAA5xACAAFZOAP//1zmA Date: Mon, 22 Dec 2014 00:06:44 +0000 Message-ID: References: <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> <20141220170315.GC32457@elstar.local> <20141221125701.GB34048@elstar.local> <20141221213240.GA34831@elstar.local> In-Reply-To: <20141221213240.GA34831@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Runu_db-mv2Z1U0lxkjB_AI4nl4 Cc: "Rtg-yang-coord@ietf.org" , "t. petch" , Alia Atlas Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 00:06:50 -0000 On 12/21/14, 4:32 PM, "Juergen Schoenwaelder" wrote: >On Sun, Dec 21, 2014 at 08:23:46AM -0800, Andy Bierman wrote: >> On Sun, Dec 21, 2014 at 4:57 AM, Juergen Schoenwaelder >> wrote: >> > >> > It is not a big deal. I just wanted to point out that what RSVP and TE >> > protocols do is, from a viewpoint of accuracy and efficiency, somewhat >> > questionable. >>=20 >> It is a big deal to add a base type. It can only be used in the new >> language version which will not be available in tools for a long time, >> and could create compatibility issues. > >Yes, and note that I did not write 'base type'. >=20 >> However, a typedef can be added now and will work with YANG 1.0. > >Exactly. > >I still remain unconvinced that IEEE floats are technically the >correct solution for token buckets and the like. I doubt that the >Linux netlink interface into the kernel uses floats. But then TE must >decide whether they like to see a float, even though they may give a >false sense of precision. I agree that IEEE Float-32 is not an optimal choice for representation of bandwidth and other integrated services values in RSVP. My point was that this was the choice that was made (although I didn=B9t articulate this very well).=20 Thanks, Acee=20 > >/js > >--=20 >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 22 00:53:44 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5A1A8A1C for ; Mon, 22 Dec 2014 00:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCj6WASIFKuP for ; Mon, 22 Dec 2014 00:53:39 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49521A0302 for ; Mon, 22 Dec 2014 00:53:37 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3D985733; Mon, 22 Dec 2014 09:53:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id p2atAEAezLmi; Mon, 22 Dec 2014 09:53: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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Dec 2014 09:53:35 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D6752002C; Mon, 22 Dec 2014 09:53:35 +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 9YgkWTRJZIGi; Mon, 22 Dec 2014 09:53: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 C8D3D20017; Mon, 22 Dec 2014 09:53:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 158C03011B8A; Mon, 22 Dec 2014 09:53:31 +0100 (CET) Date: Mon, 22 Dec 2014 09:53:31 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20141222085331.GA35742@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Andy Bierman , Alia Atlas , "Rtg-yang-coord@ietf.org" , "t. petch" References: <022c01d01aed$418d6060$4001a8c0@gateway.2wire.net> <042b01d01b76$73860c00$4001a8c0@gateway.2wire.net> <20141220170315.GC32457@elstar.local> <20141221125701.GB34048@elstar.local> <20141221213240.GA34831@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/WS2JGXFrgi9zxJsHnDktCa3UYOk Cc: "Rtg-yang-coord@ietf.org" , "t. petch" , Andy Bierman , Alia Atlas Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 08:53:40 -0000 On Mon, Dec 22, 2014 at 12:06:44AM +0000, Acee Lindem (acee) wrote: > > I agree that IEEE Float-32 is not an optimal choice for representation of > bandwidth and other integrated services values in RSVP. My point was that > this was the choice that was made (although I didn¹t articulate this very > well). > A certain protocol encodes the values in IEEE floating point format but that does not mean that implementations or other interfaces have to use IEEE floating point format (and I would not be surprised if a number of implementations do _not_ use IEEE floating point format). Encoding and internal representation are sometimes different things. /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 22 01:00:46 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07F71A8A25 for ; Mon, 22 Dec 2014 01:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPgBnWU_0voQ for ; Mon, 22 Dec 2014 01:00:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C15BD1A8A20 for ; Mon, 22 Dec 2014 01:00:42 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id AAFB61280A97; Mon, 22 Dec 2014 10:00:38 +0100 (CET) Date: Mon, 22 Dec 2014 10:00:38 +0100 (CET) Message-Id: <20141222.100038.719440000332847338.mbj@tail-f.com> To: acee@cisco.com From: Martin Bjorklund In-Reply-To: References: <20141221213240.GA34831@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/FuqeeEWLkrVnvZhZ1QMEgC47inw Cc: Rtg-yang-coord@ietf.org, akatlas@gmail.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, ietfc@btconnect.com Subject: Re: [Rtg-yang-coord] Fwd: Last Call: (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 09:00:44 -0000 "Acee Lindem (acee)" wrote: > = > = > On 12/21/14, 4:32 PM, "Juergen Schoenwaelder" > wrote: > = > >On Sun, Dec 21, 2014 at 08:23:46AM -0800, Andy Bierman wrote: > >> On Sun, Dec 21, 2014 at 4:57 AM, Juergen Schoenwaelder > >> wrote: > >> > > >> > It is not a big deal. I just wanted to point out that what RSVP = and TE > >> > protocols do is, from a viewpoint of accuracy and efficiency, so= mewhat > >> > questionable. > >> = > >> It is a big deal to add a base type. It can only be used in the n= ew > >> language version which will not be available in tools for a long t= ime, > >> and could create compatibility issues. > > > >Yes, and note that I did not write 'base type'. > > = > >> However, a typedef can be added now and will work with YANG 1.0. > > > >Exactly. > > > >I still remain unconvinced that IEEE floats are technically the > >correct solution for token buckets and the like. I doubt that the > >Linux netlink interface into the kernel uses floats. But then TE mus= t > >decide whether they like to see a float, even though they may give a= > >false sense of precision. > = > I agree that IEEE Float-32 is not an optimal choice for representatio= n of > bandwidth and other integrated services values in RSVP. My point was = that > this was the choice that was made (although I didn=B9t articulate thi= s very > well). = Ok, it is clear that the protocol uses floats internally. Does it follow that the configuration model has to use floats as well? Or would decimal64 work? For the interested reader, the following mail threads may be useful to read. Background: from the start YANG had floats, but we removed them when we couldn't get them to work nicely. http://www.ietf.org/mail-archive/web/netmod/current/msg01855.html http://www.ietf.org/mail-archive/web/netmod/current/msg02216.html /martin From nobody Mon Dec 22 03:02:59 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875301A8A6A; Mon, 22 Dec 2014 03:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGN6Cr2K9u2x; Mon, 22 Dec 2014 03:02:51 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416BE1A8A6C; Mon, 22 Dec 2014 03:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1027; q=dns/txt; s=iport; t=1419246168; x=1420455768; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=nvPxNw/xGgy/6WeQnlzq0XeGhRv3OXq2iGXblWPxJYs=; b=elKa0Tr10QuRumeHzuiPS2a95Hw9/hD7Hev0HiKCS+Dz5OsoS5Kttrhu uusdZIRP+PSgR58McBn4KmBzNgUmHLvzb/WcsGG03NJw/9stmmSR4jtNW HW/d5Hj8DurVjy8xsjH/2o4EaT81qEyyVFErZEuBfxLaTfdSGxZGtWDRH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUNAEn5l1StJssW/2dsb2JhbABbg1hYxjoKC4VlAoEvAQEBAQF9hA0BAQQBAQE1MwMKEQshFg8JAwIBAgEVMAYBDAYCAQEFiCMNzxYBAQEBAQEBAQEBAQEBAQEBAQEBGY8hAQFWhCkBBJcDgQ2CZIIShXaFUiKDbz0xAYELgTcBAQE X-IronPort-AV: E=Sophos;i="5.07,623,1413244800"; d="scan'208";a="284342050" 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; 22 Dec 2014 11:02:46 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBMB2kYi023102; Mon, 22 Dec 2014 11:02:46 GMT Message-ID: <5497FA56.1070509@cisco.com> Date: Mon, 22 Dec 2014 12:02:46 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" , YANG Doctors , "" , rtg-yang-coord@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/LUAUrpZjDjl32S6faa08Y5QiKb0 Subject: Re: [Rtg-yang-coord] [yang-doctors] Yangathon @ IETF in Dallas X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 11:02:53 -0000 Dear all, To avoid any potential confusions, the YANGathon Tom mentioned here is the same event as http://www.ietf.org/mail-archive/web/ietf/current/msg90977.html Regards, Benoit > Hi! > > I will be hosting a Yangathon hacking session at the IETF in Dallas. You can get more information about the meeting here: http://www.ietf.org/meeting/ > > The past meetings have been very well attended, so we need as many volunteers who are Yang experts to help others with advice on model creation/modification and general information around Yang. Please contact me offline (with the same subject line) if you can commit to being there in person. > > We are also considering a tutorial on one or more of the tools. If you have ideas, please let me know as that is a welcome addition to the meeting as well. > > Thanks! > > --Tom > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > . > From nobody Thu Dec 25 01:07:04 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E541A874A for ; Thu, 25 Dec 2014 01:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyAq67llT18B for ; Thu, 25 Dec 2014 01:06:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DBD1A8736 for ; Thu, 25 Dec 2014 01:06:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNH75664; Thu, 25 Dec 2014 09:06:44 +0000 (GMT) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Dec 2014 09:06:43 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.207]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 17:06:35 +0800 From: wangzitao To: "stephane.litkowski@orange.com" , "Robert Raszuk" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFsPsK01GVgzkOaWRN9dfYCGJySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwIAJPUaw Date: Thu, 25 Dec 2014 09:06:35 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/a1gIVkXtj27WW1f-u3YELJ_4uhI Cc: "rtg-yang-coord@ietf.org" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 09:07:02 -0000 SSBhbSBpbnRlcmVzdGVkLg0KDQotTWljaGFlbA0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R 5Lu25Lq6OiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqCBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbQ0K5Y+R6YCB5pe26Ze0 OiAyMDE05bm0MTLmnIgxOeaXpSAyMDowMQ0K5pS25Lu25Lq6OiBMSVRLT1dTS0kgU3RlcGhhbmUg U0NFL0lCTkY7IFJvYmVydCBSYXN6dWsNCuaKhOmAgTogcnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7 IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOyBKZWZmIFRhbnRzdXJhOyBMYWRp c2xhdiBMaG90a2ENCuS4u+mimDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91 dGUgZmlsdGVycw0KDQpBbmQgcXVlc3Rpb24gOiBXaG8gaXMgaW50ZXJlc3RlZCB0byBzdGFydCBu b3cgdGhlIHdvcmsgb24gc3RhbmRhcmQgcm91dGluZyBwb2xpY3kgPw0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNv b3JkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAxOSwgMjAxNCAxMjo1OQ0KVG86IFJvYmVy dCBSYXN6dWsNCkNjOiBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgQWNlZSBMaW5kZW0gKGFjZWUp OyBEZWFuIEJvZ2Rhbm92aWM7IEplZmYgVGFudHN1cmE7IExhZGlzbGF2IExob3RrYQ0KU3ViamVj dDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0KDQpSb2Jl cnQsDQoNCllvdSBhcmUgdG91Y2hpbmcgYW4gaW50ZXJlc3RpbmcgcG9pbnQgOikgSW4gZmFjdCB0 aGVyZSBhcmUgdHdvIHdheXMgb2Ygdmlld2luZyB0aGlua3MgOg0KLSBzZXJ2aWNlIHByb3ZpZGVy cy9jdXN0b21lcnMgd2hvIHdvdWxkIGxpa2UgdG8gdXNlIG9ubHkgc3RhbmRhcmQgbW9kZWxzIHRv IGZhY2lsaXRhdGUgbmV0d29yayBwcm92aXNpb24gJiBvcGVyYXRpb24NCi0gdmVuZG9ycyB3aG8g bWF5IG5vdCB3YW50IHRvIG1ha2UgZGV2ZWxvcG1lbnQgdG8gaW1wbGVtZW50IG5ldyBmZWF0dXJl cyB0byBiZSBjb21wbGlhbnQgd2l0aCBhIHN0YW5kYXJkIHlhbmcgbW9kZWwgIChhcyBkZXYgY29z dCBtb25leSkuIEFzIHlvdSBtZW50aW9uZWQsIG9wZXJhdGlvbiBvZiBib3hlcyBpcyB0b2RheSBh IGtleSBkaWZmZXJlbnRpYXRvciB3aGVuIGNob29zaW5nIGEgdmVuZG9yLiANCldlIGNsZWFybHkg dGhpcyBkaXZlcmdlbmNlIHRvZGF5IGluIHByb2R1Y2VkIFlhbmcgbW9kZWwgKG9wZXJhdG9yIGF1 dGhvcnMgbW9kZWxzIHZzIHZlbmRvciBhdXRob3JzIG1vZGVsKQ0KDQpBcyBhIHNlcnZpY2UgcHJv dmlkZXIsIEknbSBjbGVhcmx5IHB1c2hpbmcgdG8gdXNlIG9ubHkgc3RhbmRhcmQgbW9kZWwgYXQg bGVhc3QgZm9yIG1vc3Qgb2YgdGhlIGJhc2Ugc3RydWN0dXJlIG9mIHNlcnZpY2VzIGFuZCBJIHdp bGwgcHVzaCBteSB2ZW5kb3JzIHRvIHN1cHBvcnQgaXQgYXMgbW9yZSBhcyBwb3NzaWJsZS4gSSB3 b3VsZCBzYXkgdGhhdCBtb3JlIHRoYW4gOTAlIG9mIHBhcmFtZXRlcnMgb2YgYSBzZXJ2aWNlIGFy ZSBjb21tb24gdG8gYWxsIGltcGxlbWVudGF0aW9ucyAoanVzdCBkZXRhaWxzIGFyZSBjaGFuZ2lu ZyAgOiBsb2NhbGl6YXRpb24gb2YgdGhlIGNvbmZpZyBzdGF0ZW1lbnQgb3IgZ3JhbnVsYXJpdHkg b2YgdGhlIHBhcmFtZXRlcikuIFNvIEkgdGhpbmsgdGhhdCBjcmVhdGluZyB1c2FibGUgc3RhbmRh cmQgbW9kZWwgY2FuIHdvcmsuIFRoZSByZW1haW5pbmcgeCUgY2FuIGJlIGFkZHJlc3NlZCBieSB2 ZW5kb3IgZXh0ZW5zaW9ucy4NCg0KQ29taW5nIGJhY2sgdG8gcm91dGluZyBwb2xpY2llcy4gSSBk byB0aGluayB0aGF0IHJlc3RhcnRpbmcgYSBuZXcgZnJhbWV3b3JrIGZyb20gc3RyYXRjaCBpcyB0 aGUgcmlnaHQgd2F5IHRvIGRvIGl0LiBBbmQgYXMgYW55IHByb3RvY29sIGV4dGVuc2lvbiBvciBm ZWF0dXJlIHN0YW5kYXJkaXplZCBpbiBJRVRGLCBpdCB3aWxsIGJlIHVwIHRvIGN1c3RvbWVycyB0 byByZXF1ZXN0IHRoZWlyIHZlbmRvcnMgZm9yIGltcGxlbWVudGF0aW9ucy4NCg0KVG9kYXkgcm91 dGluZyBwb2xpY3kgbWFuYWdlbWVudCBiZXR3ZWVuIGRpZmZlcmVudCB2ZW5kb3JzIGlzIGNyYXp5 LiBDb25zaWRlciB5b3UgaGF2ZSBhIFZlbmRvciBYIG5ldHdvcmsgd2l0aCB3aWRlbHkgZGVwbG95 ZWQgY29tcGxleCByb3V0aW5nIHBvbGljaWVzLCBhbmQgeW91IHdhbnQgdG8gaW50cm9kdWNlIHRv IHZlbmRvciBZLCB0cmFuc2xhdGlvbiBvZiByb3V0aW5nIHBvbGljaWVzIGZyb20gbGFuZ3VhZ2Ug WCB0byBZIGlzIGEgdmVyeSBjb21wbGV4IHdvcmsuIA0KDQpNb3Jlb3ZlciB3ZSBjYW4gc2VlIHRo YXQgZnJhbWV3b3JrIG9mIHBvbGljeSBtb2RlbCBpcyBhbHJlYWR5IGV4aXN0aW5nIGZvciBpbnRl cm5ldCByZWdpc3RyaWVzIHVzaW5nIFJQU0wuDQoNCkkgZG8gbm90IGtub3cgdG9kYXkgd2hlcmUg dGhpcyBZYW5nIGluaXRpYXRpdmUgd2lsbCBnbyAuLi4gYnV0IEkgd2lsbCBwcm9uZSBhIGNvbnNl bnN1cyBvbiBzdHJvbmcgYWRvcHRpb24gb2Ygc3RhbmRhcmQgWUFORyBtb2RlbHMgcmF0aGVyIHRo YW4gdmVuZG9yIHNwZWNpZmljIG9ubHkuDQoNCg0KU3RlcGhhbmUNCiANCiANCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFz enVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IEZyaWRheSwg RGVjZW1iZXIgMTksIDIwMTQgMTE6MTANClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYN CkNjOiBKZWZmIFRhbnRzdXJhOyBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsg cnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IExhZGlzbGF2IExob3RrYQ0KU3ViamVjdDogUmU6IFtS dGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0KDQpIaSBTdGVwaGFuZSwN Cg0KVGhhdCBpcyBnb2luZyB0byBiZSB2ZXJ5IGludGVyZXN0aW5nIGluZGVlZC4gQ29uc2lkZXJp bmcgdGhhdCBudW1iZXIgb2YgY3VzdG9tZXJzIGhhdmUgcGFpZCB2ZW5kb3JzIG1pbGxpb25zIGZv ciBjdXN0b21pemVkIGV4dGVuc2lvbnMgYW5kIG9ubHkgc29tZSBvZiB0aGVtIG1hZGUgaXQgdG8g SUVURiBkcmFmdHMvcmZjcy4NCg0KU28gd2hhdCB3aWxsIG1vc3QgbGlrZWx5IGhhcHBlbiBpcyBn ZW5lcmFsIFlBTkcgbW9kZWwgb2Ygbm90IG11Y2ggdXNlIGFuZCB6b28gb2YgcHJvcHJpZXRhcnkg dmVuZG9yIFlBTkcgZXh0ZW5zaW9ucyBub3QgY29tcGF0aWJsZSBiZXR3ZWVuIGltcGxlbWVudGF0 aW9ucy4NCg0KSXMgdGhpcyByZWFsbHkgd2hlcmUgd2Ugd2FudCB0byBnbyB3aXRoIHRoaXMgZW50 aXJlIGVmZm9ydCA/DQoNCkJlc3QsDQpyLg0KDQoNCk9uIEZyaSwgRGVjIDE5LCAyMDE0IGF0IDEx OjAzIEFNLCAgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiB3cm90ZToNCj4gSGksDQo+ DQo+IEkgdGhpbmsgd29ya2luZyBvZiBCR1AgWUFORyBpcyBhIGdvb2Qgb3Bwb3J0dW5pdHkgdG8g c3RhcnQgd29ya2luZyBvbiBwb2xpY3kgZnJhbWV3b3JrLg0KPiBXb3JrIG9uIHByb3RvY29scyBZ QU5HIGlzIGFscmVhZHkgaGFyZCBkdWUgdG8gdmVuZG9yIGNvbmZpZyBkaXNwcmVjYW5jaWVzLCBJ IGV4cGVjdCBwb2xpY3kgd29yayB0byBiZSBtdWNoIGhhcmRlciAuLi4NCj4NCj4gQnV0IEkgdGhp bmssIHRoZXJlIGlzIGFuIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHNvbWV0aGluZyBuZXcgZm9yIGV2 ZXJ5b25lICh0aGF0IG1heSBjb2V4aXN0IHdpdGggZXhpc3RpbmcgQ0xJIHBvbGljaWVzKSBhbmQg bm90IGxvb2tpbmcgYXQgQ0xJIHRyYW5zbGF0aW9uIChpdCB3aWxsIGJlIGltcG9zc2libGUgd2l0 aCBwb2xpY2llcykuIFRoZW4gaXQgd291bGQgYmUgdXAgdG8gc2VydmljZSBwcm92aWRlcnMgdG8g cmVxdWVzdCB0aGUgc3VwcG9ydCBvZiB0aGlzIGJ5IHRoZWlyIGZhdm9yaXRlIHZlbmRvcnMuDQo+ DQo+IEJlc3QgUmVnYXJkcywNCj4NCj4gU3RlcGhhbmUNCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdt YWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydCANCj4gUmFzenVrDQo+IFNlbnQ6IFdlZG5lc2Rh eSwgRGVjZW1iZXIgMTcsIDIwMTQgMjM6MjgNCj4gVG86IEplZmYgVGFudHN1cmENCj4gQ2M6IEFj ZWUgTGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOyBydGcteWFuZy1jb29yZEBpZXRmLm9y ZzsgDQo+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjsgTGFkaXNsYXYgTGhvdGthDQo+IFN1 YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4N Cj4gU28gYXJlIHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwgWUFORyBzcGVjaWZpY2F0aW9uIHNheSBm b3IgQkdQIGJ5IGRlc2lnbiB3aWxsIG5vdCBiZSBjb21wYXRpYmxlIHdpdGggc29tZSBpbXBsZW1l bnRhdGlvbnMgPw0KPg0KPiBPciBhcmUgeW91IHNheWluZyB0aGF0IGZvcm1hbCBkZXNpZ24gc2F5 IG9mIEJHUCBwcm90b2NvbCB3aWxsIGhhdmUgdG8gd2FpdCBmZXcgeWVhcnMgdGlsbCBZQU5HIGZv ciBwb2xpY3kgc3BlYyBpcyBjb21wbGV0ZSA/DQo+DQo+IENoZWVycywNCj4gci4NCj4NCj4gT24g V2VkLCBEZWMgMTcsIDIwMTQgYXQgMTE6MTQgUE0sIEplZmYgVGFudHN1cmEgPGplZmYudGFudHN1 cmFAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IFllcywgZXhhY3RseSwgUm9iZXJ0IC0gdGhlIGJl aGF2aW9yIHlvdSBoYXZlIGRlc2NyaWJlZCBpcyBhbiBpbXBsZW1lbnRhdGlvbiwgbm90IGEgZm9y bWFsIHNwZWNpZmljYXRpb24uDQo+Pg0KPj4gUmVnYXJkcywNCj4+IEplZmYNCj4+DQo+Pj4gT24g RGVjIDE3LCAyMDE0LCBhdCAyOjEyIFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28u Y29tPiB3cm90ZToNCj4+Pg0KPj4+IFdoeSBpcyB0aGlzIGEgcHJvYmxlbSBpZiB0aGUgZGVmYXVs dCBpcyB0byBub3QgdG8gcmVkaXN0cmlidXRlIHJvdXRlcyBiZXR3ZWVuIFJJQnM/IE5vdGUgdGhh dCBpdCBpc27igJl0IGxpa2Ugd2UgaGF2ZSBhIHNldCBvZiBhcHByb3ZlZCByb3V0aW5nIHByb3Rv Y29sIG1vZGVscyB0aGF0IGFyZSBkZXBlbmRlbnQgb24gdGhpcyBiZWhhdmlvci4NCj4+PiBBY2Vl DQo+Pj4NCj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCA1OjA3IFBNLCBEZWFuIEJvZ2Rhbm92aWMg PGRlYW5iQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+Pj4NCj4+Pj4gUm9iZXJ0LA0KPj4+Pg0KPj4+ PiBZb3VyIHByb3Bvc2FsIGlzIHZlcnkgc2Vuc2libGUgYW5kIEkgdGhpbmsgdGhpcyBpcyB0aGUg YmVzdCBvcHRpb24NCj4+Pj4NCj4+Pj4gRGVhbg0KPj4+Pg0KPj4+Pj4gT24gRGVjIDE3LCAyMDE0 LCBhdCA0OjQ5IFBNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4gd3JvdGU6DQo+ Pj4+Pg0KPj4+Pj4gRGVhbiwgYWxsDQo+Pj4+Pg0KPj4+Pj4gVGhlIHdheSBJIHJlYWQgaXQgY3Vy cmVudGx5IGluIHNlY3Rpb24gNS41IHRoZXJlIGFyZSBvbmx5IHR3byANCj4+Pj4+IHJvdXRlIGZp bHRlcnMgcHJvcG9zZWQgKGRlbnktYWxsIG9yIGFsbG93LWFsbCkuIEFzIHdlIGtub3cgc29tZSAN Cj4+Pj4+IHJvdXRpbmcgcHJvdG9jb2xzIHJlcXVpcmUgZXhwbGljaXQgcGVybWlzc2lvbiB0byBv cGVyYXRlIChleGFtcGxlOiBFQkdQKS4NCj4+Pj4+IElmIHdlIHJlbW92ZSBldmVuIHRob3NlIHR3 byBwcmltaXRpdmUgZmlsdGVycyB0aGVyZSBjYW4gYmUgaW1wYWN0IA0KPj4+Pj4gdG8gb3RoZXIg Y29tcG9uZW50cy4NCj4+Pj4+DQo+Pj4+PiBCdXQgSSBkbyBzdXBwb3J0IGEgc2VwYXJhdGUgd29y ayBmb3IgWUFORyBtb2RlbCBmb3IgcG9saWN5LiBJIGRvIA0KPj4+Pj4gZXhwZWN0IHRoaXMgdG8g YmUgYSB2ZXJ5IGludGVyZXN0aW5nIGFuZCBpbnZvbHZlZCB3b3JrIGNvbnNpZGVyaW5nIA0KPj4+ Pj4gc2lnbmlmaWNhbnQgZGl2ZXJzaXR5IG9mIHBvbGljeSBsYW5ndWFnZXMgYWNyb3NzIGFsbCAN Cj4+Pj4+IGltcGxlbWVudGF0aW9ucyB0b2RheS4NCj4+Pj4+DQo+Pj4+PiBPbmNlIHRoYXQgd29y ayBpcyBkb25lIHdlIGNvdWxkIHJldGlyZSBzZWN0aW9uIDUuNSBvZg0KPj4+Pj4gKi1uZXRtb2Qt cm91dGluZy0qDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IHIuDQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+PiBPbiBXZWQsIERlYyAxNywgMjAxNCBhdCAxMDowOSBQTSwgRGVhbiBCb2dkYW5vdmlj IDxkZWFuYkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4+Pj4gSSdtIGluIHN1cHBvcnQgb2YgcmVt b3Zpbmcgcm91dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0aW5nIGNmZyBtb2RlbC4gUm91dGUgZmls dGVycyBzaG91bGQgYmUgSU1PIHBhcnQgb2YgdGhlIHBvbGljeSBtb2RlbCwgaW4gd2hpY2ggYWxz byBBQ0wgbW9kZWwgYmVsb25ncyB0b28uIEFjdHVhbGx5LCBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhl IGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3VpdGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuDQo+ Pj4+Pj4NCj4+Pj4+PiBEZWFuDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0K Pj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+Pj4NCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4N Cj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIA0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgDQo+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgDQo+IHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4NCj4NCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIA0KPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0K VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsg dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KUnRnLXlhbmctY29vcmRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmct Y29vcmQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0 DQpSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGcteWFuZy1jb29yZA0K From nobody Thu Dec 25 02:54:14 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAA1A8793 for ; Thu, 25 Dec 2014 02:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmhCyZKCcAX2 for ; Thu, 25 Dec 2014 02:54:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724D51A877C for ; Thu, 25 Dec 2014 02:54:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNH82404; Thu, 25 Dec 2014 10:54:02 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Dec 2014 10:54:00 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 18:53:56 +0800 From: Qin Wu To: "stephane.litkowski@orange.com" , "Robert Raszuk" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwIAJWCRw Date: Thu, 25 Dec 2014 10:53:55 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/1S48hHBJ5i27xUpBSIjhnW6UMXY Cc: "rtg-yang-coord@ietf.org" , "Acee Lindem \(acee\)" , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 10:54:13 -0000 R29vZCBxdWVzdGlvbiwgSSB0aGluayBJMlJTIGhhcyBhbHJlYWR5IGRldmxlZCBpbnRvIHRoaXMg YXNwZWN0LCBlLmcuLA0KYS4gUG9saWN5IGZyYW1ld29yayBkcmFmdA0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWF0bGFzLWkycnMtcG9saWN5LWZyYW1ld29yay0wMA0KYi4gUG9s aWN5IGJhc2VkIHJvdXRpbmcgZHJhZnRzIA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWhhcmVza2luaS1pMnJzLXBici1pbmZvLW1vZGVsLTAwDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWtpbmktaTJycy1wYnItaW5mby1tb2RlbC0wMC50eHQNCkkgdGhpbmsgdGhl c2UgZHJhZnRzIGFyZSBxdWl0ZSByZWxhdGVkIHRvIHdoYXQgeW91IGFyZSBsb29raW5nIGZvci4N CldvdWxkIGl0IGJlIGdyZWF0IHRvIHJlc3RhcnQgc29tZSBkaXNjdXNzaW9uIG9uIHRoZXNlIGRy YWZ0cyBmaXJzdCBhbmQgc2VlIHdoYXQgaXMgbWlzc2luZyBpbiB0aGVzZSBkcmFmdHMNCkFuZCBp ZiB0aGVzZSBkcmFmdHMgY2FuIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cyB3ZSB3YW50IHRvIHNl dCBmb3IgdGhpcyB0b3BpYz8NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCuWPkeS7tuS6ujogUnRnLXlhbmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3Vu Y2VzQGlldGYub3JnXSDku6Pooaggc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20NCuWPkemA geaXtumXtDogMjAxNOW5tDEy5pyIMTnml6UgMjA6MDENCuaUtuS7tuS6ujogTElUS09XU0tJIFN0 ZXBoYW5lIFNDRS9JQk5GOyBSb2JlcnQgUmFzenVrDQrmioTpgIE6IHJ0Zy15YW5nLWNvb3JkQGll dGYub3JnOyBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgSmVmZiBUYW50c3Vy YTsgTGFkaXNsYXYgTGhvdGthDQrkuLvpopg6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpS MDE6IHJvdXRlIGZpbHRlcnMNCg0KQW5kIHF1ZXN0aW9uIDogV2hvIGlzIGludGVyZXN0ZWQgdG8g c3RhcnQgbm93IHRoZSB3b3JrIG9uIHN0YW5kYXJkIHJvdXRpbmcgcG9saWN5ID8NCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnRnLXlhbmctY29vcmQgW21haWx0bzpydGct eWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygc3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb20NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTksIDIwMTQgMTI6NTkNClRv OiBSb2JlcnQgUmFzenVrDQpDYzogcnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IEFjZWUgTGluZGVt IChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOyBKZWZmIFRhbnRzdXJhOyBMYWRpc2xhdiBMaG90a2EN ClN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMN Cg0KUm9iZXJ0LA0KDQpZb3UgYXJlIHRvdWNoaW5nIGFuIGludGVyZXN0aW5nIHBvaW50IDopIElu IGZhY3QgdGhlcmUgYXJlIHR3byB3YXlzIG9mIHZpZXdpbmcgdGhpbmtzIDoNCi0gc2VydmljZSBw cm92aWRlcnMvY3VzdG9tZXJzIHdobyB3b3VsZCBsaWtlIHRvIHVzZSBvbmx5IHN0YW5kYXJkIG1v ZGVscyB0byBmYWNpbGl0YXRlIG5ldHdvcmsgcHJvdmlzaW9uICYgb3BlcmF0aW9uDQotIHZlbmRv cnMgd2hvIG1heSBub3Qgd2FudCB0byBtYWtlIGRldmVsb3BtZW50IHRvIGltcGxlbWVudCBuZXcg ZmVhdHVyZXMgdG8gYmUgY29tcGxpYW50IHdpdGggYSBzdGFuZGFyZCB5YW5nIG1vZGVsICAoYXMg ZGV2IGNvc3QgbW9uZXkpLiBBcyB5b3UgbWVudGlvbmVkLCBvcGVyYXRpb24gb2YgYm94ZXMgaXMg dG9kYXkgYSBrZXkgZGlmZmVyZW50aWF0b3Igd2hlbiBjaG9vc2luZyBhIHZlbmRvci4gDQpXZSBj bGVhcmx5IHRoaXMgZGl2ZXJnZW5jZSB0b2RheSBpbiBwcm9kdWNlZCBZYW5nIG1vZGVsIChvcGVy YXRvciBhdXRob3JzIG1vZGVscyB2cyB2ZW5kb3IgYXV0aG9ycyBtb2RlbCkNCg0KQXMgYSBzZXJ2 aWNlIHByb3ZpZGVyLCBJJ20gY2xlYXJseSBwdXNoaW5nIHRvIHVzZSBvbmx5IHN0YW5kYXJkIG1v ZGVsIGF0IGxlYXN0IGZvciBtb3N0IG9mIHRoZSBiYXNlIHN0cnVjdHVyZSBvZiBzZXJ2aWNlcyBh bmQgSSB3aWxsIHB1c2ggbXkgdmVuZG9ycyB0byBzdXBwb3J0IGl0IGFzIG1vcmUgYXMgcG9zc2li bGUuIEkgd291bGQgc2F5IHRoYXQgbW9yZSB0aGFuIDkwJSBvZiBwYXJhbWV0ZXJzIG9mIGEgc2Vy dmljZSBhcmUgY29tbW9uIHRvIGFsbCBpbXBsZW1lbnRhdGlvbnMgKGp1c3QgZGV0YWlscyBhcmUg Y2hhbmdpbmcgIDogbG9jYWxpemF0aW9uIG9mIHRoZSBjb25maWcgc3RhdGVtZW50IG9yIGdyYW51 bGFyaXR5IG9mIHRoZSBwYXJhbWV0ZXIpLiBTbyBJIHRoaW5rIHRoYXQgY3JlYXRpbmcgdXNhYmxl IHN0YW5kYXJkIG1vZGVsIGNhbiB3b3JrLiBUaGUgcmVtYWluaW5nIHglIGNhbiBiZSBhZGRyZXNz ZWQgYnkgdmVuZG9yIGV4dGVuc2lvbnMuDQoNCkNvbWluZyBiYWNrIHRvIHJvdXRpbmcgcG9saWNp ZXMuIEkgZG8gdGhpbmsgdGhhdCByZXN0YXJ0aW5nIGEgbmV3IGZyYW1ld29yayBmcm9tIHN0cmF0 Y2ggaXMgdGhlIHJpZ2h0IHdheSB0byBkbyBpdC4gQW5kIGFzIGFueSBwcm90b2NvbCBleHRlbnNp b24gb3IgZmVhdHVyZSBzdGFuZGFyZGl6ZWQgaW4gSUVURiwgaXQgd2lsbCBiZSB1cCB0byBjdXN0 b21lcnMgdG8gcmVxdWVzdCB0aGVpciB2ZW5kb3JzIGZvciBpbXBsZW1lbnRhdGlvbnMuDQoNClRv ZGF5IHJvdXRpbmcgcG9saWN5IG1hbmFnZW1lbnQgYmV0d2VlbiBkaWZmZXJlbnQgdmVuZG9ycyBp cyBjcmF6eS4gQ29uc2lkZXIgeW91IGhhdmUgYSBWZW5kb3IgWCBuZXR3b3JrIHdpdGggd2lkZWx5 IGRlcGxveWVkIGNvbXBsZXggcm91dGluZyBwb2xpY2llcywgYW5kIHlvdSB3YW50IHRvIGludHJv ZHVjZSB0byB2ZW5kb3IgWSwgdHJhbnNsYXRpb24gb2Ygcm91dGluZyBwb2xpY2llcyBmcm9tIGxh bmd1YWdlIFggdG8gWSBpcyBhIHZlcnkgY29tcGxleCB3b3JrLiANCg0KTW9yZW92ZXIgd2UgY2Fu IHNlZSB0aGF0IGZyYW1ld29yayBvZiBwb2xpY3kgbW9kZWwgaXMgYWxyZWFkeSBleGlzdGluZyBm b3IgaW50ZXJuZXQgcmVnaXN0cmllcyB1c2luZyBSUFNMLg0KDQpJIGRvIG5vdCBrbm93IHRvZGF5 IHdoZXJlIHRoaXMgWWFuZyBpbml0aWF0aXZlIHdpbGwgZ28gLi4uIGJ1dCBJIHdpbGwgcHJvbmUg YSBjb25zZW5zdXMgb24gc3Ryb25nIGFkb3B0aW9uIG9mIHN0YW5kYXJkIFlBTkcgbW9kZWxzIHJh dGhlciB0aGFuIHZlbmRvciBzcGVjaWZpYyBvbmx5Lg0KDQoNClN0ZXBoYW5lDQogDQogDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWls dG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBG cmlkYXksIERlY2VtYmVyIDE5LCAyMDE0IDExOjEwDQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFND RS9JQk5GDQpDYzogSmVmZiBUYW50c3VyYTsgQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJvZ2Rh bm92aWM7IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBMYWRpc2xhdiBMaG90a2ENClN1YmplY3Q6 IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCg0KSGkgU3Rl cGhhbmUsDQoNClRoYXQgaXMgZ29pbmcgdG8gYmUgdmVyeSBpbnRlcmVzdGluZyBpbmRlZWQuIENv bnNpZGVyaW5nIHRoYXQgbnVtYmVyIG9mIGN1c3RvbWVycyBoYXZlIHBhaWQgdmVuZG9ycyBtaWxs aW9ucyBmb3IgY3VzdG9taXplZCBleHRlbnNpb25zIGFuZCBvbmx5IHNvbWUgb2YgdGhlbSBtYWRl IGl0IHRvIElFVEYgZHJhZnRzL3JmY3MuDQoNClNvIHdoYXQgd2lsbCBtb3N0IGxpa2VseSBoYXBw ZW4gaXMgZ2VuZXJhbCBZQU5HIG1vZGVsIG9mIG5vdCBtdWNoIHVzZSBhbmQgem9vIG9mIHByb3By aWV0YXJ5IHZlbmRvciBZQU5HIGV4dGVuc2lvbnMgbm90IGNvbXBhdGlibGUgYmV0d2VlbiBpbXBs ZW1lbnRhdGlvbnMuDQoNCklzIHRoaXMgcmVhbGx5IHdoZXJlIHdlIHdhbnQgdG8gZ28gd2l0aCB0 aGlzIGVudGlyZSBlZmZvcnQgPw0KDQpCZXN0LA0Kci4NCg0KDQpPbiBGcmksIERlYyAxOSwgMjAx NCBhdCAxMTowMyBBTSwgIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ IEhpLA0KPg0KPiBJIHRoaW5rIHdvcmtpbmcgb2YgQkdQIFlBTkcgaXMgYSBnb29kIG9wcG9ydHVu aXR5IHRvIHN0YXJ0IHdvcmtpbmcgb24gcG9saWN5IGZyYW1ld29yay4NCj4gV29yayBvbiBwcm90 b2NvbHMgWUFORyBpcyBhbHJlYWR5IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWcgZGlzcHJlY2Fu Y2llcywgSSBleHBlY3QgcG9saWN5IHdvcmsgdG8gYmUgbXVjaCBoYXJkZXIgLi4uDQo+DQo+IEJ1 dCBJIHRoaW5rLCB0aGVyZSBpcyBhbiBvcHBvcnR1bml0eSB0byBzdGFydCBzb21ldGhpbmcgbmV3 IGZvciBldmVyeW9uZSAodGhhdCBtYXkgY29leGlzdCB3aXRoIGV4aXN0aW5nIENMSSBwb2xpY2ll cykgYW5kIG5vdCBsb29raW5nIGF0IENMSSB0cmFuc2xhdGlvbiAoaXQgd2lsbCBiZSBpbXBvc3Np YmxlIHdpdGggcG9saWNpZXMpLiBUaGVuIGl0IHdvdWxkIGJlIHVwIHRvIHNlcnZpY2UgcHJvdmlk ZXJzIHRvIHJlcXVlc3QgdGhlIHN1cHBvcnQgb2YgdGhpcyBieSB0aGVpciBmYXZvcml0ZSB2ZW5k b3JzLg0KPg0KPiBCZXN0IFJlZ2FyZHMsDQo+DQo+IFN0ZXBoYW5lDQo+DQo+DQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJh c3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgDQo+IFJhc3p1aw0KPiBTZW50OiBX ZWRuZXNkYXksIERlY2VtYmVyIDE3LCAyMDE0IDIzOjI4DQo+IFRvOiBKZWZmIFRhbnRzdXJhDQo+ IENjOiBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgcnRnLXlhbmctY29vcmRA aWV0Zi5vcmc7IA0KPiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IExhZGlzbGF2IExob3Rr YQ0KPiBTdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0 ZXJzDQo+DQo+IFNvIGFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9ybWFsIFlBTkcgc3BlY2lmaWNhdGlv biBzYXkgZm9yIEJHUCBieSBkZXNpZ24gd2lsbCBub3QgYmUgY29tcGF0aWJsZSB3aXRoIHNvbWUg aW1wbGVtZW50YXRpb25zID8NCj4NCj4gT3IgYXJlIHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwgZGVz aWduIHNheSBvZiBCR1AgcHJvdG9jb2wgd2lsbCBoYXZlIHRvIHdhaXQgZmV3IHllYXJzIHRpbGwg WUFORyBmb3IgcG9saWN5IHNwZWMgaXMgY29tcGxldGUgPw0KPg0KPiBDaGVlcnMsDQo+IHIuDQo+ DQo+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDExOjE0IFBNLCBKZWZmIFRhbnRzdXJhIDxqZWZm LnRhbnRzdXJhQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiBZZXMsIGV4YWN0bHksIFJvYmVydCAt IHRoZSBiZWhhdmlvciB5b3UgaGF2ZSBkZXNjcmliZWQgaXMgYW4gaW1wbGVtZW50YXRpb24sIG5v dCBhIGZvcm1hbCBzcGVjaWZpY2F0aW9uLg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBKZWZmDQo+Pg0K Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgMjoxMiBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2Vl QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBXaHkgaXMgdGhpcyBhIHByb2JsZW0gaWYgdGhl IGRlZmF1bHQgaXMgdG8gbm90IHRvIHJlZGlzdHJpYnV0ZSByb3V0ZXMgYmV0d2VlbiBSSUJzPyBO b3RlIHRoYXQgaXQgaXNu4oCZdCBsaWtlIHdlIGhhdmUgYSBzZXQgb2YgYXBwcm92ZWQgcm91dGlu ZyBwcm90b2NvbCBtb2RlbHMgdGhhdCBhcmUgZGVwZW5kZW50IG9uIHRoaXMgYmVoYXZpb3IuDQo+ Pj4gQWNlZQ0KPj4+DQo+Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNTowNyBQTSwgRGVhbiBCb2dk YW5vdmljIDxkZWFuYkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4+DQo+Pj4+IFJvYmVydCwNCj4+ Pj4NCj4+Pj4gWW91ciBwcm9wb3NhbCBpcyB2ZXJ5IHNlbnNpYmxlIGFuZCBJIHRoaW5rIHRoaXMg aXMgdGhlIGJlc3Qgb3B0aW9uDQo+Pj4+DQo+Pj4+IERlYW4NCj4+Pj4NCj4+Pj4+IE9uIERlYyAx NywgMjAxNCwgYXQgNDo0OSBQTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdy b3RlOg0KPj4+Pj4NCj4+Pj4+IERlYW4sIGFsbA0KPj4+Pj4NCj4+Pj4+IFRoZSB3YXkgSSByZWFk IGl0IGN1cnJlbnRseSBpbiBzZWN0aW9uIDUuNSB0aGVyZSBhcmUgb25seSB0d28gDQo+Pj4+PiBy b3V0ZSBmaWx0ZXJzIHByb3Bvc2VkIChkZW55LWFsbCBvciBhbGxvdy1hbGwpLiBBcyB3ZSBrbm93 IHNvbWUgDQo+Pj4+PiByb3V0aW5nIHByb3RvY29scyByZXF1aXJlIGV4cGxpY2l0IHBlcm1pc3Np b24gdG8gb3BlcmF0ZSAoZXhhbXBsZTogRUJHUCkuDQo+Pj4+PiBJZiB3ZSByZW1vdmUgZXZlbiB0 aG9zZSB0d28gcHJpbWl0aXZlIGZpbHRlcnMgdGhlcmUgY2FuIGJlIGltcGFjdCANCj4+Pj4+IHRv IG90aGVyIGNvbXBvbmVudHMuDQo+Pj4+Pg0KPj4+Pj4gQnV0IEkgZG8gc3VwcG9ydCBhIHNlcGFy YXRlIHdvcmsgZm9yIFlBTkcgbW9kZWwgZm9yIHBvbGljeS4gSSBkbyANCj4+Pj4+IGV4cGVjdCB0 aGlzIHRvIGJlIGEgdmVyeSBpbnRlcmVzdGluZyBhbmQgaW52b2x2ZWQgd29yayBjb25zaWRlcmlu ZyANCj4+Pj4+IHNpZ25pZmljYW50IGRpdmVyc2l0eSBvZiBwb2xpY3kgbGFuZ3VhZ2VzIGFjcm9z cyBhbGwgDQo+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgdG9kYXkuDQo+Pj4+Pg0KPj4+Pj4gT25jZSB0 aGF0IHdvcmsgaXMgZG9uZSB3ZSBjb3VsZCByZXRpcmUgc2VjdGlvbiA1LjUgb2YNCj4+Pj4+ICot bmV0bW9kLXJvdXRpbmctKg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiByLg0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+Pj4gT24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgMTA6MDkgUE0sIERlYW4gQm9n ZGFub3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+Pj4+IEknbSBpbiBzdXBwb3J0 IG9mIHJlbW92aW5nIHJvdXRlIGZpbHRlcnMgZnJvbSB0aGUgcm91dGluZyBjZmcgbW9kZWwuIFJv dXRlIGZpbHRlcnMgc2hvdWxkIGJlIElNTyBwYXJ0IG9mIHRoZSBwb2xpY3kgbW9kZWwsIGluIHdo aWNoIGFsc28gQUNMIG1vZGVsIGJlbG9uZ3MgdG9vLiBBY3R1YWxseSwgSSB3b3VsZCBhcmd1ZSB0 aGF0IHRoZSBjdXJyZW50IEFDTCBtb2RlbCBpcyB2ZXJ5IHN1aXRhYmxlIGZvciByb3V0ZSBmaWx0 ZXJzLg0KPj4+Pj4+DQo+Pj4+Pj4gRGVhbg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBSdGcteWFuZy1jb29yZCBtYWlsaW5n IGxpc3QNCj4+Pj4gUnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KPj4+DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+DQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyANCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIA0KPiBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQo+DQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciANCj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNClJ0Zy15YW5n LWNvb3JkQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Zy15YW5nLWNvb3JkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJ0Zy15YW5nLWNvb3JkIG1haWxp bmcgbGlzdA0KUnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCg== From nobody Thu Dec 25 03:12:59 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09521A8791 for ; Thu, 25 Dec 2014 03:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53E0Gvl6kJP8 for ; Thu, 25 Dec 2014 03:12:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5071A875C for ; Thu, 25 Dec 2014 03:12:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQL86718; Thu, 25 Dec 2014 11:12:41 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Dec 2014 11:12:39 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 19:12:33 +0800 From: Qin Wu To: Jeff Tantsura , "Acee Lindem (acee)" , "stephane.litkowski@orange.com" , Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwP//wG0AgABaZACACUWn8A== Date: Thu, 25 Dec 2014 11:12:32 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> 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.138.41.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/sUQNd3Sduna-UixYApWAj5CBzHs Cc: "rtg-yang-coord@ietf.org" , David Sinicrope , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 11:12:57 -0000 SmVmZjoNCklzbid0IHRoaXMgdG9waWMgc3Vic3VtZWQgaW50byBJMlJTPw0KV2hhdCBhbSBJIG1p c3Npbmc/DQoNClJlZ2FyZHMhDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bk uro6IFJ0Zy15YW5nLWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIEplZmYgVGFudHN1cmENCuWPkemAgeaXtumXtDogMjAxNOW5tDEy5pyIMjDml6Ug NTozNg0K5pS25Lu25Lq6OiBBY2VlIExpbmRlbSAoYWNlZSk7IHN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tOyBSb2JlcnQgUmFzenVrDQrmioTpgIE6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3Jn OyBEZWFuIEJvZ2Rhbm92aWM7IExhZGlzbGF2IExob3RrYQ0K5Li76aKYOiBSZTogW1J0Zy15YW5n LWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0ZXJzDQoNCknigJlkIGxpa2UgdG8gYmUgaW52 b2x2ZWQsIGFzIHdlbGwgYXMgZ2l2aW5nIGl0IGEgaG9tZSBpbiBydGd3Zw0KDQpDaGVlcnMsDQpK ZWZmDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4NCj5PbiAxMi8xOS8x NCwgNzowMCBBTSwgInN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIg0KPjxzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+DQo+PkFuZCBxdWVzdGlvbiA6IFdobyBpcyBp bnRlcmVzdGVkIHRvIHN0YXJ0IG5vdyB0aGUgd29yayBvbiBzdGFuZGFyZCANCj4+cm91dGluZyBw b2xpY3kgPw0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IFJ0 Zy15YW5nLWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10gT24g DQo+PkJlaGFsZiBPZiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbQ0KPj5TZW50OiBGcmlk YXksIERlY2VtYmVyIDE5LCAyMDE0IDEyOjU5DQo+PlRvOiBSb2JlcnQgUmFzenVrDQo+PkNjOiBy dGcteWFuZy1jb29yZEBpZXRmLm9yZzsgQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJvZ2Rhbm92 aWM7IEplZmYgDQo+PlRhbnRzdXJhOyBMYWRpc2xhdiBMaG90a2ENCj4+U3ViamVjdDogUmU6IFtS dGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0KPj4NCj4+Um9iZXJ0LA0K Pj4NCj4+WW91IGFyZSB0b3VjaGluZyBhbiBpbnRlcmVzdGluZyBwb2ludCA6KSBJbiBmYWN0IHRo ZXJlIGFyZSB0d28gd2F5cyBvZiANCj4+dmlld2luZyB0aGlua3MgOg0KPj4tIHNlcnZpY2UgcHJv dmlkZXJzL2N1c3RvbWVycyB3aG8gd291bGQgbGlrZSB0byB1c2Ugb25seSBzdGFuZGFyZCANCj4+ bW9kZWxzIHRvIGZhY2lsaXRhdGUgbmV0d29yayBwcm92aXNpb24gJiBvcGVyYXRpb24NCj4+LSB2 ZW5kb3JzIHdobyBtYXkgbm90IHdhbnQgdG8gbWFrZSBkZXZlbG9wbWVudCB0byBpbXBsZW1lbnQg bmV3IA0KPj5mZWF0dXJlcyB0byBiZSBjb21wbGlhbnQgd2l0aCBhIHN0YW5kYXJkIHlhbmcgbW9k ZWwgIChhcyBkZXYgY29zdCANCj4+bW9uZXkpLiBBcyB5b3UgbWVudGlvbmVkLCBvcGVyYXRpb24g b2YgYm94ZXMgaXMgdG9kYXkgYSBrZXkgDQo+PmRpZmZlcmVudGlhdG9yIHdoZW4gY2hvb3Npbmcg YSB2ZW5kb3IuDQo+PldlIGNsZWFybHkgdGhpcyBkaXZlcmdlbmNlIHRvZGF5IGluIHByb2R1Y2Vk IFlhbmcgbW9kZWwgKG9wZXJhdG9yIA0KPj5hdXRob3JzIG1vZGVscyB2cyB2ZW5kb3IgYXV0aG9y cyBtb2RlbCkNCj4+DQo+PkFzIGEgc2VydmljZSBwcm92aWRlciwgSSdtIGNsZWFybHkgcHVzaGlu ZyB0byB1c2Ugb25seSBzdGFuZGFyZCBtb2RlbCANCj4+YXQgbGVhc3QgZm9yIG1vc3Qgb2YgdGhl IGJhc2Ugc3RydWN0dXJlIG9mIHNlcnZpY2VzIGFuZCBJIHdpbGwgcHVzaCBteSANCj4+dmVuZG9y cyB0byBzdXBwb3J0IGl0IGFzIG1vcmUgYXMgcG9zc2libGUuIEkgd291bGQgc2F5IHRoYXQgbW9y ZSB0aGFuIA0KPj45MCUgb2YgcGFyYW1ldGVycyBvZiBhIHNlcnZpY2UgYXJlIGNvbW1vbiB0byBh bGwgaW1wbGVtZW50YXRpb25zIChqdXN0IA0KPj5kZXRhaWxzIGFyZSBjaGFuZ2luZyAgOiBsb2Nh bGl6YXRpb24gb2YgdGhlIGNvbmZpZyBzdGF0ZW1lbnQgb3IgDQo+PmdyYW51bGFyaXR5IG9mIHRo ZSBwYXJhbWV0ZXIpLiBTbyBJIHRoaW5rIHRoYXQgY3JlYXRpbmcgdXNhYmxlIA0KPj5zdGFuZGFy ZCBtb2RlbCBjYW4gd29yay4gVGhlIHJlbWFpbmluZyB4JSBjYW4gYmUgYWRkcmVzc2VkIGJ5IHZl bmRvciBleHRlbnNpb25zLg0KPj4NCj4+Q29taW5nIGJhY2sgdG8gcm91dGluZyBwb2xpY2llcy4g SSBkbyB0aGluayB0aGF0IHJlc3RhcnRpbmcgYSBuZXcgDQo+PmZyYW1ld29yayBmcm9tIHN0cmF0 Y2ggaXMgdGhlIHJpZ2h0IHdheSB0byBkbyBpdC4gQW5kIGFzIGFueSBwcm90b2NvbCANCj4+ZXh0 ZW5zaW9uIG9yIGZlYXR1cmUgc3RhbmRhcmRpemVkIGluIElFVEYsIGl0IHdpbGwgYmUgdXAgdG8g Y3VzdG9tZXJzIA0KPj50byByZXF1ZXN0IHRoZWlyIHZlbmRvcnMgZm9yIGltcGxlbWVudGF0aW9u cy4NCj4+DQo+PlRvZGF5IHJvdXRpbmcgcG9saWN5IG1hbmFnZW1lbnQgYmV0d2VlbiBkaWZmZXJl bnQgdmVuZG9ycyBpcyBjcmF6eS4NCj4+Q29uc2lkZXIgeW91IGhhdmUgYSBWZW5kb3IgWCBuZXR3 b3JrIHdpdGggd2lkZWx5IGRlcGxveWVkIGNvbXBsZXggDQo+PnJvdXRpbmcgcG9saWNpZXMsIGFu ZCB5b3Ugd2FudCB0byBpbnRyb2R1Y2UgdG8gdmVuZG9yIFksIHRyYW5zbGF0aW9uIA0KPj5vZiBy b3V0aW5nIHBvbGljaWVzIGZyb20gbGFuZ3VhZ2UgWCB0byBZIGlzIGEgdmVyeSBjb21wbGV4IHdv cmsuDQo+Pg0KPj5Nb3Jlb3ZlciB3ZSBjYW4gc2VlIHRoYXQgZnJhbWV3b3JrIG9mIHBvbGljeSBt b2RlbCBpcyBhbHJlYWR5IGV4aXN0aW5nIA0KPj5mb3IgaW50ZXJuZXQgcmVnaXN0cmllcyB1c2lu ZyBSUFNMLg0KPj4NCj4+SSBkbyBub3Qga25vdyB0b2RheSB3aGVyZSB0aGlzIFlhbmcgaW5pdGlh dGl2ZSB3aWxsIGdvIC4uLiBidXQgSSB3aWxsIA0KPj5wcm9uZSBhIGNvbnNlbnN1cyBvbiBzdHJv bmcgYWRvcHRpb24gb2Ygc3RhbmRhcmQgWUFORyBtb2RlbHMgcmF0aGVyIA0KPj50aGFuIHZlbmRv ciBzcGVjaWZpYyBvbmx5Lg0KPj4NCj4+DQo+PlN0ZXBoYW5lDQo+PiANCj4+IA0KPj4NCj4+DQo+ Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IHJyYXN6dWtAZ21haWwuY29tIFtt YWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgDQo+PlJhc3p1aw0K Pj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDE5LCAyMDE0IDExOjEwDQo+PlRvOiBMSVRLT1dTS0kg U3RlcGhhbmUgU0NFL0lCTkYNCj4+Q2M6IEplZmYgVGFudHN1cmE7IEFjZWUgTGluZGVtIChhY2Vl KTsgRGVhbiBCb2dkYW5vdmljOyANCj4+cnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IExhZGlzbGF2 IExob3RrYQ0KPj5TdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0 ZSBmaWx0ZXJzDQo+Pg0KPj5IaSBTdGVwaGFuZSwNCj4+DQo+PlRoYXQgaXMgZ29pbmcgdG8gYmUg dmVyeSBpbnRlcmVzdGluZyBpbmRlZWQuIENvbnNpZGVyaW5nIHRoYXQgbnVtYmVyIA0KPj5vZiBj dXN0b21lcnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWlsbGlvbnMgZm9yIGN1c3RvbWl6ZWQgZXh0ZW5z aW9ucyBhbmQgDQo+Pm9ubHkgc29tZSBvZiB0aGVtIG1hZGUgaXQgdG8gSUVURiBkcmFmdHMvcmZj cy4NCj4+DQo+PlNvIHdoYXQgd2lsbCBtb3N0IGxpa2VseSBoYXBwZW4gaXMgZ2VuZXJhbCBZQU5H IG1vZGVsIG9mIG5vdCBtdWNoIHVzZSANCj4+YW5kIHpvbyBvZiBwcm9wcmlldGFyeSB2ZW5kb3Ig WUFORyBleHRlbnNpb25zIG5vdCBjb21wYXRpYmxlIGJldHdlZW4gDQo+PmltcGxlbWVudGF0aW9u cy4NCj4+DQo+PklzIHRoaXMgcmVhbGx5IHdoZXJlIHdlIHdhbnQgdG8gZ28gd2l0aCB0aGlzIGVu dGlyZSBlZmZvcnQgPw0KPj4NCj4+QmVzdCwNCj4+ci4NCj4+DQo+Pg0KPj5PbiBGcmksIERlYyAx OSwgMjAxNCBhdCAxMTowMyBBTSwgIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3Jv dGU6DQo+Pj4gSGksDQo+Pj4NCj4+PiBJIHRoaW5rIHdvcmtpbmcgb2YgQkdQIFlBTkcgaXMgYSBn b29kIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHdvcmtpbmcgDQo+Pj5vbiBwb2xpY3kgZnJhbWV3b3Jr Lg0KPj4+IFdvcmsgb24gcHJvdG9jb2xzIFlBTkcgaXMgYWxyZWFkeSBoYXJkIGR1ZSB0byB2ZW5k b3IgY29uZmlnIA0KPj4+ZGlzcHJlY2FuY2llcywgSSBleHBlY3QgcG9saWN5IHdvcmsgdG8gYmUg bXVjaCBoYXJkZXIgLi4uDQo+Pj4NCj4+PiBCdXQgSSB0aGluaywgdGhlcmUgaXMgYW4gb3Bwb3J0 dW5pdHkgdG8gc3RhcnQgc29tZXRoaW5nIG5ldyBmb3IgDQo+Pj5ldmVyeW9uZSAodGhhdCBtYXkg Y29leGlzdCB3aXRoIGV4aXN0aW5nIENMSSBwb2xpY2llcykgYW5kIG5vdCANCj4+Pmxvb2tpbmcg YXQgQ0xJIHRyYW5zbGF0aW9uIChpdCB3aWxsIGJlIGltcG9zc2libGUgd2l0aCBwb2xpY2llcyku IA0KPj4+VGhlbiBpdCB3b3VsZCBiZSB1cCB0byBzZXJ2aWNlIHByb3ZpZGVycyB0byByZXF1ZXN0 IHRoZSBzdXBwb3J0IG9mIA0KPj4+dGhpcyBieSB0aGVpciBmYXZvcml0ZSB2ZW5kb3JzLg0KPj4+ DQo+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+DQo+Pj4gU3RlcGhhbmUNCj4+Pg0KPj4+DQo+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFp bHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgDQo+Pj4gUm9iZXJ0IFJhc3p1aw0K Pj4+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTcsIDIwMTQgMjM6MjgNCj4+PiBUbzogSmVm ZiBUYW50c3VyYQ0KPj4+IENjOiBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsg cnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IA0KPj4+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJO RjsgTGFkaXNsYXYgTGhvdGthDQo+Pj4gU3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNz dWUgOlIwMTogcm91dGUgZmlsdGVycw0KPj4+DQo+Pj4gU28gYXJlIHlvdSBzYXlpbmcgdGhhdCBm b3JtYWwgWUFORyBzcGVjaWZpY2F0aW9uIHNheSBmb3IgQkdQIGJ5IA0KPj4+ZGVzaWduIHdpbGwg bm90IGJlIGNvbXBhdGlibGUgd2l0aCBzb21lIGltcGxlbWVudGF0aW9ucyA/DQo+Pj4NCj4+PiBP ciBhcmUgeW91IHNheWluZyB0aGF0IGZvcm1hbCBkZXNpZ24gc2F5IG9mIEJHUCBwcm90b2NvbCB3 aWxsIGhhdmUgDQo+Pj50byB3YWl0IGZldyB5ZWFycyB0aWxsIFlBTkcgZm9yIHBvbGljeSBzcGVj IGlzIGNvbXBsZXRlID8NCj4+Pg0KPj4+IENoZWVycywNCj4+PiByLg0KPj4+DQo+Pj4gT24gV2Vk LCBEZWMgMTcsIDIwMTQgYXQgMTE6MTQgUE0sIEplZmYgVGFudHN1cmEgDQo+Pj48amVmZi50YW50 c3VyYUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+PiBZZXMsIGV4YWN0bHksIFJvYmVydCAtIHRo ZSBiZWhhdmlvciB5b3UgaGF2ZSBkZXNjcmliZWQgaXMgYW4gDQo+Pj4+aW1wbGVtZW50YXRpb24s IG5vdCBhIGZvcm1hbCBzcGVjaWZpY2F0aW9uLg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBK ZWZmDQo+Pj4+DQo+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDI6MTIgUE0sIEFjZWUgTGluZGVt IChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4NCj4+Pj4+IFdoeSBp cyB0aGlzIGEgcHJvYmxlbSBpZiB0aGUgZGVmYXVsdCBpcyB0byBub3QgdG8gcmVkaXN0cmlidXRl IA0KPj4+Pj5yb3V0ZXMgYmV0d2VlbiBSSUJzPyBOb3RlIHRoYXQgaXQgaXNuwrl0IGxpa2Ugd2Ug aGF2ZSBhIHNldCBvZiANCj4+Pj4+YXBwcm92ZWQgcm91dGluZyBwcm90b2NvbCBtb2RlbHMgdGhh dCBhcmUgZGVwZW5kZW50IG9uIHRoaXMgYmVoYXZpb3IuDQo+Pj4+PiBBY2VlDQo+Pj4+Pg0KPj4+ Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNTowNyBQTSwgRGVhbiBCb2dkYW5vdmljIDxkZWFuYkBq dW5pcGVyLm5ldD4NCj4+Pj4+Pndyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gUm9iZXJ0LA0KPj4+Pj4+ DQo+Pj4+Pj4gWW91ciBwcm9wb3NhbCBpcyB2ZXJ5IHNlbnNpYmxlIGFuZCBJIHRoaW5rIHRoaXMg aXMgdGhlIGJlc3QgDQo+Pj4+Pj4gb3B0aW9uDQo+Pj4+Pj4NCj4+Pj4+PiBEZWFuDQo+Pj4+Pj4N Cj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCA0OjQ5IFBNLCBSb2JlcnQgUmFzenVrIDxyb2Jl cnRAcmFzenVrLm5ldD4NCj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gRGVhbiwgYWxs DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSB3YXkgSSByZWFkIGl0IGN1cnJlbnRseSBpbiBzZWN0aW9u IDUuNSB0aGVyZSBhcmUgb25seSB0d28gIA0KPj4+Pj4+PnJvdXRlIGZpbHRlcnMgcHJvcG9zZWQg KGRlbnktYWxsIG9yIGFsbG93LWFsbCkuIEFzIHdlIGtub3cgc29tZSAgDQo+Pj4+Pj4+cm91dGlu ZyBwcm90b2NvbHMgcmVxdWlyZSBleHBsaWNpdCBwZXJtaXNzaW9uIHRvIG9wZXJhdGUgKGV4YW1w bGU6DQo+Pj4+Pj4+RUJHUCkuDQo+Pj4+Pj4+IElmIHdlIHJlbW92ZSBldmVuIHRob3NlIHR3byBw cmltaXRpdmUgZmlsdGVycyB0aGVyZSBjYW4gYmUgDQo+Pj4+Pj4+aW1wYWN0ICB0byBvdGhlciBj b21wb25lbnRzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBCdXQgSSBkbyBzdXBwb3J0IGEgc2VwYXJhdGUg d29yayBmb3IgWUFORyBtb2RlbCBmb3IgcG9saWN5LiBJIGRvIA0KPj4+Pj4+PiBleHBlY3QgdGhp cyB0byBiZSBhIHZlcnkgaW50ZXJlc3RpbmcgYW5kIGludm9sdmVkIHdvcmsgDQo+Pj4+Pj4+IGNv bnNpZGVyaW5nIHNpZ25pZmljYW50IGRpdmVyc2l0eSBvZiBwb2xpY3kgbGFuZ3VhZ2VzIGFjcm9z cyBhbGwgDQo+Pj4+Pj4+IGltcGxlbWVudGF0aW9ucyB0b2RheS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g T25jZSB0aGF0IHdvcmsgaXMgZG9uZSB3ZSBjb3VsZCByZXRpcmUgc2VjdGlvbiA1LjUgb2YNCj4+ Pj4+Pj4gKi1uZXRtb2Qtcm91dGluZy0qDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+ Pj4+IHIuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiBXZWQsIERlYyAxNywgMjAxNCBh dCAxMDowOSBQTSwgRGVhbiBCb2dkYW5vdmljIA0KPj4+Pj4+Pj48ZGVhbmJAanVuaXBlci5uZXQ+ IHdyb3RlOg0KPj4+Pj4+Pj4gSSdtIGluIHN1cHBvcnQgb2YgcmVtb3Zpbmcgcm91dGUgZmlsdGVy cyBmcm9tIHRoZSByb3V0aW5nIGNmZyANCj4+Pj4+Pj4+bW9kZWwuIFJvdXRlIGZpbHRlcnMgc2hv dWxkIGJlIElNTyBwYXJ0IG9mIHRoZSBwb2xpY3kgbW9kZWwsIGluIA0KPj4+Pj4+Pj53aGljaCBh bHNvIEFDTCBtb2RlbCBiZWxvbmdzIHRvby4gQWN0dWFsbHksIEkgd291bGQgYXJndWUgdGhhdCAN Cj4+Pj4+Pj4+dGhlIGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3VpdGFibGUgZm9yIHJvdXRl IGZpbHRlcnMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRGVhbg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBSdGcteWFu Zy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQN Cj4+Pj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IF9fIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+DQo+Pj4gQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zICANCj4+ PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBl dHJlIGRpZmZ1c2VzLCAgDQo+Pj5leHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlICANCj4+PnBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIA0KPj4+cXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIA0KPj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIA0KPj4+YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4NCj4+Pg0KPj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciAgDQo+Pj5wcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCANCj4+PmJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+Pj4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIA0KPj4+YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+ PiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IA0KPj4+aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N Cj4+PiBUaGFuayB5b3UuDQo+Pj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+X19fDQo+Pl8NCj4+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+DQo+PkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyANCj4+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIA0KPj5leHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPj5wYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSAN Cj4+cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIA0KPj5kJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgDQo+PmFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQo+Pg0KPj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+PnByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IA0KPj5iZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj5JZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIA0KPj5kZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+PkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSANCj4+YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+PlRoYW5r IHlvdS4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PlJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPj5SdGcteWFuZy1jb29yZEBpZXRm Lm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNv b3JkDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pl9fXw0KPj5fDQo+Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pg0KPj5DZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQo+PmNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRp ZmZ1c2VzLCANCj4+ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSANCj4+cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgDQo+PnF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyAN Cj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIA0KPj5hbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0K Pj4NCj4+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIA0KPj5wcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCANCj4+YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCANCj4+ZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgDQo+PmJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj5UaGFuayB5b3UuDQo+Pg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUnRnLXlhbmct Y29vcmQgbWFpbGluZyBsaXN0DQpSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0K From nobody Thu Dec 25 03:18:04 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF91A8795 for ; Thu, 25 Dec 2014 03:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Fcqs7X5ciz for ; Thu, 25 Dec 2014 03:17:59 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615BB1A8791 for ; Thu, 25 Dec 2014 03:17:59 -0800 (PST) Received: by mail-ig0-f170.google.com with SMTP id r2so9050458igi.3 for ; Thu, 25 Dec 2014 03:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BbzBsYv40D8xV8m8gnFcl4xmpISnaVdfRr02WpK1KDU=; b=Gexnn/aFkG7V+1j2StYlt6AA77pkbG9WqU5K0jRBak4BbmUmadKV6qjNl6mL/Q2ZIR 8mxMIRb1kygLJ1Ul37vI2wJMivwYZEmzFkAuPUgj3xq5h36IzLJ2MVHIKKnRZSIm+Y6f zWj077VRBD80piVtyYMX5/6Vpzdp/Rb/+WsOtLhOtXG/1VhaX6zOR5A01XGg2709zQn6 p3RWf59dGpJ1m4la051xJa3b+vCXbddxqnj2LNUECYM3NNR2I2zq+RM2+1lVSYZ4e2/F Oq2uqlAwzg1DYxtIJi7/WZuHhN8BY0WQztSFqZOedOl5fww+2Xc5weCsBi424VHiN3hu P45A== MIME-Version: 1.0 X-Received: by 10.50.66.131 with SMTP id f3mr17543657igt.17.1419506278425; Thu, 25 Dec 2014 03:17:58 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.152.130 with HTTP; Thu, 25 Dec 2014 03:17:58 -0800 (PST) In-Reply-To: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> Date: Thu, 25 Dec 2014 12:17:58 +0100 X-Google-Sender-Auth: 1x1Erl7p-z35oS3lMwd6iVu4hgI Message-ID: From: Robert Raszuk To: Qin Wu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/uBz-ZQqyY1XXnDBDTq-63TMY7Uw Cc: "rtg-yang-coord@ietf.org" , "stephane.litkowski@orange.com" , Dean Bogdanovic , Jeff Tantsura , Ladislav Lhotka , David Sinicrope , "Acee Lindem \(acee\)" Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 11:18:02 -0000 Qin, draft-atlas-i2rs-policy-framework-00 can be helpful to this work. The other two drafts on PBR are quite irrelevant. We are not talking about PBR here at all. It is just one specific application of data plane policy. Our effort first is to define YANG model for control plane policy. Best, r. On Thu, Dec 25, 2014 at 12:12 PM, Qin Wu wrote: > Jeff: > Isn't this topic subsumed into I2RS? > What am I missing? > > Regards! > -Qin > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Rtg-yang-coord [mailto:rtg-yang-coord-bounce= s@ietf.org] =E4=BB=A3=E8=A1=A8 Jeff Tantsura > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B412=E6=9C=8820=E6=97=A5= 5:36 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Acee Lindem (acee); stephane.litkowski@orang= e.com; Robert Raszuk > =E6=8A=84=E9=80=81: rtg-yang-coord@ietf.org; Dean Bogdanovic; Ladislav Lh= otka > =E4=B8=BB=E9=A2=98: Re: [Rtg-yang-coord] issue :R01: route filters > > I=E2=80=99d like to be involved, as well as giving it a home in rtgwg > > Cheers, > Jeff > > > > > -----Original Message----- > >> >>On 12/19/14, 7:00 AM, "stephane.litkowski@orange.com" >> wrote: >> >>>And question : Who is interested to start now the work on standard >>>routing policy ? >>> >>> >>>-----Original Message----- >>>From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On >>>Behalf Of stephane.litkowski@orange.com >>>Sent: Friday, December 19, 2014 12:59 >>>To: Robert Raszuk >>>Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff >>>Tantsura; Ladislav Lhotka >>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>> >>>Robert, >>> >>>You are touching an interesting point :) In fact there are two ways of >>>viewing thinks : >>>- service providers/customers who would like to use only standard >>>models to facilitate network provision & operation >>>- vendors who may not want to make development to implement new >>>features to be compliant with a standard yang model (as dev cost >>>money). As you mentioned, operation of boxes is today a key >>>differentiator when choosing a vendor. >>>We clearly this divergence today in produced Yang model (operator >>>authors models vs vendor authors model) >>> >>>As a service provider, I'm clearly pushing to use only standard model >>>at least for most of the base structure of services and I will push my >>>vendors to support it as more as possible. I would say that more than >>>90% of parameters of a service are common to all implementations (just >>>details are changing : localization of the config statement or >>>granularity of the parameter). So I think that creating usable >>>standard model can work. The remaining x% can be addressed by vendor ext= ensions. >>> >>>Coming back to routing policies. I do think that restarting a new >>>framework from stratch is the right way to do it. And as any protocol >>>extension or feature standardized in IETF, it will be up to customers >>>to request their vendors for implementations. >>> >>>Today routing policy management between different vendors is crazy. >>>Consider you have a Vendor X network with widely deployed complex >>>routing policies, and you want to introduce to vendor Y, translation >>>of routing policies from language X to Y is a very complex work. >>> >>>Moreover we can see that framework of policy model is already existing >>>for internet registries using RPSL. >>> >>>I do not know today where this Yang initiative will go ... but I will >>>prone a consensus on strong adoption of standard YANG models rather >>>than vendor specific only. >>> >>> >>>Stephane >>> >>> >>> >>> >>>-----Original Message----- >>>From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>>Raszuk >>>Sent: Friday, December 19, 2014 11:10 >>>To: LITKOWSKI Stephane SCE/IBNF >>>Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic; >>>rtg-yang-coord@ietf.org; Ladislav Lhotka >>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>> >>>Hi Stephane, >>> >>>That is going to be very interesting indeed. Considering that number >>>of customers have paid vendors millions for customized extensions and >>>only some of them made it to IETF drafts/rfcs. >>> >>>So what will most likely happen is general YANG model of not much use >>>and zoo of proprietary vendor YANG extensions not compatible between >>>implementations. >>> >>>Is this really where we want to go with this entire effort ? >>> >>>Best, >>>r. >>> >>> >>>On Fri, Dec 19, 2014 at 11:03 AM, wrote= : >>>> Hi, >>>> >>>> I think working of BGP YANG is a good opportunity to start working >>>>on policy framework. >>>> Work on protocols YANG is already hard due to vendor config >>>>disprecancies, I expect policy work to be much harder ... >>>> >>>> But I think, there is an opportunity to start something new for >>>>everyone (that may coexist with existing CLI policies) and not >>>>looking at CLI translation (it will be impossible with policies). >>>>Then it would be up to service providers to request the support of >>>>this by their favorite vendors. >>>> >>>> Best Regards, >>>> >>>> Stephane >>>> >>>> >>>> -----Original Message----- >>>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of >>>> Robert Raszuk >>>> Sent: Wednesday, December 17, 2014 23:28 >>>> To: Jeff Tantsura >>>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; >>>> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka >>>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>>> >>>> So are you saying that formal YANG specification say for BGP by >>>>design will not be compatible with some implementations ? >>>> >>>> Or are you saying that formal design say of BGP protocol will have >>>>to wait few years till YANG for policy spec is complete ? >>>> >>>> Cheers, >>>> r. >>>> >>>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura >>>> wrote: >>>>> Yes, exactly, Robert - the behavior you have described is an >>>>>implementation, not a formal specification. >>>>> >>>>> Regards, >>>>> Jeff >>>>> >>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) >>>>>>wrote: >>>>>> >>>>>> Why is this a problem if the default is to not to redistribute >>>>>>routes between RIBs? Note that it isn=C2=B9t like we have a set of >>>>>>approved routing protocol models that are dependent on this behavior. >>>>>> Acee >>>>>> >>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic >>>>>>>wrote: >>>>>>> >>>>>>> Robert, >>>>>>> >>>>>>> Your proposal is very sensible and I think this is the best >>>>>>> option >>>>>>> >>>>>>> Dean >>>>>>> >>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk >>>>>>>>wrote: >>>>>>>> >>>>>>>> Dean, all >>>>>>>> >>>>>>>> The way I read it currently in section 5.5 there are only two >>>>>>>>route filters proposed (deny-all or allow-all). As we know some >>>>>>>>routing protocols require explicit permission to operate (example: >>>>>>>>EBGP). >>>>>>>> If we remove even those two primitive filters there can be >>>>>>>>impact to other components. >>>>>>>> >>>>>>>> But I do support a separate work for YANG model for policy. I do >>>>>>>> expect this to be a very interesting and involved work >>>>>>>> considering significant diversity of policy languages across all >>>>>>>> implementations today. >>>>>>>> >>>>>>>> Once that work is done we could retire section 5.5 of >>>>>>>> *-netmod-routing-* >>>>>>>> >>>>>>>> Regards, >>>>>>>> r. >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic >>>>>>>>> wrote: >>>>>>>>> I'm in support of removing route filters from the routing cfg >>>>>>>>>model. Route filters should be IMO part of the policy model, in >>>>>>>>>which also ACL model belongs too. Actually, I would argue that >>>>>>>>>the current ACL model is very suitable for route filters. >>>>>>>>> >>>>>>>>> Dean >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtg-yang-coord mailing list >>>>>>> Rtg-yang-coord@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>>> >>>> >>>> ____________________________________________________________________ >>>> __ ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>>exploites ou copies sans autorisation. Si vous avez recu ce message >>>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>>>que les pieces jointes. Les messages electroniques etant susceptibles >>>>d'alteration, Orange decline toute responsabilite si ce message a ete >>>>altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>>privileged information that may be protected by law; they should not >>>>be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender >>>>and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that >>>>have been modified, changed or falsified. >>>> Thank you. >>>> >>> >>>______________________________________________________________________ >>>___ >>>_ >>>_______________________________________________ >>> >>>Ce message et ses pieces jointes peuvent contenir des informations >>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>exploites ou copies sans autorisation. Si vous avez recu ce message >>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>>que les pieces jointes. Les messages electroniques etant susceptibles >>>d'alteration, Orange decline toute responsabilite si ce message a ete >>>altere, deforme ou falsifie. Merci. >>> >>>This message and its attachments may contain confidential or >>>privileged information that may be protected by law; they should not >>>be distributed, used or copied without authorisation. >>>If you have received this email in error, please notify the sender and >>>delete this message and its attachments. >>>As emails may be altered, Orange is not liable for messages that have >>>been modified, changed or falsified. >>>Thank you. >>> >>>_______________________________________________ >>>Rtg-yang-coord mailing list >>>Rtg-yang-coord@ietf.org >>>https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> >>>______________________________________________________________________ >>>___ >>>_ >>>_______________________________________________ >>> >>>Ce message et ses pieces jointes peuvent contenir des informations >>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>exploites ou copies sans autorisation. Si vous avez recu ce message >>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>>que les pieces jointes. Les messages electroniques etant susceptibles >>>d'alteration, Orange decline toute responsabilite si ce message a ete >>>altere, deforme ou falsifie. Merci. >>> >>>This message and its attachments may contain confidential or >>>privileged information that may be protected by law; they should not >>>be distributed, used or copied without authorisation. >>>If you have received this email in error, please notify the sender and >>>delete this message and its attachments. >>>As emails may be altered, Orange is not liable for messages that have >>>been modified, changed or falsified. >>>Thank you. >>> >> > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Thu Dec 25 05:19:56 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBAE1A87BB for ; Thu, 25 Dec 2014 05:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW91nsh70-ac for ; Thu, 25 Dec 2014 05:19:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6101A87B9 for ; Thu, 25 Dec 2014 05:19:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNH91600; Thu, 25 Dec 2014 13:19:42 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Dec 2014 13:19:41 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.46]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 21:19:36 +0800 From: Lizhenbin To: "stephane.litkowski@orange.com" , "Susan Hares" , "'Jeff Tantsura'" , "'Acee Lindem (acee)'" , "'Robert Raszuk'" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwP//wG0AgABaZACAABoGAIAJS+YH Date: Thu, 25 Dec 2014 13:19:36 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D2C6A3B3B@nkgeml506-mbx.china.huawei.com> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> , <00c701d01be0$cbdd5a10$63980e30$@ndzh.com> In-Reply-To: <00c701d01be0$cbdd5a10$63980e30$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/RBi4wzX5SFpyZgVI8IgLLxA6q-A Cc: "rtg-yang-coord@ietf.org" , 'Dean Bogdanovic' , 'Ladislav Lhotka' Subject: [Rtg-yang-coord] =?utf-8?b?562U5aSNOiAgaXNzdWUgOlIwMTogcm91dGUg?= =?utf-8?q?filters?= X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 13:19:54 -0000 SGkgU3RlcGhlbiwNCkkgd29uZGVyIGhvdyB0byBzYXkgSSBhbSBpbnRlcmVzdGVkIDopIEluIGZh Y3QsIHdoZW4gd2UgcHJlcHJhcmUgdGhlIFlhbmcgbW9kZWxzIGZvciBkaWZmZXJlbnQgcm91dGlu ZyBwcm90b2NvbHMgYW5kIE1QTFMgcHJvdG9jb2xzLCBpdCBpcyBmb3VuZCB0aGUgWWFuZyBtb2Rl bHMgZm9yIHRoZSBzdGFuZGFyZCByb3V0ZSBwb2xpY3kgaXMgaW5ldml0YWJsZSB0aG91Z2ggd2Ug YXJlIGFsc28gYXdhcmUgdGhhdCBkZWZpbmluZyB0aGUgWWFuZyBtb2RlbHMgZm9yIHRoZSByb3V0 aW5nIHBvbGljeSB3aWxsIGJlIG1vcmUgZGlmZmljdWx0IHRoYW4gdGhlIFlhbmcgbW9kZWxzIGZv ciB0aGUgcHJvdG9jb2xzLiBJbiBvcmRlciB0byBwdXNoIHRoZSB3b3JrLCBJIGhhdmUgb3JnYW5p emVkIG9uZSBpbnRlcm5hbCB0ZWFtIHRvIGRlZmluZSB0aGUgWWFuZyBtb2RlbHMgZm9yIHRoZSBy b3V0aW5nIHBvbGljeSBhbmQgaXQgd2lsbCBiZSBwdWJsaXNoZWQgc29vbi4gTm93IGl0IHNlZW1z IHRoZXJlIGFyZSBzbyBtYW55IHBlb3BsZSB0aGF0IHdvdWxkIGxpa2UgdG8gaW52b2x2ZSBpbiB0 aGUgd29yaywgY291bGQgd2Ugd29yayBvdXQgdGhlIHBvc3NpYmxlIHdheSBiZWZvcmUgd2UgcHVi bGlzaCB0aGUgWWFuZyBtb2RlbHMgZm9yIHRoZSByb3V0aW5nIHBvbGljeT8NCg0KUmVnYXJkcywN ClJvYmluDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CuWPkeS7tuS6ujogUnRnLXlhbmctY29vcmQgW3J0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5v cmddIOS7o+ihqCBTdXNhbiBIYXJlcyBbc2hhcmVzQG5kemguY29tXQ0K5Y+R6YCB5pe26Ze0OiAy MDE05bm0MTLmnIgyMOaXpSA3OjA5DQrmlLbku7bkuro6ICdKZWZmIFRhbnRzdXJhJzsgJ0FjZWUg TGluZGVtIChhY2VlKSc7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyAnUm9iZXJ0IFJh c3p1aycNCuaKhOmAgTogcnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7ICdEZWFuIEJvZ2Rhbm92aWMn OyAnTGFkaXNsYXYgTGhvdGthJw0K5Li76aKYOiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6 UjAxOiByb3V0ZSBmaWx0ZXJzDQoNClN0ZXBoZW46DQoNCkkgYW0gaW50ZXJlc3RlZC4gIFdlIGhh dmluZyByb3V0aW5nIHBvbGljeSBkaXNjdXNzaW9uIGluIEkyUlMgcmVsYXRpbmcgUEJSDQphbmQg cG9saWN5LiAgSXQgbmVlZHMgdG8gbGluayB0byBhIGJhc2Ugc3BlY2lmaWNhdGlvbi4NCg0KU3Vl DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSdGcteWFuZy1jb29yZCBbbWFp bHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KSmVmZiBU YW50c3VyYQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAxOSwgMjAxNCA0OjM2IFBNDQpUbzogQWNl ZSBMaW5kZW0gKGFjZWUpOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgUm9iZXJ0IFJh c3p1aw0KQ2M6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBEZWFuIEJvZ2Rhbm92aWM7IExhZGlz bGF2IExob3RrYQ0KU3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91 dGUgZmlsdGVycw0KDQpJ4oCZZCBsaWtlIHRvIGJlIGludm9sdmVkLCBhcyB3ZWxsIGFzIGdpdmlu ZyBpdCBhIGhvbWUgaW4gcnRnd2cNCg0KQ2hlZXJzLA0KSmVmZg0KDQoNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KDQo+DQo+T24gMTIvMTkvMTQsIDc6MDAgQU0sICJzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbSINCj48c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IHdy b3RlOg0KPg0KPj5BbmQgcXVlc3Rpb24gOiBXaG8gaXMgaW50ZXJlc3RlZCB0byBzdGFydCBub3cg dGhlIHdvcmsgb24gc3RhbmRhcmQNCj4+cm91dGluZyBwb2xpY3kgPw0KPj4NCj4+DQo+Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IFJ0Zy15YW5nLWNvb3JkIFttYWlsdG86cnRn LXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+QmVoYWxmIE9mIHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tDQo+PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTksIDIwMTQgMTI6 NTkNCj4+VG86IFJvYmVydCBSYXN6dWsNCj4+Q2M6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBB Y2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgSmVmZg0KPj5UYW50c3VyYTsgTGFk aXNsYXYgTGhvdGthDQo+PlN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6 IHJvdXRlIGZpbHRlcnMNCj4+DQo+PlJvYmVydCwNCj4+DQo+PllvdSBhcmUgdG91Y2hpbmcgYW4g aW50ZXJlc3RpbmcgcG9pbnQgOikgSW4gZmFjdCB0aGVyZSBhcmUgdHdvIHdheXMgb2YNCj4+dmll d2luZyB0aGlua3MgOg0KPj4tIHNlcnZpY2UgcHJvdmlkZXJzL2N1c3RvbWVycyB3aG8gd291bGQg bGlrZSB0byB1c2Ugb25seSBzdGFuZGFyZA0KPj5tb2RlbHMgdG8gZmFjaWxpdGF0ZSBuZXR3b3Jr IHByb3Zpc2lvbiAmIG9wZXJhdGlvbg0KPj4tIHZlbmRvcnMgd2hvIG1heSBub3Qgd2FudCB0byBt YWtlIGRldmVsb3BtZW50IHRvIGltcGxlbWVudCBuZXcNCj4+ZmVhdHVyZXMgdG8gYmUgY29tcGxp YW50IHdpdGggYSBzdGFuZGFyZCB5YW5nIG1vZGVsICAoYXMgZGV2IGNvc3QNCj4+bW9uZXkpLiBB cyB5b3UgbWVudGlvbmVkLCBvcGVyYXRpb24gb2YgYm94ZXMgaXMgdG9kYXkgYSBrZXkNCj4+ZGlm ZmVyZW50aWF0b3Igd2hlbiBjaG9vc2luZyBhIHZlbmRvci4NCj4+V2UgY2xlYXJseSB0aGlzIGRp dmVyZ2VuY2UgdG9kYXkgaW4gcHJvZHVjZWQgWWFuZyBtb2RlbCAob3BlcmF0b3INCj4+YXV0aG9y cyBtb2RlbHMgdnMgdmVuZG9yIGF1dGhvcnMgbW9kZWwpDQo+Pg0KPj5BcyBhIHNlcnZpY2UgcHJv dmlkZXIsIEknbSBjbGVhcmx5IHB1c2hpbmcgdG8gdXNlIG9ubHkgc3RhbmRhcmQgbW9kZWwNCj4+ YXQgbGVhc3QgZm9yIG1vc3Qgb2YgdGhlIGJhc2Ugc3RydWN0dXJlIG9mIHNlcnZpY2VzIGFuZCBJ IHdpbGwgcHVzaCBteQ0KPj52ZW5kb3JzIHRvIHN1cHBvcnQgaXQgYXMgbW9yZSBhcyBwb3NzaWJs ZS4gSSB3b3VsZCBzYXkgdGhhdCBtb3JlIHRoYW4NCj4+OTAlIG9mIHBhcmFtZXRlcnMgb2YgYSBz ZXJ2aWNlIGFyZSBjb21tb24gdG8gYWxsIGltcGxlbWVudGF0aW9ucyAoanVzdA0KPj5kZXRhaWxz IGFyZSBjaGFuZ2luZyAgOiBsb2NhbGl6YXRpb24gb2YgdGhlIGNvbmZpZyBzdGF0ZW1lbnQgb3IN Cj4+Z3JhbnVsYXJpdHkgb2YgdGhlIHBhcmFtZXRlcikuIFNvIEkgdGhpbmsgdGhhdCBjcmVhdGlu ZyB1c2FibGUNCj4+c3RhbmRhcmQgbW9kZWwgY2FuIHdvcmsuIFRoZSByZW1haW5pbmcgeCUgY2Fu IGJlIGFkZHJlc3NlZCBieSB2ZW5kb3INCmV4dGVuc2lvbnMuDQo+Pg0KPj5Db21pbmcgYmFjayB0 byByb3V0aW5nIHBvbGljaWVzLiBJIGRvIHRoaW5rIHRoYXQgcmVzdGFydGluZyBhIG5ldw0KPj5m cmFtZXdvcmsgZnJvbSBzdHJhdGNoIGlzIHRoZSByaWdodCB3YXkgdG8gZG8gaXQuIEFuZCBhcyBh bnkgcHJvdG9jb2wNCj4+ZXh0ZW5zaW9uIG9yIGZlYXR1cmUgc3RhbmRhcmRpemVkIGluIElFVEYs IGl0IHdpbGwgYmUgdXAgdG8gY3VzdG9tZXJzDQo+PnRvIHJlcXVlc3QgdGhlaXIgdmVuZG9ycyBm b3IgaW1wbGVtZW50YXRpb25zLg0KPj4NCj4+VG9kYXkgcm91dGluZyBwb2xpY3kgbWFuYWdlbWVu dCBiZXR3ZWVuIGRpZmZlcmVudCB2ZW5kb3JzIGlzIGNyYXp5Lg0KPj5Db25zaWRlciB5b3UgaGF2 ZSBhIFZlbmRvciBYIG5ldHdvcmsgd2l0aCB3aWRlbHkgZGVwbG95ZWQgY29tcGxleA0KPj5yb3V0 aW5nIHBvbGljaWVzLCBhbmQgeW91IHdhbnQgdG8gaW50cm9kdWNlIHRvIHZlbmRvciBZLCB0cmFu c2xhdGlvbg0KPj5vZiByb3V0aW5nIHBvbGljaWVzIGZyb20gbGFuZ3VhZ2UgWCB0byBZIGlzIGEg dmVyeSBjb21wbGV4IHdvcmsuDQo+Pg0KPj5Nb3Jlb3ZlciB3ZSBjYW4gc2VlIHRoYXQgZnJhbWV3 b3JrIG9mIHBvbGljeSBtb2RlbCBpcyBhbHJlYWR5IGV4aXN0aW5nDQo+PmZvciBpbnRlcm5ldCBy ZWdpc3RyaWVzIHVzaW5nIFJQU0wuDQo+Pg0KPj5JIGRvIG5vdCBrbm93IHRvZGF5IHdoZXJlIHRo aXMgWWFuZyBpbml0aWF0aXZlIHdpbGwgZ28gLi4uIGJ1dCBJIHdpbGwNCj4+cHJvbmUgYSBjb25z ZW5zdXMgb24gc3Ryb25nIGFkb3B0aW9uIG9mIHN0YW5kYXJkIFlBTkcgbW9kZWxzIHJhdGhlcg0K Pj50aGFuIHZlbmRvciBzcGVjaWZpYyBvbmx5Lg0KPj4NCj4+DQo+PlN0ZXBoYW5lDQo+Pg0KPj4N Cj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBycmFzenVrQGdt YWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0DQo+ PlJhc3p1aw0KPj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDE5LCAyMDE0IDExOjEwDQo+PlRvOiBM SVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCj4+Q2M6IEplZmYgVGFudHN1cmE7IEFjZWUgTGlu ZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOw0KPj5ydGcteWFuZy1jb29yZEBpZXRmLm9yZzsg TGFkaXNsYXYgTGhvdGthDQo+PlN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpS MDE6IHJvdXRlIGZpbHRlcnMNCj4+DQo+PkhpIFN0ZXBoYW5lLA0KPj4NCj4+VGhhdCBpcyBnb2lu ZyB0byBiZSB2ZXJ5IGludGVyZXN0aW5nIGluZGVlZC4gQ29uc2lkZXJpbmcgdGhhdCBudW1iZXIN Cj4+b2YgY3VzdG9tZXJzIGhhdmUgcGFpZCB2ZW5kb3JzIG1pbGxpb25zIGZvciBjdXN0b21pemVk IGV4dGVuc2lvbnMgYW5kDQo+Pm9ubHkgc29tZSBvZiB0aGVtIG1hZGUgaXQgdG8gSUVURiBkcmFm dHMvcmZjcy4NCj4+DQo+PlNvIHdoYXQgd2lsbCBtb3N0IGxpa2VseSBoYXBwZW4gaXMgZ2VuZXJh bCBZQU5HIG1vZGVsIG9mIG5vdCBtdWNoIHVzZQ0KPj5hbmQgem9vIG9mIHByb3ByaWV0YXJ5IHZl bmRvciBZQU5HIGV4dGVuc2lvbnMgbm90IGNvbXBhdGlibGUgYmV0d2Vlbg0KPj5pbXBsZW1lbnRh dGlvbnMuDQo+Pg0KPj5JcyB0aGlzIHJlYWxseSB3aGVyZSB3ZSB3YW50IHRvIGdvIHdpdGggdGhp cyBlbnRpcmUgZWZmb3J0ID8NCj4+DQo+PkJlc3QsDQo+PnIuDQo+Pg0KPj4NCj4+T24gRnJpLCBE ZWMgMTksIDIwMTQgYXQgMTE6MDMgQU0sICA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+ IHdyb3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4gSSB0aGluayB3b3JraW5nIG9mIEJHUCBZQU5HIGlz IGEgZ29vZCBvcHBvcnR1bml0eSB0byBzdGFydCB3b3JraW5nDQo+Pj5vbiBwb2xpY3kgZnJhbWV3 b3JrLg0KPj4+IFdvcmsgb24gcHJvdG9jb2xzIFlBTkcgaXMgYWxyZWFkeSBoYXJkIGR1ZSB0byB2 ZW5kb3IgY29uZmlnDQo+Pj5kaXNwcmVjYW5jaWVzLCBJIGV4cGVjdCBwb2xpY3kgd29yayB0byBi ZSBtdWNoIGhhcmRlciAuLi4NCj4+Pg0KPj4+IEJ1dCBJIHRoaW5rLCB0aGVyZSBpcyBhbiBvcHBv cnR1bml0eSB0byBzdGFydCBzb21ldGhpbmcgbmV3IGZvcg0KPj4+ZXZlcnlvbmUgKHRoYXQgbWF5 IGNvZXhpc3Qgd2l0aCBleGlzdGluZyBDTEkgcG9saWNpZXMpIGFuZCBub3QNCj4+Pmxvb2tpbmcg YXQgQ0xJIHRyYW5zbGF0aW9uIChpdCB3aWxsIGJlIGltcG9zc2libGUgd2l0aCBwb2xpY2llcyku DQo+Pj5UaGVuIGl0IHdvdWxkIGJlIHVwIHRvIHNlcnZpY2UgcHJvdmlkZXJzIHRvIHJlcXVlc3Qg dGhlIHN1cHBvcnQgb2YNCj4+PnRoaXMgYnkgdGhlaXIgZmF2b3JpdGUgdmVuZG9ycy4NCj4+Pg0K Pj4+IEJlc3QgUmVnYXJkcywNCj4+Pg0KPj4+IFN0ZXBoYW5lDQo+Pj4NCj4+Pg0KPj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0 bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mDQo+Pj4gUm9iZXJ0IFJhc3p1aw0KPj4+ IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTcsIDIwMTQgMjM6MjgNCj4+PiBUbzogSmVmZiBU YW50c3VyYQ0KPj4+IENjOiBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgcnRn LXlhbmctY29vcmRAaWV0Zi5vcmc7DQo+Pj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBM YWRpc2xhdiBMaG90a2ENCj4+PiBTdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6 UjAxOiByb3V0ZSBmaWx0ZXJzDQo+Pj4NCj4+PiBTbyBhcmUgeW91IHNheWluZyB0aGF0IGZvcm1h bCBZQU5HIHNwZWNpZmljYXRpb24gc2F5IGZvciBCR1AgYnkNCj4+PmRlc2lnbiB3aWxsIG5vdCBi ZSBjb21wYXRpYmxlIHdpdGggc29tZSBpbXBsZW1lbnRhdGlvbnMgPw0KPj4+DQo+Pj4gT3IgYXJl IHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwgZGVzaWduIHNheSBvZiBCR1AgcHJvdG9jb2wgd2lsbCBo YXZlDQo+Pj50byB3YWl0IGZldyB5ZWFycyB0aWxsIFlBTkcgZm9yIHBvbGljeSBzcGVjIGlzIGNv bXBsZXRlID8NCj4+Pg0KPj4+IENoZWVycywNCj4+PiByLg0KPj4+DQo+Pj4gT24gV2VkLCBEZWMg MTcsIDIwMTQgYXQgMTE6MTQgUE0sIEplZmYgVGFudHN1cmENCj4+PjxqZWZmLnRhbnRzdXJhQGVy aWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+IFllcywgZXhhY3RseSwgUm9iZXJ0IC0gdGhlIGJlaGF2 aW9yIHlvdSBoYXZlIGRlc2NyaWJlZCBpcyBhbg0KPj4+PmltcGxlbWVudGF0aW9uLCBub3QgYSBm b3JtYWwgc3BlY2lmaWNhdGlvbi4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gSmVmZg0KPj4+ Pg0KPj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCAyOjEyIFBNLCBBY2VlIExpbmRlbSAoYWNlZSkg PGFjZWVAY2lzY28uY29tPg0KPj4+Pj53cm90ZToNCj4+Pj4+DQo+Pj4+PiBXaHkgaXMgdGhpcyBh IHByb2JsZW0gaWYgdGhlIGRlZmF1bHQgaXMgdG8gbm90IHRvIHJlZGlzdHJpYnV0ZQ0KPj4+Pj5y b3V0ZXMgYmV0d2VlbiBSSUJzPyBOb3RlIHRoYXQgaXQgaXNuwrl0IGxpa2Ugd2UgaGF2ZSBhIHNl dCBvZg0KPj4+Pj5hcHByb3ZlZCByb3V0aW5nIHByb3RvY29sIG1vZGVscyB0aGF0IGFyZSBkZXBl bmRlbnQgb24gdGhpcyBiZWhhdmlvci4NCj4+Pj4+IEFjZWUNCj4+Pj4+DQo+Pj4+Pj4gT24gRGVj IDE3LCAyMDE0LCBhdCA1OjA3IFBNLCBEZWFuIEJvZ2Rhbm92aWMgPGRlYW5iQGp1bmlwZXIubmV0 Pg0KPj4+Pj4+d3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBSb2JlcnQsDQo+Pj4+Pj4NCj4+Pj4+PiBZ b3VyIHByb3Bvc2FsIGlzIHZlcnkgc2Vuc2libGUgYW5kIEkgdGhpbmsgdGhpcyBpcyB0aGUgYmVz dA0KPj4+Pj4+IG9wdGlvbg0KPj4+Pj4+DQo+Pj4+Pj4gRGVhbg0KPj4+Pj4+DQo+Pj4+Pj4+IE9u IERlYyAxNywgMjAxNCwgYXQgNDo0OSBQTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ+DQo+Pj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IERlYW4sIGFsbA0KPj4+Pj4+Pg0K Pj4+Pj4+PiBUaGUgd2F5IEkgcmVhZCBpdCBjdXJyZW50bHkgaW4gc2VjdGlvbiA1LjUgdGhlcmUg YXJlIG9ubHkgdHdvDQo+Pj4+Pj4+cm91dGUgZmlsdGVycyBwcm9wb3NlZCAoZGVueS1hbGwgb3Ig YWxsb3ctYWxsKS4gQXMgd2Uga25vdyBzb21lDQo+Pj4+Pj4+cm91dGluZyBwcm90b2NvbHMgcmVx dWlyZSBleHBsaWNpdCBwZXJtaXNzaW9uIHRvIG9wZXJhdGUgKGV4YW1wbGU6DQo+Pj4+Pj4+RUJH UCkuDQo+Pj4+Pj4+IElmIHdlIHJlbW92ZSBldmVuIHRob3NlIHR3byBwcmltaXRpdmUgZmlsdGVy cyB0aGVyZSBjYW4gYmUNCj4+Pj4+Pj5pbXBhY3QgIHRvIG90aGVyIGNvbXBvbmVudHMuDQo+Pj4+ Pj4+DQo+Pj4+Pj4+IEJ1dCBJIGRvIHN1cHBvcnQgYSBzZXBhcmF0ZSB3b3JrIGZvciBZQU5HIG1v ZGVsIGZvciBwb2xpY3kuIEkgZG8NCj4+Pj4+Pj4gZXhwZWN0IHRoaXMgdG8gYmUgYSB2ZXJ5IGlu dGVyZXN0aW5nIGFuZCBpbnZvbHZlZCB3b3JrDQo+Pj4+Pj4+IGNvbnNpZGVyaW5nIHNpZ25pZmlj YW50IGRpdmVyc2l0eSBvZiBwb2xpY3kgbGFuZ3VhZ2VzIGFjcm9zcyBhbGwNCj4+Pj4+Pj4gaW1w bGVtZW50YXRpb25zIHRvZGF5Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbmNlIHRoYXQgd29yayBpcyBk b25lIHdlIGNvdWxkIHJldGlyZSBzZWN0aW9uIDUuNSBvZg0KPj4+Pj4+PiAqLW5ldG1vZC1yb3V0 aW5nLSoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4gci4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDEwOjA5IFBNLCBEZWFuIEJv Z2Rhbm92aWMNCj4+Pj4+Pj4+PGRlYW5iQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+Pj4+Pj4+IEkn bSBpbiBzdXBwb3J0IG9mIHJlbW92aW5nIHJvdXRlIGZpbHRlcnMgZnJvbSB0aGUgcm91dGluZyBj ZmcNCj4+Pj4+Pj4+bW9kZWwuIFJvdXRlIGZpbHRlcnMgc2hvdWxkIGJlIElNTyBwYXJ0IG9mIHRo ZSBwb2xpY3kgbW9kZWwsIGluDQo+Pj4+Pj4+PndoaWNoIGFsc28gQUNMIG1vZGVsIGJlbG9uZ3Mg dG9vLiBBY3R1YWxseSwgSSB3b3VsZCBhcmd1ZSB0aGF0DQo+Pj4+Pj4+PnRoZSBjdXJyZW50IEFD TCBtb2RlbCBpcyB2ZXJ5IHN1aXRhYmxlIGZvciByb3V0ZSBmaWx0ZXJzLg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IERlYW4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQo+ Pj4+Pj4gUnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+Pj4+Pg0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+PiBfXyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pg0KPj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPj4+Y29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+Pj5leHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlDQo+Pj5wYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaQ0KPj4+cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+Pj5kJ2FsdGVyYXRpb24sIE9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUNCj4+ PmFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+Pj4NCj4+PiBUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+PnBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBz aG91bGQgbm90DQo+Pj5iZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KPj4+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPj4+YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4NCj4+PiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0DQo+Pj5oYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4+IFRoYW5rIHlvdS4NCj4+Pg0KPj4NCj4+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5fX18NCj4+Xw0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4NCj4+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPj5leHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl DQo+PnBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpDQo+PnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcw0KPj5kJ2FsdGVyYXRpb24sIE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUNCj4+YWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4+DQo+PlRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPj5wcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdA0K Pj5iZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0K Pj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kDQo+PmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCj4+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlDQo+PmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KPj5UaGFuayB5b3UuDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj5SdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+UnRnLXlhbmct Y29vcmRAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGcteWFuZy1jb29yZA0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5fX18NCj4+Xw0KPj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4NCj4+Q2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z DQo+PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBh cyBldHJlIGRpZmZ1c2VzLA0KPj5leHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlDQo+PnBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpDQo+PnF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp Ymxlcw0KPj5kJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUNCj4+YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4NCj4+DQo+PlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvcg0KPj5wcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdA0KPj5iZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQo+PmRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+QXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+PmJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj5UaGFuayB5b3UuDQo+Pg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUnRnLXlhbmct Y29vcmQgbWFpbGluZyBsaXN0DQpSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUnRnLXlhbmctY29vcmQgbWFpbGlu ZyBsaXN0DQpSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA== From nobody Thu Dec 25 05:33:31 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B91A87BC for ; Thu, 25 Dec 2014 05:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMfZzGSqT7OC for ; Thu, 25 Dec 2014 05:33:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5DF1A87BF for ; Thu, 25 Dec 2014 05:33:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQL96140; Thu, 25 Dec 2014 13:33:17 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Dec 2014 13:33:13 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.46]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 21:33:09 +0800 From: Lizhenbin To: Susan Hares , "'Jeff Tantsura'" , "'Acee Lindem (acee)'" , "stephane.litkowski@orange.com" , "'Robert Raszuk'" Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwP//wG0AgABaZACAABoGAIAJT3IT Date: Thu, 25 Dec 2014 13:33:08 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D2C6A3B57@nkgeml506-mbx.china.huawei.com> References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> , <00c701d01be0$cbdd5a10$63980e30$@ndzh.com> In-Reply-To: <00c701d01be0$cbdd5a10$63980e30$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.217.156.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/QZrXu5Lt_MG9iLlf8MzK69GVTZ8 Cc: "rtg-yang-coord@ietf.org" , 'Dean Bogdanovic' , 'Ladislav Lhotka' Subject: [Rtg-yang-coord] =?utf-8?b?562U5aSNOiAgaXNzdWUgOlIwMTogcm91dGUg?= =?utf-8?q?filters?= X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 13:33:28 -0000 SGkgZm9sa3MsDQpSZWdhcmRpbmcgdGhlIFlhbmcgbW9kZWxzLCBJIGhhdmUgZm9sbG93aW5nIG9w aW5pb24gZm9yIGRpc2N1c3Npb246DQoxLiBXZSB0aGluayB0aGUgZm9yd2FyZGluZywgdG9wb2xv Z3kgYW5kIHBvbGljeSBhcmUgdGhlIGJhc2ljIGNvbXBvbmVudHMgZm9yIEkyUlMuIEl0IGlzIGJl dHRlciB0aGUgWWFuZyBtb2RlbHMgZm9yIHRoZSBwb2xpY3kgc2hvdWxkIGJlIGRlZmluZWQgaW4g dGhlIEkyUlMgV0cgaW5zdGVhZCBvZiBSVEdXRy4gDQoyLiBUaG91Z2ggdGhlIHJvdXRlIHBvbGlj eSBoYXMgbXVjaCByZWxhdGlvbiB3aXRoIEJHUCwgd2UgdGhpbmsgdGhlIHBvbGljeSBzaG91bGQg YmUgaW5kZXBlbmRlbnQgc2luY2UgaXQgbWF5IGJlIHVzZWQgZm9yIG90aGVyIHByb3RvY29scy4g Tm93IElQIHByZWZpeCBsaXN0IGlzIGRlZmluZWQgaW4gQkdQIHlhbmcgbW9kZWxzLiBXZSBob3Bl IGl0IHNob3VsZCBiZSBkZWZpbmVkIGluIHRoZSByb3V0aW5nIHBvbGljeS4gVGhlIGRlY291cGxp bmcgb2YgdGhlIHBvbGljeSBmcm9tIHRoZSBwcm90b2NvbCBtYXkgYmVuZWZpdCB0aGUgWWFuZyBt b2RlbCBkZWZpbml0aW9uIGZvciB0aGUgcG90b2NvbC4NCjMuIFRob3VnaCB3ZSBhcmUgZGVmaW5p bmcgdGhlIFlhbmcgbW9kZWxzIGZvciB0aGUgcm91dGUgcG9saWN5LCB3ZSBhcmUgYXdhcmUgdGhl eSBhcmUgbm90IGZsZXhpYmxlIGVub3VnaCBmb3Igc29tZSBzY2VuYXJpb3MuIENvdWxkIHdlIHN0 YXJ0IHRvIHN0YW5kYXJkaXplIHNvbWUgcG9saWN5IHNwZWNpZmljIGxhbmd1YWdlIHN1Y2ggYXMg UlBTTCB3aGlsZSBkZWZpbmUgdGhlIFlhbmcgbW9kZWxzIGZvciB0aGUgcm91dGluZyBwb2xpY3k/ DQoNCg0KUmVnYXJkcywNClJvYmluDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0K5Y+R5Lu25Lq6OiBSdGcteWFuZy1jb29yZCBbcnRnLXlhbmctY29v cmQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFN1c2FuIEhhcmVzIFtzaGFyZXNAbmR6aC5jb21d DQrlj5HpgIHml7bpl7Q6IDIwMTTlubQxMuaciDIw5pelIDc6MDkNCuaUtuS7tuS6ujogJ0plZmYg VGFudHN1cmEnOyAnQWNlZSBMaW5kZW0gKGFjZWUpJzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb207ICdSb2JlcnQgUmFzenVrJw0K5oqE6YCBOiBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsg J0RlYW4gQm9nZGFub3ZpYyc7ICdMYWRpc2xhdiBMaG90a2EnDQrkuLvpopg6IFJlOiBbUnRnLXlh bmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCg0KU3RlcGhlbjoNCg0KSSBhbSBp bnRlcmVzdGVkLiAgV2UgaGF2aW5nIHJvdXRpbmcgcG9saWN5IGRpc2N1c3Npb24gaW4gSTJSUyBy ZWxhdGluZyBQQlINCmFuZCBwb2xpY3kuICBJdCBuZWVkcyB0byBsaW5rIHRvIGEgYmFzZSBzcGVj aWZpY2F0aW9uLg0KDQpTdWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJ0 Zy15YW5nLWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQpKZWZmIFRhbnRzdXJhDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDE5LCAyMDE0 IDQ6MzYgUE0NClRvOiBBY2VlIExpbmRlbSAoYWNlZSk7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tOyBSb2JlcnQgUmFzenVrDQpDYzogcnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IERlYW4g Qm9nZGFub3ZpYzsgTGFkaXNsYXYgTGhvdGthDQpTdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3Jk XSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0ZXJzDQoNCknigJlkIGxpa2UgdG8gYmUgaW52b2x2ZWQs IGFzIHdlbGwgYXMgZ2l2aW5nIGl0IGEgaG9tZSBpbiBydGd3Zw0KDQpDaGVlcnMsDQpKZWZmDQoN Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4NCj5PbiAxMi8xOS8xNCwgNzow MCBBTSwgInN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIg0KPjxzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+DQo+PkFuZCBxdWVzdGlvbiA6IFdobyBpcyBpbnRlcmVz dGVkIHRvIHN0YXJ0IG5vdyB0aGUgd29yayBvbiBzdGFuZGFyZA0KPj5yb3V0aW5nIHBvbGljeSA/ DQo+Pg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogUnRnLXlhbmct Y29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj5CZWhh bGYgT2Ygc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20NCj4+U2VudDogRnJpZGF5LCBEZWNl bWJlciAxOSwgMjAxNCAxMjo1OQ0KPj5UbzogUm9iZXJ0IFJhc3p1aw0KPj5DYzogcnRnLXlhbmct Y29vcmRAaWV0Zi5vcmc7IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOyBKZWZm DQo+PlRhbnRzdXJhOyBMYWRpc2xhdiBMaG90a2ENCj4+U3ViamVjdDogUmU6IFtSdGcteWFuZy1j b29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0KPj4NCj4+Um9iZXJ0LA0KPj4NCj4+WW91 IGFyZSB0b3VjaGluZyBhbiBpbnRlcmVzdGluZyBwb2ludCA6KSBJbiBmYWN0IHRoZXJlIGFyZSB0 d28gd2F5cyBvZg0KPj52aWV3aW5nIHRoaW5rcyA6DQo+Pi0gc2VydmljZSBwcm92aWRlcnMvY3Vz dG9tZXJzIHdobyB3b3VsZCBsaWtlIHRvIHVzZSBvbmx5IHN0YW5kYXJkDQo+Pm1vZGVscyB0byBm YWNpbGl0YXRlIG5ldHdvcmsgcHJvdmlzaW9uICYgb3BlcmF0aW9uDQo+Pi0gdmVuZG9ycyB3aG8g bWF5IG5vdCB3YW50IHRvIG1ha2UgZGV2ZWxvcG1lbnQgdG8gaW1wbGVtZW50IG5ldw0KPj5mZWF0 dXJlcyB0byBiZSBjb21wbGlhbnQgd2l0aCBhIHN0YW5kYXJkIHlhbmcgbW9kZWwgIChhcyBkZXYg Y29zdA0KPj5tb25leSkuIEFzIHlvdSBtZW50aW9uZWQsIG9wZXJhdGlvbiBvZiBib3hlcyBpcyB0 b2RheSBhIGtleQ0KPj5kaWZmZXJlbnRpYXRvciB3aGVuIGNob29zaW5nIGEgdmVuZG9yLg0KPj5X ZSBjbGVhcmx5IHRoaXMgZGl2ZXJnZW5jZSB0b2RheSBpbiBwcm9kdWNlZCBZYW5nIG1vZGVsIChv cGVyYXRvcg0KPj5hdXRob3JzIG1vZGVscyB2cyB2ZW5kb3IgYXV0aG9ycyBtb2RlbCkNCj4+DQo+ PkFzIGEgc2VydmljZSBwcm92aWRlciwgSSdtIGNsZWFybHkgcHVzaGluZyB0byB1c2Ugb25seSBz dGFuZGFyZCBtb2RlbA0KPj5hdCBsZWFzdCBmb3IgbW9zdCBvZiB0aGUgYmFzZSBzdHJ1Y3R1cmUg b2Ygc2VydmljZXMgYW5kIEkgd2lsbCBwdXNoIG15DQo+PnZlbmRvcnMgdG8gc3VwcG9ydCBpdCBh cyBtb3JlIGFzIHBvc3NpYmxlLiBJIHdvdWxkIHNheSB0aGF0IG1vcmUgdGhhbg0KPj45MCUgb2Yg cGFyYW1ldGVycyBvZiBhIHNlcnZpY2UgYXJlIGNvbW1vbiB0byBhbGwgaW1wbGVtZW50YXRpb25z IChqdXN0DQo+PmRldGFpbHMgYXJlIGNoYW5naW5nICA6IGxvY2FsaXphdGlvbiBvZiB0aGUgY29u ZmlnIHN0YXRlbWVudCBvcg0KPj5ncmFudWxhcml0eSBvZiB0aGUgcGFyYW1ldGVyKS4gU28gSSB0 aGluayB0aGF0IGNyZWF0aW5nIHVzYWJsZQ0KPj5zdGFuZGFyZCBtb2RlbCBjYW4gd29yay4gVGhl IHJlbWFpbmluZyB4JSBjYW4gYmUgYWRkcmVzc2VkIGJ5IHZlbmRvcg0KZXh0ZW5zaW9ucy4NCj4+ DQo+PkNvbWluZyBiYWNrIHRvIHJvdXRpbmcgcG9saWNpZXMuIEkgZG8gdGhpbmsgdGhhdCByZXN0 YXJ0aW5nIGEgbmV3DQo+PmZyYW1ld29yayBmcm9tIHN0cmF0Y2ggaXMgdGhlIHJpZ2h0IHdheSB0 byBkbyBpdC4gQW5kIGFzIGFueSBwcm90b2NvbA0KPj5leHRlbnNpb24gb3IgZmVhdHVyZSBzdGFu ZGFyZGl6ZWQgaW4gSUVURiwgaXQgd2lsbCBiZSB1cCB0byBjdXN0b21lcnMNCj4+dG8gcmVxdWVz dCB0aGVpciB2ZW5kb3JzIGZvciBpbXBsZW1lbnRhdGlvbnMuDQo+Pg0KPj5Ub2RheSByb3V0aW5n IHBvbGljeSBtYW5hZ2VtZW50IGJldHdlZW4gZGlmZmVyZW50IHZlbmRvcnMgaXMgY3JhenkuDQo+ PkNvbnNpZGVyIHlvdSBoYXZlIGEgVmVuZG9yIFggbmV0d29yayB3aXRoIHdpZGVseSBkZXBsb3ll ZCBjb21wbGV4DQo+PnJvdXRpbmcgcG9saWNpZXMsIGFuZCB5b3Ugd2FudCB0byBpbnRyb2R1Y2Ug dG8gdmVuZG9yIFksIHRyYW5zbGF0aW9uDQo+Pm9mIHJvdXRpbmcgcG9saWNpZXMgZnJvbSBsYW5n dWFnZSBYIHRvIFkgaXMgYSB2ZXJ5IGNvbXBsZXggd29yay4NCj4+DQo+Pk1vcmVvdmVyIHdlIGNh biBzZWUgdGhhdCBmcmFtZXdvcmsgb2YgcG9saWN5IG1vZGVsIGlzIGFscmVhZHkgZXhpc3RpbmcN Cj4+Zm9yIGludGVybmV0IHJlZ2lzdHJpZXMgdXNpbmcgUlBTTC4NCj4+DQo+PkkgZG8gbm90IGtu b3cgdG9kYXkgd2hlcmUgdGhpcyBZYW5nIGluaXRpYXRpdmUgd2lsbCBnbyAuLi4gYnV0IEkgd2ls bA0KPj5wcm9uZSBhIGNvbnNlbnN1cyBvbiBzdHJvbmcgYWRvcHRpb24gb2Ygc3RhbmRhcmQgWUFO RyBtb2RlbHMgcmF0aGVyDQo+PnRoYW4gdmVuZG9yIHNwZWNpZmljIG9ubHkuDQo+Pg0KPj4NCj4+ U3RlcGhhbmUNCj4+DQo+Pg0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PkZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJl aGFsZiBPZiBSb2JlcnQNCj4+UmFzenVrDQo+PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTksIDIw MTQgMTE6MTANCj4+VG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KPj5DYzogSmVmZiBU YW50c3VyYTsgQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJvZ2Rhbm92aWM7DQo+PnJ0Zy15YW5n LWNvb3JkQGlldGYub3JnOyBMYWRpc2xhdiBMaG90a2ENCj4+U3ViamVjdDogUmU6IFtSdGcteWFu Zy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0KPj4NCj4+SGkgU3RlcGhhbmUsDQo+ Pg0KPj5UaGF0IGlzIGdvaW5nIHRvIGJlIHZlcnkgaW50ZXJlc3RpbmcgaW5kZWVkLiBDb25zaWRl cmluZyB0aGF0IG51bWJlcg0KPj5vZiBjdXN0b21lcnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWlsbGlv bnMgZm9yIGN1c3RvbWl6ZWQgZXh0ZW5zaW9ucyBhbmQNCj4+b25seSBzb21lIG9mIHRoZW0gbWFk ZSBpdCB0byBJRVRGIGRyYWZ0cy9yZmNzLg0KPj4NCj4+U28gd2hhdCB3aWxsIG1vc3QgbGlrZWx5 IGhhcHBlbiBpcyBnZW5lcmFsIFlBTkcgbW9kZWwgb2Ygbm90IG11Y2ggdXNlDQo+PmFuZCB6b28g b2YgcHJvcHJpZXRhcnkgdmVuZG9yIFlBTkcgZXh0ZW5zaW9ucyBub3QgY29tcGF0aWJsZSBiZXR3 ZWVuDQo+PmltcGxlbWVudGF0aW9ucy4NCj4+DQo+PklzIHRoaXMgcmVhbGx5IHdoZXJlIHdlIHdh bnQgdG8gZ28gd2l0aCB0aGlzIGVudGlyZSBlZmZvcnQgPw0KPj4NCj4+QmVzdCwNCj4+ci4NCj4+ DQo+Pg0KPj5PbiBGcmksIERlYyAxOSwgMjAxNCBhdCAxMTowMyBBTSwgIDxzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pj4gSGksDQo+Pj4NCj4+PiBJIHRoaW5rIHdvcmtp bmcgb2YgQkdQIFlBTkcgaXMgYSBnb29kIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHdvcmtpbmcNCj4+ Pm9uIHBvbGljeSBmcmFtZXdvcmsuDQo+Pj4gV29yayBvbiBwcm90b2NvbHMgWUFORyBpcyBhbHJl YWR5IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWcNCj4+PmRpc3ByZWNhbmNpZXMsIEkgZXhwZWN0 IHBvbGljeSB3b3JrIHRvIGJlIG11Y2ggaGFyZGVyIC4uLg0KPj4+DQo+Pj4gQnV0IEkgdGhpbmss IHRoZXJlIGlzIGFuIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHNvbWV0aGluZyBuZXcgZm9yDQo+Pj5l dmVyeW9uZSAodGhhdCBtYXkgY29leGlzdCB3aXRoIGV4aXN0aW5nIENMSSBwb2xpY2llcykgYW5k IG5vdA0KPj4+bG9va2luZyBhdCBDTEkgdHJhbnNsYXRpb24gKGl0IHdpbGwgYmUgaW1wb3NzaWJs ZSB3aXRoIHBvbGljaWVzKS4NCj4+PlRoZW4gaXQgd291bGQgYmUgdXAgdG8gc2VydmljZSBwcm92 aWRlcnMgdG8gcmVxdWVzdCB0aGUgc3VwcG9ydCBvZg0KPj4+dGhpcyBieSB0aGVpciBmYXZvcml0 ZSB2ZW5kb3JzLg0KPj4+DQo+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+DQo+Pj4gU3RlcGhhbmUNCj4+ Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBycmFzenVr QGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YNCj4+PiBS b2JlcnQgUmFzenVrDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNywgMjAxNCAyMzoy OA0KPj4+IFRvOiBKZWZmIFRhbnRzdXJhDQo+Pj4gQ2M6IEFjZWUgTGluZGVtIChhY2VlKTsgRGVh biBCb2dkYW5vdmljOyBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsNCj4+PiBMSVRLT1dTS0kgU3Rl cGhhbmUgU0NFL0lCTkY7IExhZGlzbGF2IExob3RrYQ0KPj4+IFN1YmplY3Q6IFJlOiBbUnRnLXlh bmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4+Pg0KPj4+IFNvIGFyZSB5b3Ug c2F5aW5nIHRoYXQgZm9ybWFsIFlBTkcgc3BlY2lmaWNhdGlvbiBzYXkgZm9yIEJHUCBieQ0KPj4+ ZGVzaWduIHdpbGwgbm90IGJlIGNvbXBhdGlibGUgd2l0aCBzb21lIGltcGxlbWVudGF0aW9ucyA/ DQo+Pj4NCj4+PiBPciBhcmUgeW91IHNheWluZyB0aGF0IGZvcm1hbCBkZXNpZ24gc2F5IG9mIEJH UCBwcm90b2NvbCB3aWxsIGhhdmUNCj4+PnRvIHdhaXQgZmV3IHllYXJzIHRpbGwgWUFORyBmb3Ig cG9saWN5IHNwZWMgaXMgY29tcGxldGUgPw0KPj4+DQo+Pj4gQ2hlZXJzLA0KPj4+IHIuDQo+Pj4N Cj4+PiBPbiBXZWQsIERlYyAxNywgMjAxNCBhdCAxMToxNCBQTSwgSmVmZiBUYW50c3VyYQ0KPj4+ PGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4gWWVzLCBleGFjdGx5LCBS b2JlcnQgLSB0aGUgYmVoYXZpb3IgeW91IGhhdmUgZGVzY3JpYmVkIGlzIGFuDQo+Pj4+aW1wbGVt ZW50YXRpb24sIG5vdCBhIGZvcm1hbCBzcGVjaWZpY2F0aW9uLg0KPj4+Pg0KPj4+PiBSZWdhcmRz LA0KPj4+PiBKZWZmDQo+Pj4+DQo+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDI6MTIgUE0sIEFj ZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4NCj4+ Pj4+IFdoeSBpcyB0aGlzIGEgcHJvYmxlbSBpZiB0aGUgZGVmYXVsdCBpcyB0byBub3QgdG8gcmVk aXN0cmlidXRlDQo+Pj4+PnJvdXRlcyBiZXR3ZWVuIFJJQnM/IE5vdGUgdGhhdCBpdCBpc27CuXQg bGlrZSB3ZSBoYXZlIGEgc2V0IG9mDQo+Pj4+PmFwcHJvdmVkIHJvdXRpbmcgcHJvdG9jb2wgbW9k ZWxzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiB0aGlzIGJlaGF2aW9yLg0KPj4+Pj4gQWNlZQ0KPj4+ Pj4NCj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDU6MDcgUE0sIERlYW4gQm9nZGFub3ZpYyA8 ZGVhbmJAanVuaXBlci5uZXQ+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IFJvYmVydCwN Cj4+Pj4+Pg0KPj4+Pj4+IFlvdXIgcHJvcG9zYWwgaXMgdmVyeSBzZW5zaWJsZSBhbmQgSSB0aGlu ayB0aGlzIGlzIHRoZSBiZXN0DQo+Pj4+Pj4gb3B0aW9uDQo+Pj4+Pj4NCj4+Pj4+PiBEZWFuDQo+ Pj4+Pj4NCj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCA0OjQ5IFBNLCBSb2JlcnQgUmFzenVr IDxyb2JlcnRAcmFzenVrLm5ldD4NCj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gRGVh biwgYWxsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSB3YXkgSSByZWFkIGl0IGN1cnJlbnRseSBpbiBz ZWN0aW9uIDUuNSB0aGVyZSBhcmUgb25seSB0d28NCj4+Pj4+Pj5yb3V0ZSBmaWx0ZXJzIHByb3Bv c2VkIChkZW55LWFsbCBvciBhbGxvdy1hbGwpLiBBcyB3ZSBrbm93IHNvbWUNCj4+Pj4+Pj5yb3V0 aW5nIHByb3RvY29scyByZXF1aXJlIGV4cGxpY2l0IHBlcm1pc3Npb24gdG8gb3BlcmF0ZSAoZXhh bXBsZToNCj4+Pj4+Pj5FQkdQKS4NCj4+Pj4+Pj4gSWYgd2UgcmVtb3ZlIGV2ZW4gdGhvc2UgdHdv IHByaW1pdGl2ZSBmaWx0ZXJzIHRoZXJlIGNhbiBiZQ0KPj4+Pj4+PmltcGFjdCAgdG8gb3RoZXIg Y29tcG9uZW50cy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQnV0IEkgZG8gc3VwcG9ydCBhIHNlcGFyYXRl IHdvcmsgZm9yIFlBTkcgbW9kZWwgZm9yIHBvbGljeS4gSSBkbw0KPj4+Pj4+PiBleHBlY3QgdGhp cyB0byBiZSBhIHZlcnkgaW50ZXJlc3RpbmcgYW5kIGludm9sdmVkIHdvcmsNCj4+Pj4+Pj4gY29u c2lkZXJpbmcgc2lnbmlmaWNhbnQgZGl2ZXJzaXR5IG9mIHBvbGljeSBsYW5ndWFnZXMgYWNyb3Nz IGFsbA0KPj4+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgdG9kYXkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9u Y2UgdGhhdCB3b3JrIGlzIGRvbmUgd2UgY291bGQgcmV0aXJlIHNlY3Rpb24gNS41IG9mDQo+Pj4+ Pj4+ICotbmV0bW9kLXJvdXRpbmctKg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+ PiByLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gV2VkLCBEZWMgMTcsIDIwMTQgYXQg MTA6MDkgUE0sIERlYW4gQm9nZGFub3ZpYw0KPj4+Pj4+Pj48ZGVhbmJAanVuaXBlci5uZXQ+IHdy b3RlOg0KPj4+Pj4+Pj4gSSdtIGluIHN1cHBvcnQgb2YgcmVtb3Zpbmcgcm91dGUgZmlsdGVycyBm cm9tIHRoZSByb3V0aW5nIGNmZw0KPj4+Pj4+Pj5tb2RlbC4gUm91dGUgZmlsdGVycyBzaG91bGQg YmUgSU1PIHBhcnQgb2YgdGhlIHBvbGljeSBtb2RlbCwgaW4NCj4+Pj4+Pj4+d2hpY2ggYWxzbyBB Q0wgbW9kZWwgYmVsb25ncyB0b28uIEFjdHVhbGx5LCBJIHdvdWxkIGFyZ3VlIHRoYXQNCj4+Pj4+ Pj4+dGhlIGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3VpdGFibGUgZm9yIHJvdXRlIGZpbHRl cnMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRGVhbg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBSdGcteWFuZy1jb29y ZCBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4+Pj4+ DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IF9fIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+DQo+Pj4gQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+Pj5jb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZm dXNlcywNCj4+PmV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UNCj4+PnBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpDQo+Pj5xdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMNCj4+ PmQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZQ0KPj4+YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4+ Pg0KPj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvcg0KPj4+cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4+PmJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+Pj5hbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj4+IEFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4+PmhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+Pj4gVGhhbmsgeW91Lg0KPj4+ DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pl9fXw0KPj5fDQo+Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pg0KPj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4+Y29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVz ZXMsDQo+PmV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UNCj4+cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kNCj4+cXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+PmQnYWx0 ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZQ0KPj5hbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4NCj4+VGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y DQo+PnByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsg dGhleSBzaG91bGQgbm90DQo+PmJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uDQo+PklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4+ZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLg0KPj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4+YmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQo+PlRoYW5rIHlvdS4NCj4+DQo+Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PlJ0Zy15YW5nLWNvb3JkIG1haWxpbmcg bGlzdA0KPj5SdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pl9f Xw0KPj5fDQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pg0KPj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMNCj4+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+PmV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4+cGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kNCj4+cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+PmQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPj5hbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4NCj4+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+PnByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90DQo+PmJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+PklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQNCj4+ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj5BcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUNCj4+YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+PlRoYW5r IHlvdS4NCj4+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNClJ0Zy15YW5nLWNvb3JkQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3Jk DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSdGct eWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNClJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3Jk From nobody Thu Dec 25 16:36:01 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6331A1B0E for ; Thu, 25 Dec 2014 16:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZVRvnAPAf6K for ; Thu, 25 Dec 2014 16:35:57 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FCB1A1AD9 for ; Thu, 25 Dec 2014 16:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18352; q=dns/txt; s=iport; t=1419554156; x=1420763756; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YbKS+2Kpr/NC6RMqg5z6cwTszORDIwD8/kF506wU6n0=; b=eNs/5CtJ/eqxvxEP8hY75ihrJXBwgnVTXYZP9m/BKTkkNPGAqvXwqRNs sZbL/2X45oTB3BTIcdK9XtbDWb2pakWkR35NSGXrNCCbTccp02sDo8YP4 g1avVCJ0iJhsQjglYN74RuhgYhmzBdzY3sxir4g6Vq3UvnSpnG1n4M6GH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgFAAetnFStJV2Y/2dsb2JhbABcgwZSWASDAMNbCoVxAhxrFgEBAQEBfYQMAQEBBAEBASAROgQHDAYBBgIRBAEBAQICIwMCBB8GCxQBBQMKBAENBYgYAxENljacaI9zDYUJAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYhsg0CBSBEBHRgbDYJigUEFjhWHL4FEgQ2CZYIzhVSCHoM5IoNub4EMOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,645,1413244800"; d="scan'208";a="108430982" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 26 Dec 2014 00:35:55 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBQ0ZtbU024053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Dec 2014 00:35:55 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 25 Dec 2014 18:35:54 -0600 From: "Acee Lindem (acee)" To: Lizhenbin , Susan Hares , "'Jeff Tantsura'" , "stephane.litkowski@orange.com" , "'Robert Raszuk'" Thread-Topic: =?utf-8?B?562U5aSNOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZp?= =?utf-8?Q?lters?= Thread-Index: AQHQIKPnc8RLfq0N4UKVnfp4pHJGKA== Date: Fri, 26 Dec 2014 00:35:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/5f0e0DxE1uxBdX-K4W4k1YRcb54 Cc: "rtg-yang-coord@ietf.org" , 'Dean Bogdanovic' , 'Ladislav Lhotka' Subject: Re: [Rtg-yang-coord] =?utf-8?b?562U5aSNOiAgaXNzdWUgOlIwMTogcm91dGUg?= =?utf-8?q?filters?= X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 00:36:00 -0000 Um9iaW4sIA0KDQpBcyB5b3UgaGF2ZSBub3RlZCwgdGhlcmUgaGFzIGFscmVhZHkgYmVlbiBzb21l IHByaW9yIHdvcmsgb24gcm91dGluZw0KcG9saWN5LiBJbiBmYWN0LCBhbGwgdGhlIEJHUCBkcmFm dHMgaGF2ZSBlbGVtZW50cyBvZiByb3V0aW5nIHBvbGljeS4NClRoZXJlZm9yZSwgdGhlIGZhY3Qg dGhhdCB5b3UgaGF2ZSBjaGFydGVyZWQgd29yayBvbiByb3V0aW5nIHBvbGljeSBpcyBieQ0Kbm8g bWVhbnMgYSBndWFyYW50ZWUgdGhhdCB5b3VyIHdvcmsgd2lsbCBiZWNvbWUgdGhlIHN0YW5kYXJk LiBJdCBjYW4sDQpob3dldmVyLCBiZSBhbiBpbnB1dCB0byB0aGUgcHJvY2Vzcy4NCg0KVGhhbmtz LA0KQWNlZSANCg0KT24gMTIvMjUvMTQsIDg6MzMgQU0sICJMaXpoZW5iaW4iIDxsaXpoZW5iaW5A aHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSBmb2xrcywNCj5SZWdhcmRpbmcgdGhlIFlhbmcgbW9k ZWxzLCBJIGhhdmUgZm9sbG93aW5nIG9waW5pb24gZm9yIGRpc2N1c3Npb246DQo+MS4gV2UgdGhp bmsgdGhlIGZvcndhcmRpbmcsIHRvcG9sb2d5IGFuZCBwb2xpY3kgYXJlIHRoZSBiYXNpYyBjb21w b25lbnRzDQo+Zm9yIEkyUlMuIEl0IGlzIGJldHRlciB0aGUgWWFuZyBtb2RlbHMgZm9yIHRoZSBw b2xpY3kgc2hvdWxkIGJlIGRlZmluZWQNCj5pbiB0aGUgSTJSUyBXRyBpbnN0ZWFkIG9mIFJUR1dH Lg0KPjIuIFRob3VnaCB0aGUgcm91dGUgcG9saWN5IGhhcyBtdWNoIHJlbGF0aW9uIHdpdGggQkdQ LCB3ZSB0aGluayB0aGUNCj5wb2xpY3kgc2hvdWxkIGJlIGluZGVwZW5kZW50IHNpbmNlIGl0IG1h eSBiZSB1c2VkIGZvciBvdGhlciBwcm90b2NvbHMuDQo+Tm93IElQIHByZWZpeCBsaXN0IGlzIGRl ZmluZWQgaW4gQkdQIHlhbmcgbW9kZWxzLiBXZSBob3BlIGl0IHNob3VsZCBiZQ0KPmRlZmluZWQg aW4gdGhlIHJvdXRpbmcgcG9saWN5LiBUaGUgZGVjb3VwbGluZyBvZiB0aGUgcG9saWN5IGZyb20g dGhlDQo+cHJvdG9jb2wgbWF5IGJlbmVmaXQgdGhlIFlhbmcgbW9kZWwgZGVmaW5pdGlvbiBmb3Ig dGhlIHBvdG9jb2wuDQo+My4gVGhvdWdoIHdlIGFyZSBkZWZpbmluZyB0aGUgWWFuZyBtb2RlbHMg Zm9yIHRoZSByb3V0ZSBwb2xpY3ksIHdlIGFyZQ0KPmF3YXJlIHRoZXkgYXJlIG5vdCBmbGV4aWJs ZSBlbm91Z2ggZm9yIHNvbWUgc2NlbmFyaW9zLiBDb3VsZCB3ZSBzdGFydCB0bw0KPnN0YW5kYXJk aXplIHNvbWUgcG9saWN5IHNwZWNpZmljIGxhbmd1YWdlIHN1Y2ggYXMgUlBTTCB3aGlsZSBkZWZp bmUgdGhlDQo+WWFuZyBtb2RlbHMgZm9yIHRoZSByb3V0aW5nIHBvbGljeT8NCj4NCj4NCj5SZWdh cmRzLA0KPlJvYmluDQo+DQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPuWPkeS7tuS6ujogUnRnLXlhbmctY29vcmQgW3J0Zy15YW5nLWNvb3Jk LWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBTdXNhbiBIYXJlcw0KPltzaGFyZXNAbmR6aC5jb21d DQo+5Y+R6YCB5pe26Ze0OiAyMDE05bm0MTLmnIgyMOaXpSA3OjA5DQo+5pS25Lu25Lq6OiAnSmVm ZiBUYW50c3VyYSc7ICdBY2VlIExpbmRlbSAoYWNlZSknOw0KPnN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tOyAnUm9iZXJ0IFJhc3p1aycNCj7mioTpgIE6IHJ0Zy15YW5nLWNvb3JkQGlldGYu b3JnOyAnRGVhbiBCb2dkYW5vdmljJzsgJ0xhZGlzbGF2IExob3RrYScNCj7kuLvpopg6IFJlOiBb UnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4NCj5TdGVwaGVuOg0K Pg0KPkkgYW0gaW50ZXJlc3RlZC4gIFdlIGhhdmluZyByb3V0aW5nIHBvbGljeSBkaXNjdXNzaW9u IGluIEkyUlMgcmVsYXRpbmcgUEJSDQo+YW5kIHBvbGljeS4gIEl0IG5lZWRzIHRvIGxpbmsgdG8g YSBiYXNlIHNwZWNpZmljYXRpb24uDQo+DQo+U3VlDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPkplZmYgVGFudHN1cmENCj5TZW50OiBGcmlkYXks IERlY2VtYmVyIDE5LCAyMDE0IDQ6MzYgUE0NCj5UbzogQWNlZSBMaW5kZW0gKGFjZWUpOyBzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgUm9iZXJ0IFJhc3p1aw0KPkNjOiBydGcteWFuZy1j b29yZEBpZXRmLm9yZzsgRGVhbiBCb2dkYW5vdmljOyBMYWRpc2xhdiBMaG90a2ENCj5TdWJqZWN0 OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0ZXJzDQo+DQo+SeKA mWQgbGlrZSB0byBiZSBpbnZvbHZlZCwgYXMgd2VsbCBhcyBnaXZpbmcgaXQgYSBob21lIGluIHJ0 Z3dnDQo+DQo+Q2hlZXJzLA0KPkplZmYNCj4NCj4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPg0KPj4NCj4+T24gMTIvMTkvMTQsIDc6MDAgQU0sICJzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbSINCj4+PHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiB3cm90ZToN Cj4+DQo+Pj5BbmQgcXVlc3Rpb24gOiBXaG8gaXMgaW50ZXJlc3RlZCB0byBzdGFydCBub3cgdGhl IHdvcmsgb24gc3RhbmRhcmQNCj4+PnJvdXRpbmcgcG9saWN5ID8NCj4+Pg0KPj4+DQo+Pj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogUnRnLXlhbmctY29vcmQgW21haWx0bzpy dGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+QmVoYWxmIE9mIHN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tDQo+Pj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDE5LCAyMDE0 IDEyOjU5DQo+Pj5UbzogUm9iZXJ0IFJhc3p1aw0KPj4+Q2M6IHJ0Zy15YW5nLWNvb3JkQGlldGYu b3JnOyBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgSmVmZg0KPj4+VGFudHN1 cmE7IExhZGlzbGF2IExob3RrYQ0KPj4+U3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNz dWUgOlIwMTogcm91dGUgZmlsdGVycw0KPj4+DQo+Pj5Sb2JlcnQsDQo+Pj4NCj4+PllvdSBhcmUg dG91Y2hpbmcgYW4gaW50ZXJlc3RpbmcgcG9pbnQgOikgSW4gZmFjdCB0aGVyZSBhcmUgdHdvIHdh eXMgb2YNCj4+PnZpZXdpbmcgdGhpbmtzIDoNCj4+Pi0gc2VydmljZSBwcm92aWRlcnMvY3VzdG9t ZXJzIHdobyB3b3VsZCBsaWtlIHRvIHVzZSBvbmx5IHN0YW5kYXJkDQo+Pj5tb2RlbHMgdG8gZmFj aWxpdGF0ZSBuZXR3b3JrIHByb3Zpc2lvbiAmIG9wZXJhdGlvbg0KPj4+LSB2ZW5kb3JzIHdobyBt YXkgbm90IHdhbnQgdG8gbWFrZSBkZXZlbG9wbWVudCB0byBpbXBsZW1lbnQgbmV3DQo+Pj5mZWF0 dXJlcyB0byBiZSBjb21wbGlhbnQgd2l0aCBhIHN0YW5kYXJkIHlhbmcgbW9kZWwgIChhcyBkZXYg Y29zdA0KPj4+bW9uZXkpLiBBcyB5b3UgbWVudGlvbmVkLCBvcGVyYXRpb24gb2YgYm94ZXMgaXMg dG9kYXkgYSBrZXkNCj4+PmRpZmZlcmVudGlhdG9yIHdoZW4gY2hvb3NpbmcgYSB2ZW5kb3IuDQo+ Pj5XZSBjbGVhcmx5IHRoaXMgZGl2ZXJnZW5jZSB0b2RheSBpbiBwcm9kdWNlZCBZYW5nIG1vZGVs IChvcGVyYXRvcg0KPj4+YXV0aG9ycyBtb2RlbHMgdnMgdmVuZG9yIGF1dGhvcnMgbW9kZWwpDQo+ Pj4NCj4+PkFzIGEgc2VydmljZSBwcm92aWRlciwgSSdtIGNsZWFybHkgcHVzaGluZyB0byB1c2Ug b25seSBzdGFuZGFyZCBtb2RlbA0KPj4+YXQgbGVhc3QgZm9yIG1vc3Qgb2YgdGhlIGJhc2Ugc3Ry dWN0dXJlIG9mIHNlcnZpY2VzIGFuZCBJIHdpbGwgcHVzaCBteQ0KPj4+dmVuZG9ycyB0byBzdXBw b3J0IGl0IGFzIG1vcmUgYXMgcG9zc2libGUuIEkgd291bGQgc2F5IHRoYXQgbW9yZSB0aGFuDQo+ Pj45MCUgb2YgcGFyYW1ldGVycyBvZiBhIHNlcnZpY2UgYXJlIGNvbW1vbiB0byBhbGwgaW1wbGVt ZW50YXRpb25zIChqdXN0DQo+Pj5kZXRhaWxzIGFyZSBjaGFuZ2luZyAgOiBsb2NhbGl6YXRpb24g b2YgdGhlIGNvbmZpZyBzdGF0ZW1lbnQgb3INCj4+PmdyYW51bGFyaXR5IG9mIHRoZSBwYXJhbWV0 ZXIpLiBTbyBJIHRoaW5rIHRoYXQgY3JlYXRpbmcgdXNhYmxlDQo+Pj5zdGFuZGFyZCBtb2RlbCBj YW4gd29yay4gVGhlIHJlbWFpbmluZyB4JSBjYW4gYmUgYWRkcmVzc2VkIGJ5IHZlbmRvcg0KPmV4 dGVuc2lvbnMuDQo+Pj4NCj4+PkNvbWluZyBiYWNrIHRvIHJvdXRpbmcgcG9saWNpZXMuIEkgZG8g dGhpbmsgdGhhdCByZXN0YXJ0aW5nIGEgbmV3DQo+Pj5mcmFtZXdvcmsgZnJvbSBzdHJhdGNoIGlz IHRoZSByaWdodCB3YXkgdG8gZG8gaXQuIEFuZCBhcyBhbnkgcHJvdG9jb2wNCj4+PmV4dGVuc2lv biBvciBmZWF0dXJlIHN0YW5kYXJkaXplZCBpbiBJRVRGLCBpdCB3aWxsIGJlIHVwIHRvIGN1c3Rv bWVycw0KPj4+dG8gcmVxdWVzdCB0aGVpciB2ZW5kb3JzIGZvciBpbXBsZW1lbnRhdGlvbnMuDQo+ Pj4NCj4+PlRvZGF5IHJvdXRpbmcgcG9saWN5IG1hbmFnZW1lbnQgYmV0d2VlbiBkaWZmZXJlbnQg dmVuZG9ycyBpcyBjcmF6eS4NCj4+PkNvbnNpZGVyIHlvdSBoYXZlIGEgVmVuZG9yIFggbmV0d29y ayB3aXRoIHdpZGVseSBkZXBsb3llZCBjb21wbGV4DQo+Pj5yb3V0aW5nIHBvbGljaWVzLCBhbmQg eW91IHdhbnQgdG8gaW50cm9kdWNlIHRvIHZlbmRvciBZLCB0cmFuc2xhdGlvbg0KPj4+b2Ygcm91 dGluZyBwb2xpY2llcyBmcm9tIGxhbmd1YWdlIFggdG8gWSBpcyBhIHZlcnkgY29tcGxleCB3b3Jr Lg0KPj4+DQo+Pj5Nb3Jlb3ZlciB3ZSBjYW4gc2VlIHRoYXQgZnJhbWV3b3JrIG9mIHBvbGljeSBt b2RlbCBpcyBhbHJlYWR5IGV4aXN0aW5nDQo+Pj5mb3IgaW50ZXJuZXQgcmVnaXN0cmllcyB1c2lu ZyBSUFNMLg0KPj4+DQo+Pj5JIGRvIG5vdCBrbm93IHRvZGF5IHdoZXJlIHRoaXMgWWFuZyBpbml0 aWF0aXZlIHdpbGwgZ28gLi4uIGJ1dCBJIHdpbGwNCj4+PnByb25lIGEgY29uc2Vuc3VzIG9uIHN0 cm9uZyBhZG9wdGlvbiBvZiBzdGFuZGFyZCBZQU5HIG1vZGVscyByYXRoZXINCj4+PnRoYW4gdmVu ZG9yIHNwZWNpZmljIG9ubHkuDQo+Pj4NCj4+Pg0KPj4+U3RlcGhhbmUNCj4+Pg0KPj4+DQo+Pj4N Cj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IHJyYXN6dWtAZ21h aWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQNCj4+ PlJhc3p1aw0KPj4+U2VudDogRnJpZGF5LCBEZWNlbWJlciAxOSwgMjAxNCAxMToxMA0KPj4+VG86 IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORg0KPj4+Q2M6IEplZmYgVGFudHN1cmE7IEFjZWUg TGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOw0KPj4+cnRnLXlhbmctY29vcmRAaWV0Zi5v cmc7IExhZGlzbGF2IExob3RrYQ0KPj4+U3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNz dWUgOlIwMTogcm91dGUgZmlsdGVycw0KPj4+DQo+Pj5IaSBTdGVwaGFuZSwNCj4+Pg0KPj4+VGhh dCBpcyBnb2luZyB0byBiZSB2ZXJ5IGludGVyZXN0aW5nIGluZGVlZC4gQ29uc2lkZXJpbmcgdGhh dCBudW1iZXINCj4+Pm9mIGN1c3RvbWVycyBoYXZlIHBhaWQgdmVuZG9ycyBtaWxsaW9ucyBmb3Ig Y3VzdG9taXplZCBleHRlbnNpb25zIGFuZA0KPj4+b25seSBzb21lIG9mIHRoZW0gbWFkZSBpdCB0 byBJRVRGIGRyYWZ0cy9yZmNzLg0KPj4+DQo+Pj5TbyB3aGF0IHdpbGwgbW9zdCBsaWtlbHkgaGFw cGVuIGlzIGdlbmVyYWwgWUFORyBtb2RlbCBvZiBub3QgbXVjaCB1c2UNCj4+PmFuZCB6b28gb2Yg cHJvcHJpZXRhcnkgdmVuZG9yIFlBTkcgZXh0ZW5zaW9ucyBub3QgY29tcGF0aWJsZSBiZXR3ZWVu DQo+Pj5pbXBsZW1lbnRhdGlvbnMuDQo+Pj4NCj4+PklzIHRoaXMgcmVhbGx5IHdoZXJlIHdlIHdh bnQgdG8gZ28gd2l0aCB0aGlzIGVudGlyZSBlZmZvcnQgPw0KPj4+DQo+Pj5CZXN0LA0KPj4+ci4N Cj4+Pg0KPj4+DQo+Pj5PbiBGcmksIERlYyAxOSwgMjAxNCBhdCAxMTowMyBBTSwgIDxzdGVwaGFu ZS5saXRrb3dza2lAb3JhbmdlLmNvbT4NCj4+Pndyb3RlOg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4g SSB0aGluayB3b3JraW5nIG9mIEJHUCBZQU5HIGlzIGEgZ29vZCBvcHBvcnR1bml0eSB0byBzdGFy dCB3b3JraW5nDQo+Pj4+b24gcG9saWN5IGZyYW1ld29yay4NCj4+Pj4gV29yayBvbiBwcm90b2Nv bHMgWUFORyBpcyBhbHJlYWR5IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWcNCj4+Pj5kaXNwcmVj YW5jaWVzLCBJIGV4cGVjdCBwb2xpY3kgd29yayB0byBiZSBtdWNoIGhhcmRlciAuLi4NCj4+Pj4N Cj4+Pj4gQnV0IEkgdGhpbmssIHRoZXJlIGlzIGFuIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHNvbWV0 aGluZyBuZXcgZm9yDQo+Pj4+ZXZlcnlvbmUgKHRoYXQgbWF5IGNvZXhpc3Qgd2l0aCBleGlzdGlu ZyBDTEkgcG9saWNpZXMpIGFuZCBub3QNCj4+Pj5sb29raW5nIGF0IENMSSB0cmFuc2xhdGlvbiAo aXQgd2lsbCBiZSBpbXBvc3NpYmxlIHdpdGggcG9saWNpZXMpLg0KPj4+PlRoZW4gaXQgd291bGQg YmUgdXAgdG8gc2VydmljZSBwcm92aWRlcnMgdG8gcmVxdWVzdCB0aGUgc3VwcG9ydCBvZg0KPj4+ PnRoaXMgYnkgdGhlaXIgZmF2b3JpdGUgdmVuZG9ycy4NCj4+Pj4NCj4+Pj4gQmVzdCBSZWdhcmRz LA0KPj4+Pg0KPj4+PiBTdGVwaGFuZQ0KPj4+Pg0KPj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtA Z21haWwuY29tXSBPbiBCZWhhbGYgT2YNCj4+Pj4gUm9iZXJ0IFJhc3p1aw0KPj4+PiBTZW50OiBX ZWRuZXNkYXksIERlY2VtYmVyIDE3LCAyMDE0IDIzOjI4DQo+Pj4+IFRvOiBKZWZmIFRhbnRzdXJh DQo+Pj4+IENjOiBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgcnRnLXlhbmct Y29vcmRAaWV0Zi5vcmc7DQo+Pj4+IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjsgTGFkaXNs YXYgTGhvdGthDQo+Pj4+IFN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6 IHJvdXRlIGZpbHRlcnMNCj4+Pj4NCj4+Pj4gU28gYXJlIHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwg WUFORyBzcGVjaWZpY2F0aW9uIHNheSBmb3IgQkdQIGJ5DQo+Pj4+ZGVzaWduIHdpbGwgbm90IGJl IGNvbXBhdGlibGUgd2l0aCBzb21lIGltcGxlbWVudGF0aW9ucyA/DQo+Pj4+DQo+Pj4+IE9yIGFy ZSB5b3Ugc2F5aW5nIHRoYXQgZm9ybWFsIGRlc2lnbiBzYXkgb2YgQkdQIHByb3RvY29sIHdpbGwg aGF2ZQ0KPj4+PnRvIHdhaXQgZmV3IHllYXJzIHRpbGwgWUFORyBmb3IgcG9saWN5IHNwZWMgaXMg Y29tcGxldGUgPw0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+IHIuDQo+Pj4+DQo+Pj4+IE9uIFdl ZCwgRGVjIDE3LCAyMDE0IGF0IDExOjE0IFBNLCBKZWZmIFRhbnRzdXJhDQo+Pj4+PGplZmYudGFu dHN1cmFAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4+IFllcywgZXhhY3RseSwgUm9iZXJ0IC0g dGhlIGJlaGF2aW9yIHlvdSBoYXZlIGRlc2NyaWJlZCBpcyBhbg0KPj4+Pj5pbXBsZW1lbnRhdGlv biwgbm90IGEgZm9ybWFsIHNwZWNpZmljYXRpb24uDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+ Pj4+IEplZmYNCj4+Pj4+DQo+Pj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCAyOjEyIFBNLCBBY2Vl IExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPg0KPj4+Pj4+d3JvdGU6DQo+Pj4+Pj4NCj4+ Pj4+PiBXaHkgaXMgdGhpcyBhIHByb2JsZW0gaWYgdGhlIGRlZmF1bHQgaXMgdG8gbm90IHRvIHJl ZGlzdHJpYnV0ZQ0KPj4+Pj4+cm91dGVzIGJldHdlZW4gUklCcz8gTm90ZSB0aGF0IGl0IGlzbsK5 dCBsaWtlIHdlIGhhdmUgYSBzZXQgb2YNCj4+Pj4+PmFwcHJvdmVkIHJvdXRpbmcgcHJvdG9jb2wg bW9kZWxzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiB0aGlzIGJlaGF2aW9yLg0KPj4+Pj4+IEFjZWUN Cj4+Pj4+Pg0KPj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDU6MDcgUE0sIERlYW4gQm9nZGFu b3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ+DQo+Pj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+ IFJvYmVydCwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gWW91ciBwcm9wb3NhbCBpcyB2ZXJ5IHNlbnNpYmxl IGFuZCBJIHRoaW5rIHRoaXMgaXMgdGhlIGJlc3QNCj4+Pj4+Pj4gb3B0aW9uDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IERlYW4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNDo0OSBQ TSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQo+Pj4+Pj4+Pndyb3RlOg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IERlYW4sIGFsbA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoZSB3YXkgSSBy ZWFkIGl0IGN1cnJlbnRseSBpbiBzZWN0aW9uIDUuNSB0aGVyZSBhcmUgb25seSB0d28NCj4+Pj4+ Pj4+cm91dGUgZmlsdGVycyBwcm9wb3NlZCAoZGVueS1hbGwgb3IgYWxsb3ctYWxsKS4gQXMgd2Ug a25vdyBzb21lDQo+Pj4+Pj4+PnJvdXRpbmcgcHJvdG9jb2xzIHJlcXVpcmUgZXhwbGljaXQgcGVy bWlzc2lvbiB0byBvcGVyYXRlIChleGFtcGxlOg0KPj4+Pj4+Pj5FQkdQKS4NCj4+Pj4+Pj4+IElm IHdlIHJlbW92ZSBldmVuIHRob3NlIHR3byBwcmltaXRpdmUgZmlsdGVycyB0aGVyZSBjYW4gYmUN Cj4+Pj4+Pj4+aW1wYWN0ICB0byBvdGhlciBjb21wb25lbnRzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IEJ1dCBJIGRvIHN1cHBvcnQgYSBzZXBhcmF0ZSB3b3JrIGZvciBZQU5HIG1vZGVsIGZvciBwb2xp Y3kuIEkgZG8NCj4+Pj4+Pj4+IGV4cGVjdCB0aGlzIHRvIGJlIGEgdmVyeSBpbnRlcmVzdGluZyBh bmQgaW52b2x2ZWQgd29yaw0KPj4+Pj4+Pj4gY29uc2lkZXJpbmcgc2lnbmlmaWNhbnQgZGl2ZXJz aXR5IG9mIHBvbGljeSBsYW5ndWFnZXMgYWNyb3NzIGFsbA0KPj4+Pj4+Pj4gaW1wbGVtZW50YXRp b25zIHRvZGF5Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uY2UgdGhhdCB3b3JrIGlzIGRvbmUgd2Ug Y291bGQgcmV0aXJlIHNlY3Rpb24gNS41IG9mDQo+Pj4+Pj4+PiAqLW5ldG1vZC1yb3V0aW5nLSoN Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4gci4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDEwOjA5IFBNLCBEZWFuIEJv Z2Rhbm92aWMNCj4+Pj4+Pj4+PjxkZWFuYkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4+Pj4+Pj4g SSdtIGluIHN1cHBvcnQgb2YgcmVtb3Zpbmcgcm91dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0aW5n IGNmZw0KPj4+Pj4+Pj4+bW9kZWwuIFJvdXRlIGZpbHRlcnMgc2hvdWxkIGJlIElNTyBwYXJ0IG9m IHRoZSBwb2xpY3kgbW9kZWwsIGluDQo+Pj4+Pj4+Pj53aGljaCBhbHNvIEFDTCBtb2RlbCBiZWxv bmdzIHRvby4gQWN0dWFsbHksIEkgd291bGQgYXJndWUgdGhhdA0KPj4+Pj4+Pj4+dGhlIGN1cnJl bnQgQUNMIG1vZGVsIGlzIHZlcnkgc3VpdGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBEZWFuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IFJ0Zy15YW5nLWNvb3JkIG1haWxp bmcgbGlzdA0KPj4+Pj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+Pj4+Pj4NCj4+ Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4gX18gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+DQo+Pj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPj4+PmNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRp ZmZ1c2VzLA0KPj4+PmV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4+Pj5wYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaQ0KPj4+PnF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cw0KPj4+PmQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPj4+PmFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuDQo+Pj4+DQo+Pj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvcg0KPj4+PnByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90DQo+Pj4+YmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+Pj4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ Pj4+YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+Pj4gQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdA0KPj4+PmhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+Pj4+ IFRoYW5rIHlvdS4NCj4+Pj4NCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+X19fDQo+Pj5fDQo+ Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+DQo+ Pj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMNCj4+PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPj4+ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPj4+cGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kNCj4+PnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcw0KPj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+Pj5hbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4+DQo+Pj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+PnByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90DQo+Pj5iZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj4+SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZA0KPj4+ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K Pj4+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlDQo+Pj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N Cj4+PlRoYW5rIHlvdS4NCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PlJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPj4+UnRnLXlh bmctY29vcmRAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRnLXlhbmctY29vcmQNCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+X19fDQo+Pj5fDQo+ Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+DQo+ Pj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMNCj4+PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPj4+ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPj4+cGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kNCj4+PnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcw0KPj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+Pj5hbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4+DQo+Pj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+PnByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90DQo+Pj5iZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj4+SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZA0KPj4+ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K Pj4+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlDQo+Pj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N Cj4+PlRoYW5rIHlvdS4NCj4+Pg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPlJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPlJ0Zy15 YW5nLWNvb3JkQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGcteWFuZy1jb29yZA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+UnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQo+UnRnLXlhbmctY29v cmRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15 YW5nLWNvb3JkDQoNCg== From nobody Thu Dec 25 17:53:25 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BABF1A1B34 for ; Thu, 25 Dec 2014 17:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHInwG3pEcOa for ; Thu, 25 Dec 2014 17:53:18 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72D71A1B38 for ; Thu, 25 Dec 2014 17:53:17 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so7085712qcz.10 for ; Thu, 25 Dec 2014 17:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=Ekrz9BVkap7/JzDh9h3XzaluD0h0j9Z3M7t6e2/QCWQ=; b=njHvgztVad+shHzpbH3UDCpY0pTo6K6OxOv+dd9QVBNteg6Y/1DAKamzpkDb7W7fg5 ToNrW6Ix7QYVrrGyAnGhlv2ZCmYzh6jr/qmdXsCJ0WhMW90SIeYnQz1ASUubzCBOZMXS QatvmIxj95SnWvKbN89JZq9z6+rYHN495Q/X/UJS2wt2Y70YSMO+AQe4CmMUDOV3LJrE 68fJ//YmHhsxl0n1fMJpzHqkptCXcZKfrv+dr+VCEdWZJb+phtieIh8utLhW4kuRorS1 J7jzQGEuKNhMi2HxFJDfYVT6w3VRxCMsPOmjIuxen52J3dH+EXsH0KpNFbWZx0M8Nezf OJPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-type; bh=Ekrz9BVkap7/JzDh9h3XzaluD0h0j9Z3M7t6e2/QCWQ=; b=FehG9kqXF+6978wU9RxXR/ot8sNS81tMae0D/EoESTnbMDymMKuhPzBRtJfGuMIzvD T31X16rflJAa1vUs7aGaQwai864yE6LdI3lDlJltiF3gy6PjpqERB/AnAdHa6M2twa1R cs3btb/N1mQaNHUjKJgnOy0IQPMJhr/c5dqWSMGxdUNWeBps04fGBECdW37h6j/disSu DxLUMh4kxUpgckQL0cMIvuxM7/ewEBCBjEJie1xmXPlDPl1JFVa6cLj1+GDGQxKODzVH WLJuCgkIHFYjWcm//i6N0FxElOgajfsJb3MrX3tcvT3XT2QcsZoviKPlhJArT5EK6eyu Jxfg== X-Gm-Message-State: ALoCoQmrFCF8OXQLcIO2fUb6dqz6hnyLVwJBmB6X1IWE5me+k3ATJAmrCTdicV7hbCkGgsm/FWd5 X-Received: by 10.224.11.129 with SMTP id t1mr63714879qat.29.1419558796676; Thu, 25 Dec 2014 17:53:16 -0800 (PST) MIME-Version: 1.0 References: From: Anees Shaikh Date: Fri, 26 Dec 2014 01:53:16 +0000 Message-ID: To: "Acee Lindem (acee)" , Lizhenbin , Susan Hares , Jeff Tantsura , "stephane.litkowski@orange.com" , Robert Raszuk Content-Type: multipart/alternative; boundary=001a1132ec02d08419050b14c901 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/lM7gOaO5waRmNsyiMl3GVLDrV9o Cc: "rtg-yang-coord@ietf.org" , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] =?utf-8?b?562U5aSNOiBpc3N1ZSA6UjAxOiByb3V0ZSBm?= =?utf-8?q?ilters?= X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 01:53:23 -0000 --001a1132ec02d08419050b14c901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The OpenConfig network operators working group recently published an update to our BGP data model that may be of interest to this discussion. It also included a generalization of routing policy into a separate model to be used across multiple routing protocols, VRFs, etc. Our view is that it is possible to come up with routing policy expression that can be mapped relatively easily to a number of widely used implementations. I'm pasting the announcement email below with a link to the modules for anyone interested. thanks. -- Anees ------------- hi Folks, the working group has published a new version of the BGP model with a number of changes based on additional operator input as well as from the broader community. The updated models are available in the YangModels public github repo. Highlights of the changes: Refactored multiprotocol module with explicit set of supported AFI-SAFI combinations (using YANG identities) in a flattened list. Focus was on common config with more AFI-SAFI specific configuration forthcoming. Refactored BGP policy module to work with a new general routing policy module (see below) by augmenting it with BGP-specific policy options (conditions and actions). Several new configuration items added to base bgp module. The bgp-operational module is largely unchanged -- the next release is expected to contain a significant update. Initial version of a general routing-policy module and associated reusable types module for policy. The routing policy module is currently augmented by the bgp-policy module for bgp-specific routing policy options. The IGP policy items in this version of the module are limited to generic items available in widely used protocols like IS-IS and OSPF. On Thu Dec 25 2014 at 4:36:02 PM Acee Lindem (acee) wrote: > Robin, > > As you have noted, there has already been some prior work on routing > policy. In fact, all the BGP drafts have elements of routing policy. > Therefore, the fact that you have chartered work on routing policy is by > no means a guarantee that your work will become the standard. It can, > however, be an input to the process. > > Thanks, > Acee > > On 12/25/14, 8:33 AM, "Lizhenbin" wrote: > > >Hi folks, > >Regarding the Yang models, I have following opinion for discussion: > >1. We think the forwarding, topology and policy are the basic components > >for I2RS. It is better the Yang models for the policy should be defined > >in the I2RS WG instead of RTGWG. > >2. Though the route policy has much relation with BGP, we think the > >policy should be independent since it may be used for other protocols. > >Now IP prefix list is defined in BGP yang models. We hope it should be > >defined in the routing policy. The decoupling of the policy from the > >protocol may benefit the Yang model definition for the potocol. > >3. Though we are defining the Yang models for the route policy, we are > >aware they are not flexible enough for some scenarios. Could we start to > >standardize some policy specific language such as RPSL while define the > >Yang models for the routing policy? > > > > > >Regards, > >Robin > > > > > > > > > > > >________________________________________ > >=E5=8F=91=E4=BB=B6=E4=BA=BA: Rtg-yang-coord [rtg-yang-coord-bounces@ietf= .org] =E4=BB=A3=E8=A1=A8 Susan Hares > >[shares@ndzh.com] > >=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B412=E6=9C=8820=E6=97= =A5 7:09 > >=E6=94=B6=E4=BB=B6=E4=BA=BA: 'Jeff Tantsura'; 'Acee Lindem (acee)'; > >stephane.litkowski@orange.com; 'Robert Raszuk' > >=E6=8A=84=E9=80=81: rtg-yang-coord@ietf.org; 'Dean Bogdanovic'; 'Ladisla= v Lhotka' > >=E4=B8=BB=E9=A2=98: Re: [Rtg-yang-coord] issue :R01: route filters > > > >Stephen: > > > >I am interested. We having routing policy discussion in I2RS relating P= BR > >and policy. It needs to link to a base specification. > > > >Sue > > > >-----Original Message----- > >From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf > Of > >Jeff Tantsura > >Sent: Friday, December 19, 2014 4:36 PM > >To: Acee Lindem (acee); stephane.litkowski@orange.com; Robert Raszuk > >Cc: rtg-yang-coord@ietf.org; Dean Bogdanovic; Ladislav Lhotka > >Subject: Re: [Rtg-yang-coord] issue :R01: route filters > > > >I=E2=80=99d like to be involved, as well as giving it a home in rtgwg > > > >Cheers, > >Jeff > > > > > > > > > >-----Original Message----- > > > >> > >>On 12/19/14, 7:00 AM, "stephane.litkowski@orange.com" > >> wrote: > >> > >>>And question : Who is interested to start now the work on standard > >>>routing policy ? > >>> > >>> > >>>-----Original Message----- > >>>From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On > >>>Behalf Of stephane.litkowski@orange.com > >>>Sent: Friday, December 19, 2014 12:59 > >>>To: Robert Raszuk > >>>Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff > >>>Tantsura; Ladislav Lhotka > >>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters > >>> > >>>Robert, > >>> > >>>You are touching an interesting point :) In fact there are two ways of > >>>viewing thinks : > >>>- service providers/customers who would like to use only standard > >>>models to facilitate network provision & operation > >>>- vendors who may not want to make development to implement new > >>>features to be compliant with a standard yang model (as dev cost > >>>money). As you mentioned, operation of boxes is today a key > >>>differentiator when choosing a vendor. > >>>We clearly this divergence today in produced Yang model (operator > >>>authors models vs vendor authors model) > >>> > >>>As a service provider, I'm clearly pushing to use only standard model > >>>at least for most of the base structure of services and I will push my > >>>vendors to support it as more as possible. I would say that more than > >>>90% of parameters of a service are common to all implementations (just > >>>details are changing : localization of the config statement or > >>>granularity of the parameter). So I think that creating usable > >>>standard model can work. The remaining x% can be addressed by vendor > >extensions. > >>> > >>>Coming back to routing policies. I do think that restarting a new > >>>framework from stratch is the right way to do it. And as any protocol > >>>extension or feature standardized in IETF, it will be up to customers > >>>to request their vendors for implementations. > >>> > >>>Today routing policy management between different vendors is crazy. > >>>Consider you have a Vendor X network with widely deployed complex > >>>routing policies, and you want to introduce to vendor Y, translation > >>>of routing policies from language X to Y is a very complex work. > >>> > >>>Moreover we can see that framework of policy model is already existing > >>>for internet registries using RPSL. > >>> > >>>I do not know today where this Yang initiative will go ... but I will > >>>prone a consensus on strong adoption of standard YANG models rather > >>>than vendor specific only. > >>> > >>> > >>>Stephane > >>> > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > >>>Raszuk > >>>Sent: Friday, December 19, 2014 11:10 > >>>To: LITKOWSKI Stephane SCE/IBNF > >>>Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic; > >>>rtg-yang-coord@ietf.org; Ladislav Lhotka > >>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters > >>> > >>>Hi Stephane, > >>> > >>>That is going to be very interesting indeed. Considering that number > >>>of customers have paid vendors millions for customized extensions and > >>>only some of them made it to IETF drafts/rfcs. > >>> > >>>So what will most likely happen is general YANG model of not much use > >>>and zoo of proprietary vendor YANG extensions not compatible between > >>>implementations. > >>> > >>>Is this really where we want to go with this entire effort ? > >>> > >>>Best, > >>>r. > >>> > >>> > >>>On Fri, Dec 19, 2014 at 11:03 AM, > >>>wrote: > >>>> Hi, > >>>> > >>>> I think working of BGP YANG is a good opportunity to start working > >>>>on policy framework. > >>>> Work on protocols YANG is already hard due to vendor config > >>>>disprecancies, I expect policy work to be much harder ... > >>>> > >>>> But I think, there is an opportunity to start something new for > >>>>everyone (that may coexist with existing CLI policies) and not > >>>>looking at CLI translation (it will be impossible with policies). > >>>>Then it would be up to service providers to request the support of > >>>>this by their favorite vendors. > >>>> > >>>> Best Regards, > >>>> > >>>> Stephane > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of > >>>> Robert Raszuk > >>>> Sent: Wednesday, December 17, 2014 23:28 > >>>> To: Jeff Tantsura > >>>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; > >>>> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka > >>>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters > >>>> > >>>> So are you saying that formal YANG specification say for BGP by > >>>>design will not be compatible with some implementations ? > >>>> > >>>> Or are you saying that formal design say of BGP protocol will have > >>>>to wait few years till YANG for policy spec is complete ? > >>>> > >>>> Cheers, > >>>> r. > >>>> > >>>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura > >>>> wrote: > >>>>> Yes, exactly, Robert - the behavior you have described is an > >>>>>implementation, not a formal specification. > >>>>> > >>>>> Regards, > >>>>> Jeff > >>>>> > >>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) > >>>>>>wrote: > >>>>>> > >>>>>> Why is this a problem if the default is to not to redistribute > >>>>>>routes between RIBs? Note that it isn=C2=B9t like we have a set of > >>>>>>approved routing protocol models that are dependent on this behavio= r. > >>>>>> Acee > >>>>>> > >>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic > >>>>>>>wrote: > >>>>>>> > >>>>>>> Robert, > >>>>>>> > >>>>>>> Your proposal is very sensible and I think this is the best > >>>>>>> option > >>>>>>> > >>>>>>> Dean > >>>>>>> > >>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk > >>>>>>>>wrote: > >>>>>>>> > >>>>>>>> Dean, all > >>>>>>>> > >>>>>>>> The way I read it currently in section 5.5 there are only two > >>>>>>>>route filters proposed (deny-all or allow-all). As we know some > >>>>>>>>routing protocols require explicit permission to operate (example= : > >>>>>>>>EBGP). > >>>>>>>> If we remove even those two primitive filters there can be > >>>>>>>>impact to other components. > >>>>>>>> > >>>>>>>> But I do support a separate work for YANG model for policy. I do > >>>>>>>> expect this to be a very interesting and involved work > >>>>>>>> considering significant diversity of policy languages across all > >>>>>>>> implementations today. > >>>>>>>> > >>>>>>>> Once that work is done we could retire section 5.5 of > >>>>>>>> *-netmod-routing-* > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> r. > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic > >>>>>>>>> wrote: > >>>>>>>>> I'm in support of removing route filters from the routing cfg > >>>>>>>>>model. Route filters should be IMO part of the policy model, in > >>>>>>>>>which also ACL model belongs too. Actually, I would argue that > >>>>>>>>>the current ACL model is very suitable for route filters. > >>>>>>>>> > >>>>>>>>> Dean > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Rtg-yang-coord mailing list > >>>>>>> Rtg-yang-coord@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >>>>>> > >>>> > >>>> ____________________________________________________________________ > >>>> __ ___________________________________________________ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des informations > >>>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >>>>exploites ou copies sans autorisation. Si vous avez recu ce message > >>>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >>>>que les pieces jointes. Les messages electroniques etant susceptibles > >>>>d'alteration, Orange decline toute responsabilite si ce message a ete > >>>>altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or > >>>>privileged information that may be protected by law; they should not > >>>>be distributed, used or copied without authorisation. > >>>> If you have received this email in error, please notify the sender > >>>>and delete this message and its attachments. > >>>> As emails may be altered, Orange is not liable for messages that > >>>>have been modified, changed or falsified. > >>>> Thank you. > >>>> > >>> > >>>______________________________________________________________________ > >>>___ > >>>_ > >>>_______________________________________________ > >>> > >>>Ce message et ses pieces jointes peuvent contenir des informations > >>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >>>exploites ou copies sans autorisation. Si vous avez recu ce message > >>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >>>que les pieces jointes. Les messages electroniques etant susceptibles > >>>d'alteration, Orange decline toute responsabilite si ce message a ete > >>>altere, deforme ou falsifie. Merci. > >>> > >>>This message and its attachments may contain confidential or > >>>privileged information that may be protected by law; they should not > >>>be distributed, used or copied without authorisation. > >>>If you have received this email in error, please notify the sender and > >>>delete this message and its attachments. > >>>As emails may be altered, Orange is not liable for messages that have > >>>been modified, changed or falsified. > >>>Thank you. > >>> > >>>_______________________________________________ > >>>Rtg-yang-coord mailing list > >>>Rtg-yang-coord@ietf.org > >>>https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >>> > >>>______________________________________________________________________ > >>>___ > >>>_ > >>>_______________________________________________ > >>> > >>>Ce message et ses pieces jointes peuvent contenir des informations > >>>confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >>>exploites ou copies sans autorisation. Si vous avez recu ce message > >>>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >>>que les pieces jointes. Les messages electroniques etant susceptibles > >>>d'alteration, Orange decline toute responsabilite si ce message a ete > >>>altere, deforme ou falsifie. Merci. > >>> > >>>This message and its attachments may contain confidential or > >>>privileged information that may be protected by law; they should not > >>>be distributed, used or copied without authorisation. > >>>If you have received this email in error, please notify the sender and > >>>delete this message and its attachments. > >>>As emails may be altered, Orange is not liable for messages that have > >>>been modified, changed or falsified. > >>>Thank you. > >>> > >> > > > >_______________________________________________ > >Rtg-yang-coord mailing list > >Rtg-yang-coord@ietf.org > >https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > >_______________________________________________ > >Rtg-yang-coord mailing list > >Rtg-yang-coord@ietf.org > >https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > --001a1132ec02d08419050b14c901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The OpenConfig network operators working group recently published an up= date to our BGP data model that may be of interest to this discussion.=C2= =A0 It also included a generalization of routing policy into a separate mod= el to be used across multiple routing protocols, VRFs, etc. =C2=A0 Our view= is that it is possible to come up with routing policy expression that can = be mapped relatively easily to a number of widely used implementations. =C2= =A0 I'm pasting the announcement email below with a link to the modules= for anyone interested.

thanks.
-- Anees

-------------
hi Folks, =C2= =A0the working group has published a new version of the BGP model with a nu= mber of changes based on additional operator input as well as from the broa= der community.

The updated models are available in the=C2= =A0YangModels= public github=C2=A0repo.

Highlights of the changes:
<= div style=3D"margin:0px;padding:0px;border:0px;vertical-align:baseline">
<= /div>
Refactored multiprotocol module with explicit set of supported
AFI-SA= FI combinations (using YANG identities) in a flattened list.
Focus was o= n common config with more AFI-SAFI specific configuration
forthcoming.=

Refactored BGP policy module to work with a new general routing= policy module (see below) by augmenting it with BGP-specific policy option= s (conditions and actions).

Several new configuration items adde= d to base bgp module.

The bgp-operational module is largely unch= anged -- the next release
is expected to contain a significant update.

Initial version of a general routing-policy module and associ= ated
reusable types module for policy.=C2=A0 The routing policy module i= s
currently augmented by the bgp-policy module for bgp-specific
routi= ng policy options.

The IGP policy items in this version of the m= odule are limited to
generic items available in widely used protocols li= ke IS-IS and OSPF.

On Thu Dec 25 2014 at 4:36:02 PM Acee Lindem (acee) <acee@cisco.com> wrote:
Robin,

As you have noted, there has already been some prior work on routing
policy. In fact, all the BGP drafts have elements of routing policy.
Therefore, the fact that you have chartered work on routing policy is by no means a guarantee that your work will become the standard. It can,
however, be an input to the process.

Thanks,
Acee

On 12/25/14, 8:33 AM, "Lizhenbin" <lizhenbin@huawei.com> wrote:

>Hi folks,
>Regarding the Yang models, I have following opinion for discussion:
>1. We think the forwarding, topology and policy are the basic component= s
>for I2RS. It is better the Yang models for the policy should be defined=
>in the I2RS WG instead of RTGWG.
>2. Though the route policy has much relation with BGP, we think the
>policy should be independent since it may be used for other protocols.<= br> >Now IP prefix list is defined in BGP yang models. We hope it should be<= br> >defined in the routing policy. The decoupling of the policy from the >protocol may benefit the Yang model definition for the potocol.
>3. Though we are defining the Yang models for the route policy, we are<= br> >aware they are not flexible enough for some scenarios. Could we start t= o
>standardize some policy specific language such as RPSL while define the=
>Yang models for the routing policy?
>
>
>Regards,
>Robin
>
>
>
>
>
>________________________________________
>=E5=8F=91=E4=BB=B6=E4=BA=BA: Rtg-yang-coord [rtg-yang-coord-bounces@ietf.<= /u>org] =E4=BB=A3=E8=A1=A8 Susan Hares
>[shares@ndzh.com]
>=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B412=E6=9C=8820=E6=97= =A5 7:09
>=E6=94=B6=E4=BB=B6=E4=BA=BA: 'Jeff Tantsura'; 'Acee Lindem = (acee)';
>step= hane.litkowski@orange.com; 'Robert Raszuk'
>=E6=8A=84=E9=80=81: rtg-yang-coord@ietf.org; 'Dean Bogdanovic'; 'La= dislav Lhotka'
>=E4=B8=BB=E9=A2=98: Re: [Rtg-yang-coord] issue :R01: route filters
>
>Stephen:
>
>I am interested.=C2=A0 We having routing policy discussion in I2RS rela= ting PBR
>and policy.=C2=A0 It needs to link to a base specification.
>
>Sue
>
>-----Original Message-----
>From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On B= ehalf Of
>Jeff Tantsura
>Sent: Friday, December 19, 2014 4:36 PM
>To: Acee Lindem (acee); stephane.litkowski@orange.com; Robert Raszuk
>Cc: rtg-ya= ng-coord@ietf.org; Dean Bogdanovic; Ladislav Lhotka
>Subject: Re: [Rtg-yang-coord] issue :R01: route filters
>
>I=E2=80=99d like to be involved, as well as giving it a home in rtgwg >
>Cheers,
>Jeff
>
>
>
>
>-----Original Message-----
>
>>
>>On 12/19/14, 7:00 AM, "stephane.litkowski@orange.com"<= br> >><stephane.litkowski@orange.com> wrote:
>>
>>>And question : Who is interested to start now the work on stand= ard
>>>routing policy ?
>>>
>>>
>>>-----Original Message-----
>>>From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On
>>>Behalf Of stephane.litkowski@orange.com
>>>Sent: Friday, December 19, 2014 12:59
>>>To: Robert Raszuk
>>>Cc: rtg-yang-coord@ietf.org; Acee Lindem (acee); Dean Bogdanovic; Jeff >>>Tantsura; Ladislav Lhotka
>>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters
>>>
>>>Robert,
>>>
>>>You are touching an interesting point :) In fact there are two = ways of
>>>viewing thinks :
>>>- service providers/customers who would like to use only standa= rd
>>>models to facilitate network provision & operation
>>>- vendors who may not want to make development to implement new=
>>>features to be compliant with a standard yang model=C2=A0 (as d= ev cost
>>>money). As you mentioned, operation of boxes is today a key
>>>differentiator when choosing a vendor.
>>>We clearly this divergence today in produced Yang model (operat= or
>>>authors models vs vendor authors model)
>>>
>>>As a service provider, I'm clearly pushing to use only stan= dard model
>>>at least for most of the base structure of services and I will = push my
>>>vendors to support it as more as possible. I would say that mor= e than
>>>90% of parameters of a service are common to all implementation= s (just
>>>details are changing=C2=A0 : localization of the config stateme= nt or
>>>granularity of the parameter). So I think that creating usable<= br> >>>standard model can work. The remaining x% can be addressed by v= endor
>extensions.
>>>
>>>Coming back to routing policies. I do think that restarting a n= ew
>>>framework from stratch is the right way to do it. And as any pr= otocol
>>>extension or feature standardized in IETF, it will be up to cus= tomers
>>>to request their vendors for implementations.
>>>
>>>Today routing policy management between different vendors is cr= azy.
>>>Consider you have a Vendor X network with widely deployed compl= ex
>>>routing policies, and you want to introduce to vendor Y, transl= ation
>>>of routing policies from language X to Y is a very complex work= .
>>>
>>>Moreover we can see that framework of policy model is already e= xisting
>>>for internet registries using RPSL.
>>>
>>>I do not know today where this Yang initiative will go ... but = I will
>>>prone a consensus on strong adoption of standard YANG models ra= ther
>>>than vendor specific only.
>>>
>>>
>>>Stephane
>>>
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: rr= aszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert
>>>Raszuk
>>>Sent: Friday, December 19, 2014 11:10
>>>To: LITKOWSKI Stephane SCE/IBNF
>>>Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic;
>>>rt= g-yang-coord@ietf.org; Ladislav Lhotka
>>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters
>>>
>>>Hi Stephane,
>>>
>>>That is going to be very interesting indeed. Considering that n= umber
>>>of customers have paid vendors millions for customized extensio= ns and
>>>only some of them made it to IETF drafts/rfcs.
>>>
>>>So what will most likely happen is general YANG model of not mu= ch use
>>>and zoo of proprietary vendor YANG extensions not compatible be= tween
>>>implementations.
>>>
>>>Is this really where we want to go with this entire effort ? >>>
>>>Best,
>>>r.
>>>
>>>
>>>On Fri, Dec 19, 2014 at 11:03 AM,=C2=A0 <stephane.litkowski@orange.c= om>
>>>wrote:
>>>> Hi,
>>>>
>>>> I think working of BGP YANG is a good opportunity to start= working
>>>>on policy framework.
>>>> Work on protocols YANG is already hard due to vendor confi= g
>>>>disprecancies, I expect policy work to be much harder ... >>>>
>>>> But I think, there is an opportunity to start something ne= w for
>>>>everyone (that may coexist with existing CLI policies) and = not
>>>>looking at CLI translation (it will be impossible with poli= cies).
>>>>Then it would be up to service providers to request the sup= port of
>>>>this by their favorite vendors.
>>>>
>>>> Best Regards,
>>>>
>>>> Stephane
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of
>>>> Robert Raszuk
>>>> Sent: Wednesday, December 17, 2014 23:28
>>>> To: Jeff Tantsura
>>>> Cc: Acee Lindem (acee); Dean Bogdanovic; rtg-yang-coord@ietf.org; >>>> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka
>>>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters >>>>
>>>> So are you saying that formal YANG specification say for B= GP by
>>>>design will not be compatible with some implementations ? >>>>
>>>> Or are you saying that formal design say of BGP protocol w= ill have
>>>>to wait few years till YANG for policy spec is complete ? >>>>
>>>> Cheers,
>>>> r.
>>>>
>>>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura
>>>><jeff.tantsura@ericsson.com> wrote:
>>>>> Yes, exactly, Robert - the behavior you have described= is an
>>>>>implementation, not a formal specification.
>>>>>
>>>>> Regards,
>>>>> Jeff
>>>>>
>>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) &l= t;acee@cisco.com>= ;
>>>>>>wrote:
>>>>>>
>>>>>> Why is this a problem if the default is to not to = redistribute
>>>>>>routes between RIBs? Note that it isn=C2=B9t like w= e have a set of
>>>>>>approved routing protocol models that are dependent= on this behavior.
>>>>>> Acee
>>>>>>
>>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic &= lt;deanb@juniper.net= >
>>>>>>>wrote:
>>>>>>>
>>>>>>> Robert,
>>>>>>>
>>>>>>> Your proposal is very sensible and I think thi= s is the best
>>>>>>> option
>>>>>>>
>>>>>>> Dean
>>>>>>>
>>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk= <robert@raszuk.n= et>
>>>>>>>>wrote:
>>>>>>>>
>>>>>>>> Dean, all
>>>>>>>>
>>>>>>>> The way I read it currently in section 5.5= there are only two
>>>>>>>>route filters proposed (deny-all or allow-a= ll). As we know some
>>>>>>>>routing protocols require explicit permissi= on to operate (example:
>>>>>>>>EBGP).
>>>>>>>> If we remove even those two primitive filt= ers there can be
>>>>>>>>impact=C2=A0 to other components.
>>>>>>>>
>>>>>>>> But I do support a separate work for YANG = model for policy. I do
>>>>>>>> expect this to be a very interesting and i= nvolved work
>>>>>>>> considering significant diversity of polic= y languages across all
>>>>>>>> implementations today.
>>>>>>>>
>>>>>>>> Once that work is done we could retire sec= tion 5.5 of
>>>>>>>> *-netmod-routing-*
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> r.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean= Bogdanovic
>>>>>>>>><deanb@juniper.net> wrote:
>>>>>>>>> I'm in support of removing route f= ilters from the routing cfg
>>>>>>>>>model. Route filters should be IMO part= of the policy model, in
>>>>>>>>>which also ACL model belongs too. Actua= lly, I would argue that
>>>>>>>>>the current ACL model is very suitable = for route filters.
>>>>>>>>>
>>>>>>>>> Dean
>>>>>>>
>>>>>>> _______________________________________= ________
>>>>>>> Rtg-yang-coord mailing list
>>>>>>> Rtg-yang-coord@ietf.org
>>>>>>> https://www.ietf.org/mailman/li= stinfo/rtg-yang-coord
>>>>>>
>>>>
>>>> ___________________________________________________= _________________
>>>> __ ________________________________________________= ___
>>>>
>>>> Ce message et ses pieces jointes peuvent contenir des info= rmations
>>>>confidentielles ou privilegiees et ne doivent donc pas etre= diffuses,
>>>>exploites ou copies sans autorisation. Si vous avez recu ce= message
>>>>par erreur, veuillez le signaler a l'expediteur et le d= etruire ainsi
>>>>que les pieces jointes. Les messages electroniques etant su= sceptibles
>>>>d'alteration, Orange decline toute responsabilite si ce= message a ete
>>>>altere, deforme ou falsifie. Merci.
>>>>
>>>> This message and its attachments may contain confidential = or
>>>>privileged information that may be protected by law; they s= hould not
>>>>be distributed, used or copied without authorisation.
>>>> If you have received this email in error, please notify th= e sender
>>>>and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for message= s that
>>>>have been modified, changed or falsified.
>>>> Thank you.
>>>>
>>>
>>>________________________________________________________= ______________
>>>___
>>>_
>>>_______________________________________________
>>>
>>>Ce message et ses pieces jointes peuvent contenir des informati= ons
>>>confidentielles ou privilegiees et ne doivent donc pas etre dif= fuses,
>>>exploites ou copies sans autorisation. Si vous avez recu ce mes= sage
>>>par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi
>>>que les pieces jointes. Les messages electroniques etant suscep= tibles
>>>d'alteration, Orange decline toute responsabilite si ce mes= sage a ete
>>>altere, deforme ou falsifie. Merci.
>>>
>>>This message and its attachments may contain confidential or >>>privileged information that may be protected by law; they shoul= d not
>>>be distributed, used or copied without authorisation.
>>>If you have received this email in error, please notify the sen= der and
>>>delete this message and its attachments.
>>>As emails may be altered, Orange is not liable for messages tha= t have
>>>been modified, changed or falsified.
>>>Thank you.
>>>
>>>_______________________________________________
>>>Rtg-yang-coord mailing list
>>>Rt= g-yang-coord@ietf.org
>>>https://www.ietf.org/mailman/listinfo/rtg-yang-<= u>coord
>>>
>>>________________________________________________________= ______________
>>>___
>>>_
>>>_______________________________________________
>>>
>>>Ce message et ses pieces jointes peuvent contenir des informati= ons
>>>confidentielles ou privilegiees et ne doivent donc pas etre dif= fuses,
>>>exploites ou copies sans autorisation. Si vous avez recu ce mes= sage
>>>par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi
>>>que les pieces jointes. Les messages electroniques etant suscep= tibles
>>>d'alteration, Orange decline toute responsabilite si ce mes= sage a ete
>>>altere, deforme ou falsifie. Merci.
>>>
>>>This message and its attachments may contain confidential or >>>privileged information that may be protected by law; they shoul= d not
>>>be distributed, used or copied without authorisation.
>>>If you have received this email in error, please notify the sen= der and
>>>delete this message and its attachments.
>>>As emails may be altered, Orange is not liable for messages tha= t have
>>>been modified, changed or falsified.
>>>Thank you.
>>>
>>
>
>_______________________________________________
>Rtg-yang-coord mailing list
>Rtg-yang-c= oord@ietf.org
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord=
>
>_______________________________________________
>Rtg-yang-coord mailing list
>Rtg-yang-c= oord@ietf.org
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord=

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord= @ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord
--001a1132ec02d08419050b14c901-- From nobody Thu Dec 25 18:35:02 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A021A1B55 for ; Thu, 25 Dec 2014 18:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTadO_3tRMZ8 for ; Thu, 25 Dec 2014 18:34:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9421A1A1B54 for ; Thu, 25 Dec 2014 18:34:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNI24343; Fri, 26 Dec 2014 02:34:54 +0000 (GMT) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Dec 2014 02:34:53 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.207]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Dec 2014 10:34:46 +0800 From: wangzitao To: Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFsPsK01GVgzkOaWRN9dfYCGJySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwP//wG0AgABaZACACUeAB4AA/hvg Date: Fri, 26 Dec 2014 02:34:45 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> 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.138.41.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/i1e0eX0yFpsF6EMkKf5S7e35QEY Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 02:35:00 -0000 SGksIFJvYmVydDoNCldoYXQgYWJvdXQgdGhlIGJhc2ljIG5ldHdvcmsgcG9saWN5IGRyYWZ0IGlu IEkyUlM/DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZXMtaTJycy1ibnAt aW5mby1tb2RlbC0wMQ0KdGhlIGJhc2ljIG5ldHdvcmsgcG9saWN5IG1vZGVsIHByb3Bvc2VkIGlu IHRoZSBhYm92ZSBkcmFmdCBpcyB1c2VkDQphcyB0aGUgYmFzaXMgdG8gYnVpbGQgUEJSIG1vZGVs LCBJIGJlbGlldmUgaXQgYWxzbyBjYW4gYmUgYXBwbGllZCB0byBjb250cm9sIHBsYW5lIHBvbGlj eSBtb2RlbC4NClNlY3Rpb24gNSBvZiB0aGlzIGRyYWZ0IGdpdmVzIGEgQkdQIHBvbGljeSBleGFt cGxlLg0KDQpCUg0KLU1pY2hhZWwNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog UnRnLXlhbmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSDk u6PooaggUm9iZXJ0IFJhc3p1aw0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0MTLmnIgyNeaXpSAxOTox OA0K5pS25Lu25Lq6OiBRaW4gV3UNCuaKhOmAgTogcnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IHN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBEZWFuIEJvZ2Rhbm92aWM7IEplZmYgVGFudHN1 cmE7IExhZGlzbGF2IExob3RrYTsgRGF2aWQgU2luaWNyb3BlOyBBY2VlIExpbmRlbSAoYWNlZSkN CuS4u+mimDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0K DQpRaW4sDQoNCmRyYWZ0LWF0bGFzLWkycnMtcG9saWN5LWZyYW1ld29yay0wMCBjYW4gYmUgaGVs cGZ1bCB0byB0aGlzIHdvcmsuDQoNClRoZSBvdGhlciB0d28gZHJhZnRzIG9uIFBCUiBhcmUgcXVp dGUgaXJyZWxldmFudC4gV2UgYXJlIG5vdCB0YWxraW5nIGFib3V0IFBCUiBoZXJlIGF0IGFsbC4g SXQgaXMganVzdCBvbmUgc3BlY2lmaWMgYXBwbGljYXRpb24gb2YgZGF0YSBwbGFuZSBwb2xpY3ku DQoNCk91ciBlZmZvcnQgZmlyc3QgaXMgdG8gZGVmaW5lIFlBTkcgbW9kZWwgZm9yIGNvbnRyb2wg cGxhbmUgcG9saWN5Lg0KDQpCZXN0LA0Kci4NCg0KDQoNCg0KDQoNCg0KDQpPbiBUaHUsIERlYyAy NSwgMjAxNCBhdCAxMjoxMiBQTSwgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0K PiBKZWZmOg0KPiBJc24ndCB0aGlzIHRvcGljIHN1YnN1bWVkIGludG8gSTJSUz8NCj4gV2hhdCBh bSBJIG1pc3Npbmc/DQo+DQo+IFJlZ2FyZHMhDQo+IC1RaW4NCj4gLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0KPiDlj5Hku7bkuro6IFJ0Zy15YW5nLWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQt Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEplZmYgDQo+IFRhbnRzdXJhDQo+IOWPkemAgeaXtumX tDogMjAxNOW5tDEy5pyIMjDml6UgNTozNg0KPiDmlLbku7bkuro6IEFjZWUgTGluZGVtIChhY2Vl KTsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IFJvYmVydCBSYXN6dWsNCj4g5oqE6YCB OiBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgRGVhbiBCb2dkYW5vdmljOyBMYWRpc2xhdiBMaG90 a2ENCj4g5Li76aKYOiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0 ZXJzDQo+DQo+IEnigJlkIGxpa2UgdG8gYmUgaW52b2x2ZWQsIGFzIHdlbGwgYXMgZ2l2aW5nIGl0 IGEgaG9tZSBpbiBydGd3Zw0KPg0KPiBDaGVlcnMsDQo+IEplZmYNCj4NCj4NCj4NCj4NCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4NCj4+DQo+Pk9uIDEyLzE5LzE0LCA3OjAwIEFNLCAi c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iDQo+PjxzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbT4gd3JvdGU6DQo+Pg0KPj4+QW5kIHF1ZXN0aW9uIDogV2hvIGlzIGludGVyZXN0ZWQg dG8gc3RhcnQgbm93IHRoZSB3b3JrIG9uIHN0YW5kYXJkIA0KPj4+cm91dGluZyBwb2xpY3kgPw0K Pj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBSdGcteWFu Zy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+ QmVoYWxmIE9mIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tDQo+Pj5TZW50OiBGcmlkYXks IERlY2VtYmVyIDE5LCAyMDE0IDEyOjU5DQo+Pj5UbzogUm9iZXJ0IFJhc3p1aw0KPj4+Q2M6IHJ0 Zy15YW5nLWNvb3JkQGlldGYub3JnOyBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3Zp YzsgDQo+Pj5KZWZmIFRhbnRzdXJhOyBMYWRpc2xhdiBMaG90a2ENCj4+PlN1YmplY3Q6IFJlOiBb UnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4+Pg0KPj4+Um9iZXJ0 LA0KPj4+DQo+Pj5Zb3UgYXJlIHRvdWNoaW5nIGFuIGludGVyZXN0aW5nIHBvaW50IDopIEluIGZh Y3QgdGhlcmUgYXJlIHR3byB3YXlzIA0KPj4+b2Ygdmlld2luZyB0aGlua3MgOg0KPj4+LSBzZXJ2 aWNlIHByb3ZpZGVycy9jdXN0b21lcnMgd2hvIHdvdWxkIGxpa2UgdG8gdXNlIG9ubHkgc3RhbmRh cmQgDQo+Pj5tb2RlbHMgdG8gZmFjaWxpdGF0ZSBuZXR3b3JrIHByb3Zpc2lvbiAmIG9wZXJhdGlv bg0KPj4+LSB2ZW5kb3JzIHdobyBtYXkgbm90IHdhbnQgdG8gbWFrZSBkZXZlbG9wbWVudCB0byBp bXBsZW1lbnQgbmV3IA0KPj4+ZmVhdHVyZXMgdG8gYmUgY29tcGxpYW50IHdpdGggYSBzdGFuZGFy ZCB5YW5nIG1vZGVsICAoYXMgZGV2IGNvc3QgDQo+Pj5tb25leSkuIEFzIHlvdSBtZW50aW9uZWQs IG9wZXJhdGlvbiBvZiBib3hlcyBpcyB0b2RheSBhIGtleSANCj4+PmRpZmZlcmVudGlhdG9yIHdo ZW4gY2hvb3NpbmcgYSB2ZW5kb3IuDQo+Pj5XZSBjbGVhcmx5IHRoaXMgZGl2ZXJnZW5jZSB0b2Rh eSBpbiBwcm9kdWNlZCBZYW5nIG1vZGVsIChvcGVyYXRvciANCj4+PmF1dGhvcnMgbW9kZWxzIHZz IHZlbmRvciBhdXRob3JzIG1vZGVsKQ0KPj4+DQo+Pj5BcyBhIHNlcnZpY2UgcHJvdmlkZXIsIEkn bSBjbGVhcmx5IHB1c2hpbmcgdG8gdXNlIG9ubHkgc3RhbmRhcmQgbW9kZWwgDQo+Pj5hdCBsZWFz dCBmb3IgbW9zdCBvZiB0aGUgYmFzZSBzdHJ1Y3R1cmUgb2Ygc2VydmljZXMgYW5kIEkgd2lsbCBw dXNoIA0KPj4+bXkgdmVuZG9ycyB0byBzdXBwb3J0IGl0IGFzIG1vcmUgYXMgcG9zc2libGUuIEkg d291bGQgc2F5IHRoYXQgbW9yZSANCj4+PnRoYW4gOTAlIG9mIHBhcmFtZXRlcnMgb2YgYSBzZXJ2 aWNlIGFyZSBjb21tb24gdG8gYWxsIGltcGxlbWVudGF0aW9ucyANCj4+PihqdXN0IGRldGFpbHMg YXJlIGNoYW5naW5nICA6IGxvY2FsaXphdGlvbiBvZiB0aGUgY29uZmlnIHN0YXRlbWVudCBvciAN Cj4+PmdyYW51bGFyaXR5IG9mIHRoZSBwYXJhbWV0ZXIpLiBTbyBJIHRoaW5rIHRoYXQgY3JlYXRp bmcgdXNhYmxlIA0KPj4+c3RhbmRhcmQgbW9kZWwgY2FuIHdvcmsuIFRoZSByZW1haW5pbmcgeCUg Y2FuIGJlIGFkZHJlc3NlZCBieSB2ZW5kb3IgZXh0ZW5zaW9ucy4NCj4+Pg0KPj4+Q29taW5nIGJh Y2sgdG8gcm91dGluZyBwb2xpY2llcy4gSSBkbyB0aGluayB0aGF0IHJlc3RhcnRpbmcgYSBuZXcg DQo+Pj5mcmFtZXdvcmsgZnJvbSBzdHJhdGNoIGlzIHRoZSByaWdodCB3YXkgdG8gZG8gaXQuIEFu ZCBhcyBhbnkgcHJvdG9jb2wgDQo+Pj5leHRlbnNpb24gb3IgZmVhdHVyZSBzdGFuZGFyZGl6ZWQg aW4gSUVURiwgaXQgd2lsbCBiZSB1cCB0byBjdXN0b21lcnMgDQo+Pj50byByZXF1ZXN0IHRoZWly IHZlbmRvcnMgZm9yIGltcGxlbWVudGF0aW9ucy4NCj4+Pg0KPj4+VG9kYXkgcm91dGluZyBwb2xp Y3kgbWFuYWdlbWVudCBiZXR3ZWVuIGRpZmZlcmVudCB2ZW5kb3JzIGlzIGNyYXp5Lg0KPj4+Q29u c2lkZXIgeW91IGhhdmUgYSBWZW5kb3IgWCBuZXR3b3JrIHdpdGggd2lkZWx5IGRlcGxveWVkIGNv bXBsZXggDQo+Pj5yb3V0aW5nIHBvbGljaWVzLCBhbmQgeW91IHdhbnQgdG8gaW50cm9kdWNlIHRv IHZlbmRvciBZLCB0cmFuc2xhdGlvbiANCj4+Pm9mIHJvdXRpbmcgcG9saWNpZXMgZnJvbSBsYW5n dWFnZSBYIHRvIFkgaXMgYSB2ZXJ5IGNvbXBsZXggd29yay4NCj4+Pg0KPj4+TW9yZW92ZXIgd2Ug Y2FuIHNlZSB0aGF0IGZyYW1ld29yayBvZiBwb2xpY3kgbW9kZWwgaXMgYWxyZWFkeSANCj4+PmV4 aXN0aW5nIGZvciBpbnRlcm5ldCByZWdpc3RyaWVzIHVzaW5nIFJQU0wuDQo+Pj4NCj4+PkkgZG8g bm90IGtub3cgdG9kYXkgd2hlcmUgdGhpcyBZYW5nIGluaXRpYXRpdmUgd2lsbCBnbyAuLi4gYnV0 IEkgd2lsbCANCj4+PnByb25lIGEgY29uc2Vuc3VzIG9uIHN0cm9uZyBhZG9wdGlvbiBvZiBzdGFu ZGFyZCBZQU5HIG1vZGVscyByYXRoZXIgDQo+Pj50aGFuIHZlbmRvciBzcGVjaWZpYyBvbmx5Lg0K Pj4+DQo+Pj4NCj4+PlN0ZXBoYW5lDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6 dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgDQo+Pj5Sb2JlcnQgUmFzenVrDQo+Pj5TZW50OiBG cmlkYXksIERlY2VtYmVyIDE5LCAyMDE0IDExOjEwDQo+Pj5UbzogTElUS09XU0tJIFN0ZXBoYW5l IFNDRS9JQk5GDQo+Pj5DYzogSmVmZiBUYW50c3VyYTsgQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFu IEJvZ2Rhbm92aWM7IA0KPj4+cnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IExhZGlzbGF2IExob3Rr YQ0KPj4+U3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmls dGVycw0KPj4+DQo+Pj5IaSBTdGVwaGFuZSwNCj4+Pg0KPj4+VGhhdCBpcyBnb2luZyB0byBiZSB2 ZXJ5IGludGVyZXN0aW5nIGluZGVlZC4gQ29uc2lkZXJpbmcgdGhhdCBudW1iZXIgDQo+Pj5vZiBj dXN0b21lcnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWlsbGlvbnMgZm9yIGN1c3RvbWl6ZWQgZXh0ZW5z aW9ucyBhbmQgDQo+Pj5vbmx5IHNvbWUgb2YgdGhlbSBtYWRlIGl0IHRvIElFVEYgZHJhZnRzL3Jm Y3MuDQo+Pj4NCj4+PlNvIHdoYXQgd2lsbCBtb3N0IGxpa2VseSBoYXBwZW4gaXMgZ2VuZXJhbCBZ QU5HIG1vZGVsIG9mIG5vdCBtdWNoIHVzZSANCj4+PmFuZCB6b28gb2YgcHJvcHJpZXRhcnkgdmVu ZG9yIFlBTkcgZXh0ZW5zaW9ucyBub3QgY29tcGF0aWJsZSBiZXR3ZWVuIA0KPj4+aW1wbGVtZW50 YXRpb25zLg0KPj4+DQo+Pj5JcyB0aGlzIHJlYWxseSB3aGVyZSB3ZSB3YW50IHRvIGdvIHdpdGgg dGhpcyBlbnRpcmUgZWZmb3J0ID8NCj4+Pg0KPj4+QmVzdCwNCj4+PnIuDQo+Pj4NCj4+Pg0KPj4+ T24gRnJpLCBEZWMgMTksIDIwMTQgYXQgMTE6MDMgQU0sICA8c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20+IHdyb3RlOg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4gSSB0aGluayB3b3JraW5nIG9m IEJHUCBZQU5HIGlzIGEgZ29vZCBvcHBvcnR1bml0eSB0byBzdGFydCB3b3JraW5nIA0KPj4+Pm9u IHBvbGljeSBmcmFtZXdvcmsuDQo+Pj4+IFdvcmsgb24gcHJvdG9jb2xzIFlBTkcgaXMgYWxyZWFk eSBoYXJkIGR1ZSB0byB2ZW5kb3IgY29uZmlnIA0KPj4+PmRpc3ByZWNhbmNpZXMsIEkgZXhwZWN0 IHBvbGljeSB3b3JrIHRvIGJlIG11Y2ggaGFyZGVyIC4uLg0KPj4+Pg0KPj4+PiBCdXQgSSB0aGlu aywgdGhlcmUgaXMgYW4gb3Bwb3J0dW5pdHkgdG8gc3RhcnQgc29tZXRoaW5nIG5ldyBmb3IgDQo+ Pj4+ZXZlcnlvbmUgKHRoYXQgbWF5IGNvZXhpc3Qgd2l0aCBleGlzdGluZyBDTEkgcG9saWNpZXMp IGFuZCBub3QgDQo+Pj4+bG9va2luZyBhdCBDTEkgdHJhbnNsYXRpb24gKGl0IHdpbGwgYmUgaW1w b3NzaWJsZSB3aXRoIHBvbGljaWVzKS4NCj4+Pj5UaGVuIGl0IHdvdWxkIGJlIHVwIHRvIHNlcnZp Y2UgcHJvdmlkZXJzIHRvIHJlcXVlc3QgdGhlIHN1cHBvcnQgb2YgDQo+Pj4+dGhpcyBieSB0aGVp ciBmYXZvcml0ZSB2ZW5kb3JzLg0KPj4+Pg0KPj4+PiBCZXN0IFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+ IFN0ZXBoYW5lDQo+Pj4+DQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4+IEZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9u IEJlaGFsZiBPZiANCj4+Pj4gUm9iZXJ0IFJhc3p1aw0KPj4+PiBTZW50OiBXZWRuZXNkYXksIERl Y2VtYmVyIDE3LCAyMDE0IDIzOjI4DQo+Pj4+IFRvOiBKZWZmIFRhbnRzdXJhDQo+Pj4+IENjOiBB Y2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgcnRnLXlhbmctY29vcmRAaWV0Zi5v cmc7IA0KPj4+PiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IExhZGlzbGF2IExob3RrYQ0K Pj4+PiBTdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0 ZXJzDQo+Pj4+DQo+Pj4+IFNvIGFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9ybWFsIFlBTkcgc3BlY2lm aWNhdGlvbiBzYXkgZm9yIEJHUCBieSANCj4+Pj5kZXNpZ24gd2lsbCBub3QgYmUgY29tcGF0aWJs ZSB3aXRoIHNvbWUgaW1wbGVtZW50YXRpb25zID8NCj4+Pj4NCj4+Pj4gT3IgYXJlIHlvdSBzYXlp bmcgdGhhdCBmb3JtYWwgZGVzaWduIHNheSBvZiBCR1AgcHJvdG9jb2wgd2lsbCBoYXZlIA0KPj4+ PnRvIHdhaXQgZmV3IHllYXJzIHRpbGwgWUFORyBmb3IgcG9saWN5IHNwZWMgaXMgY29tcGxldGUg Pw0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+IHIuDQo+Pj4+DQo+Pj4+IE9uIFdlZCwgRGVjIDE3 LCAyMDE0IGF0IDExOjE0IFBNLCBKZWZmIFRhbnRzdXJhIA0KPj4+PjxqZWZmLnRhbnRzdXJhQGVy aWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+PiBZZXMsIGV4YWN0bHksIFJvYmVydCAtIHRoZSBiZWhh dmlvciB5b3UgaGF2ZSBkZXNjcmliZWQgaXMgYW4gDQo+Pj4+PmltcGxlbWVudGF0aW9uLCBub3Qg YSBmb3JtYWwgc3BlY2lmaWNhdGlvbi4NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4gSmVm Zg0KPj4+Pj4NCj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDI6MTIgUE0sIEFjZWUgTGluZGVt IChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IFdo eSBpcyB0aGlzIGEgcHJvYmxlbSBpZiB0aGUgZGVmYXVsdCBpcyB0byBub3QgdG8gcmVkaXN0cmli dXRlIA0KPj4+Pj4+cm91dGVzIGJldHdlZW4gUklCcz8gTm90ZSB0aGF0IGl0IGlzbsK5dCBsaWtl IHdlIGhhdmUgYSBzZXQgb2YgDQo+Pj4+Pj5hcHByb3ZlZCByb3V0aW5nIHByb3RvY29sIG1vZGVs cyB0aGF0IGFyZSBkZXBlbmRlbnQgb24gdGhpcyBiZWhhdmlvci4NCj4+Pj4+PiBBY2VlDQo+Pj4+ Pj4NCj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCA1OjA3IFBNLCBEZWFuIEJvZ2Rhbm92aWMg PGRlYW5iQGp1bmlwZXIubmV0Pg0KPj4+Pj4+Pndyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSb2Jl cnQsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFlvdXIgcHJvcG9zYWwgaXMgdmVyeSBzZW5zaWJsZSBhbmQg SSB0aGluayB0aGlzIGlzIHRoZSBiZXN0IA0KPj4+Pj4+PiBvcHRpb24NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gRGVhbg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCA0OjQ5IFBNLCBS b2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NCj4+Pj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4gRGVhbiwgYWxsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhlIHdheSBJIHJlYWQg aXQgY3VycmVudGx5IGluIHNlY3Rpb24gNS41IHRoZXJlIGFyZSBvbmx5IHR3byANCj4+Pj4+Pj4+ cm91dGUgZmlsdGVycyBwcm9wb3NlZCAoZGVueS1hbGwgb3IgYWxsb3ctYWxsKS4gQXMgd2Uga25v dyBzb21lIA0KPj4+Pj4+Pj5yb3V0aW5nIHByb3RvY29scyByZXF1aXJlIGV4cGxpY2l0IHBlcm1p c3Npb24gdG8gb3BlcmF0ZSAoZXhhbXBsZToNCj4+Pj4+Pj4+RUJHUCkuDQo+Pj4+Pj4+PiBJZiB3 ZSByZW1vdmUgZXZlbiB0aG9zZSB0d28gcHJpbWl0aXZlIGZpbHRlcnMgdGhlcmUgY2FuIGJlIA0K Pj4+Pj4+Pj5pbXBhY3QgIHRvIG90aGVyIGNvbXBvbmVudHMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g QnV0IEkgZG8gc3VwcG9ydCBhIHNlcGFyYXRlIHdvcmsgZm9yIFlBTkcgbW9kZWwgZm9yIHBvbGlj eS4gSSANCj4+Pj4+Pj4+IGRvIGV4cGVjdCB0aGlzIHRvIGJlIGEgdmVyeSBpbnRlcmVzdGluZyBh bmQgaW52b2x2ZWQgd29yayANCj4+Pj4+Pj4+IGNvbnNpZGVyaW5nIHNpZ25pZmljYW50IGRpdmVy c2l0eSBvZiBwb2xpY3kgbGFuZ3VhZ2VzIGFjcm9zcyANCj4+Pj4+Pj4+IGFsbCBpbXBsZW1lbnRh dGlvbnMgdG9kYXkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT25jZSB0aGF0IHdvcmsgaXMgZG9uZSB3 ZSBjb3VsZCByZXRpcmUgc2VjdGlvbiA1LjUgb2YNCj4+Pj4+Pj4+ICotbmV0bW9kLXJvdXRpbmct Kg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+PiByLg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgMTA6MDkgUE0sIERlYW4g Qm9nZGFub3ZpYyANCj4+Pj4+Pj4+PjxkZWFuYkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4+Pj4+ Pj4gSSdtIGluIHN1cHBvcnQgb2YgcmVtb3Zpbmcgcm91dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0 aW5nIGNmZyANCj4+Pj4+Pj4+Pm1vZGVsLiBSb3V0ZSBmaWx0ZXJzIHNob3VsZCBiZSBJTU8gcGFy dCBvZiB0aGUgcG9saWN5IG1vZGVsLCBpbiANCj4+Pj4+Pj4+PndoaWNoIGFsc28gQUNMIG1vZGVs IGJlbG9uZ3MgdG9vLiBBY3R1YWxseSwgSSB3b3VsZCBhcmd1ZSB0aGF0IA0KPj4+Pj4+Pj4+dGhl IGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3VpdGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBEZWFuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IFJ0Zy15YW5nLWNvb3Jk IG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+Pj4+ Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBfIF9fIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pg0KPj4+PiBDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQo+ Pj4+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFz IGV0cmUgDQo+Pj4+ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IA0KPj4+PmNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgDQo+Pj4+ZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgDQo+Pj4+ ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgDQo+Pj4+c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLg0KPj4+Pg0KPj4+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+Pj4+cHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgDQo+Pj4+ YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+ Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIA0KPj4+PmFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuDQo+Pj4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgDQo+Pj4+aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCj4+Pj4gVGhhbmsgeW91Lg0KPj4+Pg0KPj4+DQo+Pj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pl8NCj4+Pl9fXw0KPj4+Xw0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pg0KPj4+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0KPj4+Y29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIA0KPj4+ ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSANCj4+PnBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIA0KPj4+cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIA0KPj4+ZCdhbHRl cmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIA0KPj4+YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4+Pg0KPj4+ VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIA0KPj4+cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OyB0aGV5IHNob3VsZCBub3QgDQo+Pj5iZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj4+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIA0KPj4+YW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+PkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSANCj4+PmJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4+VGhhbmsgeW91Lg0KPj4+DQo+Pj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+UnRnLXlh bmctY29vcmQgbWFpbGluZyBsaXN0DQo+Pj5SdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KPj4+DQo+ Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pl8NCj4+Pl9fXw0KPj4+Xw0KPj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pg0KPj4+Q2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0KPj4+Y29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUg ZGlmZnVzZXMsIA0KPj4+ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSANCj4+PnBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIA0KPj4+cXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIA0KPj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIA0KPj4+YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCj4+Pg0KPj4+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIA0KPj4+cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgDQo+Pj5iZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj4+SWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIA0KPj4+ YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+PkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSANCj4+PmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4+VGhhbmsg eW91Lg0KPj4+DQo+Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4gUnRnLXlhbmctY29v cmRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGct eWFuZy1jb29yZA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4gUnRnLXlhbmctY29vcmRAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1j b29yZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K UnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQpSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0K From nobody Fri Dec 26 13:52:51 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB15D1AC399 for ; Fri, 26 Dec 2014 13:52:49 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUKZmWsugPZB for ; Fri, 26 Dec 2014 13:52:46 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EB91AC3CA for ; Fri, 26 Dec 2014 13:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18844; q=dns/txt; s=iport; t=1419630767; x=1420840367; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DO7ZMutm2Xnj8hCxNQhtUkV9T8XVTBemkkvYoSTbBnk=; b=HtlTC/4SuKlDlhbffg7Ujnu7KaDopfov5XPjfIPrDZ29y9O44ocJGxbN FjyeyKMskwVJKkCl7QaBzJsEBRZm+n2vFXBRZfOBJMCBSL0z2WCO83rS5 uyggo+34ttLwbJozOvrpm0qdDH+W8z+bUUFVD5EA2q/xHQTygqlnyVlqC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8FAJ3XnVStJV2a/2dsb2JhbABbgwZSWASDAcNdCoVzAhxuFgEBAQEBfYQMAQEBBAEBASAROgsMBAIBBgIRBAEBAQICIwMCAgIfBgsUAQgIAgQBDQWIGAMRDZdBnGiQAA2FCQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGIbINAgUgRAR0YGwcGgmKBQQEEjhWDP4NwgUSBDYJlgjOFVIIegzkig25vgQw5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,649,1413244800"; d="scan'208";a="382788935" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 26 Dec 2014 21:52:46 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBQLqjGW031734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Dec 2014 21:52:45 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.12]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 26 Dec 2014 15:52:45 -0600 From: "Acee Lindem (acee)" To: wangzitao , Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFpVahlro3FNkKmyiTwhxOalZySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4IAAZ1oAgAAeTgCAAACXgP//8nkAgACuOQCACL/QAIAAAYUAgAEAJYCAAO+8AA== Date: Fri, 26 Dec 2014 21:52:45 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/5fupl9K8M7hwh8sKNBzYU-wk8NI Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 21:52:49 -0000 SGkgTWljaGFlbCwgDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgZ3JlYXQgZm9yIHRoZSBwcm92aWRl cnMgdG8gZ2l2ZSB1cyB0aGVpciB2aWV3IG9uIGhvdw0Kcm91dGluZyBwb2xpY3kgc2hvdWxkIGJl IG1vZGVsZWQgYmVmb3JlIGFueW9uZSBnb2VzIGRvd24gdG8gdGhlIGxvdyBsZXZlbA0KWUFORyBk ZWZpbml0aW9ucy4gSSB3aWxsIHJldmlldyB0aGUgaW5mbyBtb2RlbCBpbiB0aGUgcmVmZXJlbmNl ZCBkcmFmdCBhcw0Kd2VsbC4gDQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDEyLzI1LzE0LCA5OjM0 IFBNLCAid2FuZ3ppdGFvIiA8d2FuZ3ppdGFvQGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SGksIFJv YmVydDoNCj5XaGF0IGFib3V0IHRoZSBiYXNpYyBuZXR3b3JrIHBvbGljeSBkcmFmdCBpbiBJMlJT Pw0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJlcy1pMnJzLWJucC1pbmZv LW1vZGVsLTAxDQo+dGhlIGJhc2ljIG5ldHdvcmsgcG9saWN5IG1vZGVsIHByb3Bvc2VkIGluIHRo ZSBhYm92ZSBkcmFmdCBpcyB1c2VkDQo+YXMgdGhlIGJhc2lzIHRvIGJ1aWxkIFBCUiBtb2RlbCwg SSBiZWxpZXZlIGl0IGFsc28gY2FuIGJlIGFwcGxpZWQgdG8NCj5jb250cm9sIHBsYW5lIHBvbGlj eSBtb2RlbC4NCj5TZWN0aW9uIDUgb2YgdGhpcyBkcmFmdCBnaXZlcyBhIEJHUCBwb2xpY3kgZXhh bXBsZS4NCj4NCj5CUg0KPi1NaWNoYWVsDQo+LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPuWPkeS7 tuS6ujogUnRnLXlhbmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYu b3JnXSDku6PooaggUm9iZXJ0DQo+UmFzenVrDQo+5Y+R6YCB5pe26Ze0OiAyMDE05bm0MTLmnIgy NeaXpSAxOToxOA0KPuaUtuS7tuS6ujogUWluIFd1DQo+5oqE6YCBOiBydGcteWFuZy1jb29yZEBp ZXRmLm9yZzsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IERlYW4NCj5Cb2dkYW5vdmlj OyBKZWZmIFRhbnRzdXJhOyBMYWRpc2xhdiBMaG90a2E7IERhdmlkIFNpbmljcm9wZTsgQWNlZSBM aW5kZW0NCj4oYWNlZSkNCj7kuLvpopg6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6 IHJvdXRlIGZpbHRlcnMNCj4NCj5RaW4sDQo+DQo+ZHJhZnQtYXRsYXMtaTJycy1wb2xpY3ktZnJh bWV3b3JrLTAwIGNhbiBiZSBoZWxwZnVsIHRvIHRoaXMgd29yay4NCj4NCj5UaGUgb3RoZXIgdHdv IGRyYWZ0cyBvbiBQQlIgYXJlIHF1aXRlIGlycmVsZXZhbnQuIFdlIGFyZSBub3QgdGFsa2luZw0K PmFib3V0IFBCUiBoZXJlIGF0IGFsbC4gSXQgaXMganVzdCBvbmUgc3BlY2lmaWMgYXBwbGljYXRp b24gb2YgZGF0YSBwbGFuZQ0KPnBvbGljeS4NCj4NCj5PdXIgZWZmb3J0IGZpcnN0IGlzIHRvIGRl ZmluZSBZQU5HIG1vZGVsIGZvciBjb250cm9sIHBsYW5lIHBvbGljeS4NCj4NCj5CZXN0LA0KPnIu DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+T24gVGh1LCBEZWMgMjUsIDIwMTQgYXQgMTI6MTIg UE0sIFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPiB3cm90ZToNCj4+IEplZmY6DQo+PiBJc24n dCB0aGlzIHRvcGljIHN1YnN1bWVkIGludG8gSTJSUz8NCj4+IFdoYXQgYW0gSSBtaXNzaW5nPw0K Pj4NCj4+IFJlZ2FyZHMhDQo+PiAtUWluDQo+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+PiDl j5Hku7bkuro6IFJ0Zy15YW5nLWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0Bp ZXRmLm9yZ10g5Luj6KGoIEplZmYNCj4+IFRhbnRzdXJhDQo+PiDlj5HpgIHml7bpl7Q6IDIwMTTl ubQxMuaciDIw5pelIDU6MzYNCj4+IOaUtuS7tuS6ujogQWNlZSBMaW5kZW0gKGFjZWUpOyBzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgUm9iZXJ0IFJhc3p1aw0KPj4g5oqE6YCBOiBydGct eWFuZy1jb29yZEBpZXRmLm9yZzsgRGVhbiBCb2dkYW5vdmljOyBMYWRpc2xhdiBMaG90a2ENCj4+ IOS4u+mimDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0K Pj4NCj4+IEnigJlkIGxpa2UgdG8gYmUgaW52b2x2ZWQsIGFzIHdlbGwgYXMgZ2l2aW5nIGl0IGEg aG9tZSBpbiBydGd3Zw0KPj4NCj4+IENoZWVycywNCj4+IEplZmYNCj4+DQo+Pg0KPj4NCj4+DQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4NCj4+Pg0KPj4+T24gMTIvMTkvMTQsIDc6 MDAgQU0sICJzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSINCj4+PjxzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj5BbmQgcXVlc3Rpb24gOiBXaG8gaXMg aW50ZXJlc3RlZCB0byBzdGFydCBub3cgdGhlIHdvcmsgb24gc3RhbmRhcmQNCj4+Pj5yb3V0aW5n IHBvbGljeSA/DQo+Pj4+DQo+Pj4+DQo+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj5Gcm9tOiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uDQo+Pj4+QmVoYWxmIE9mIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tDQo+ Pj4+U2VudDogRnJpZGF5LCBEZWNlbWJlciAxOSwgMjAxNCAxMjo1OQ0KPj4+PlRvOiBSb2JlcnQg UmFzenVrDQo+Pj4+Q2M6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBBY2VlIExpbmRlbSAoYWNl ZSk7IERlYW4gQm9nZGFub3ZpYzsNCj4+Pj5KZWZmIFRhbnRzdXJhOyBMYWRpc2xhdiBMaG90a2EN Cj4+Pj5TdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0 ZXJzDQo+Pj4+DQo+Pj4+Um9iZXJ0LA0KPj4+Pg0KPj4+PllvdSBhcmUgdG91Y2hpbmcgYW4gaW50 ZXJlc3RpbmcgcG9pbnQgOikgSW4gZmFjdCB0aGVyZSBhcmUgdHdvIHdheXMNCj4+Pj5vZiB2aWV3 aW5nIHRoaW5rcyA6DQo+Pj4+LSBzZXJ2aWNlIHByb3ZpZGVycy9jdXN0b21lcnMgd2hvIHdvdWxk IGxpa2UgdG8gdXNlIG9ubHkgc3RhbmRhcmQNCj4+Pj5tb2RlbHMgdG8gZmFjaWxpdGF0ZSBuZXR3 b3JrIHByb3Zpc2lvbiAmIG9wZXJhdGlvbg0KPj4+Pi0gdmVuZG9ycyB3aG8gbWF5IG5vdCB3YW50 IHRvIG1ha2UgZGV2ZWxvcG1lbnQgdG8gaW1wbGVtZW50IG5ldw0KPj4+PmZlYXR1cmVzIHRvIGJl IGNvbXBsaWFudCB3aXRoIGEgc3RhbmRhcmQgeWFuZyBtb2RlbCAgKGFzIGRldiBjb3N0DQo+Pj4+ bW9uZXkpLiBBcyB5b3UgbWVudGlvbmVkLCBvcGVyYXRpb24gb2YgYm94ZXMgaXMgdG9kYXkgYSBr ZXkNCj4+Pj5kaWZmZXJlbnRpYXRvciB3aGVuIGNob29zaW5nIGEgdmVuZG9yLg0KPj4+PldlIGNs ZWFybHkgdGhpcyBkaXZlcmdlbmNlIHRvZGF5IGluIHByb2R1Y2VkIFlhbmcgbW9kZWwgKG9wZXJh dG9yDQo+Pj4+YXV0aG9ycyBtb2RlbHMgdnMgdmVuZG9yIGF1dGhvcnMgbW9kZWwpDQo+Pj4+DQo+ Pj4+QXMgYSBzZXJ2aWNlIHByb3ZpZGVyLCBJJ20gY2xlYXJseSBwdXNoaW5nIHRvIHVzZSBvbmx5 IHN0YW5kYXJkIG1vZGVsDQo+Pj4+YXQgbGVhc3QgZm9yIG1vc3Qgb2YgdGhlIGJhc2Ugc3RydWN0 dXJlIG9mIHNlcnZpY2VzIGFuZCBJIHdpbGwgcHVzaA0KPj4+Pm15IHZlbmRvcnMgdG8gc3VwcG9y dCBpdCBhcyBtb3JlIGFzIHBvc3NpYmxlLiBJIHdvdWxkIHNheSB0aGF0IG1vcmUNCj4+Pj50aGFu IDkwJSBvZiBwYXJhbWV0ZXJzIG9mIGEgc2VydmljZSBhcmUgY29tbW9uIHRvIGFsbCBpbXBsZW1l bnRhdGlvbnMNCj4+Pj4oanVzdCBkZXRhaWxzIGFyZSBjaGFuZ2luZyAgOiBsb2NhbGl6YXRpb24g b2YgdGhlIGNvbmZpZyBzdGF0ZW1lbnQgb3INCj4+Pj5ncmFudWxhcml0eSBvZiB0aGUgcGFyYW1l dGVyKS4gU28gSSB0aGluayB0aGF0IGNyZWF0aW5nIHVzYWJsZQ0KPj4+PnN0YW5kYXJkIG1vZGVs IGNhbiB3b3JrLiBUaGUgcmVtYWluaW5nIHglIGNhbiBiZSBhZGRyZXNzZWQgYnkgdmVuZG9yDQo+ Pj4+ZXh0ZW5zaW9ucy4NCj4+Pj4NCj4+Pj5Db21pbmcgYmFjayB0byByb3V0aW5nIHBvbGljaWVz LiBJIGRvIHRoaW5rIHRoYXQgcmVzdGFydGluZyBhIG5ldw0KPj4+PmZyYW1ld29yayBmcm9tIHN0 cmF0Y2ggaXMgdGhlIHJpZ2h0IHdheSB0byBkbyBpdC4gQW5kIGFzIGFueSBwcm90b2NvbA0KPj4+ PmV4dGVuc2lvbiBvciBmZWF0dXJlIHN0YW5kYXJkaXplZCBpbiBJRVRGLCBpdCB3aWxsIGJlIHVw IHRvIGN1c3RvbWVycw0KPj4+PnRvIHJlcXVlc3QgdGhlaXIgdmVuZG9ycyBmb3IgaW1wbGVtZW50 YXRpb25zLg0KPj4+Pg0KPj4+PlRvZGF5IHJvdXRpbmcgcG9saWN5IG1hbmFnZW1lbnQgYmV0d2Vl biBkaWZmZXJlbnQgdmVuZG9ycyBpcyBjcmF6eS4NCj4+Pj5Db25zaWRlciB5b3UgaGF2ZSBhIFZl bmRvciBYIG5ldHdvcmsgd2l0aCB3aWRlbHkgZGVwbG95ZWQgY29tcGxleA0KPj4+PnJvdXRpbmcg cG9saWNpZXMsIGFuZCB5b3Ugd2FudCB0byBpbnRyb2R1Y2UgdG8gdmVuZG9yIFksIHRyYW5zbGF0 aW9uDQo+Pj4+b2Ygcm91dGluZyBwb2xpY2llcyBmcm9tIGxhbmd1YWdlIFggdG8gWSBpcyBhIHZl cnkgY29tcGxleCB3b3JrLg0KPj4+Pg0KPj4+Pk1vcmVvdmVyIHdlIGNhbiBzZWUgdGhhdCBmcmFt ZXdvcmsgb2YgcG9saWN5IG1vZGVsIGlzIGFscmVhZHkNCj4+Pj5leGlzdGluZyBmb3IgaW50ZXJu ZXQgcmVnaXN0cmllcyB1c2luZyBSUFNMLg0KPj4+Pg0KPj4+PkkgZG8gbm90IGtub3cgdG9kYXkg d2hlcmUgdGhpcyBZYW5nIGluaXRpYXRpdmUgd2lsbCBnbyAuLi4gYnV0IEkgd2lsbA0KPj4+PnBy b25lIGEgY29uc2Vuc3VzIG9uIHN0cm9uZyBhZG9wdGlvbiBvZiBzdGFuZGFyZCBZQU5HIG1vZGVs cyByYXRoZXINCj4+Pj50aGFuIHZlbmRvciBzcGVjaWZpYyBvbmx5Lg0KPj4+Pg0KPj4+Pg0KPj4+ PlN0ZXBoYW5lDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj5Gcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tXSBPbiBCZWhhbGYgT2YNCj4+Pj5Sb2JlcnQgUmFzenVrDQo+Pj4+U2VudDogRnJpZGF5 LCBEZWNlbWJlciAxOSwgMjAxNCAxMToxMA0KPj4+PlRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NF L0lCTkYNCj4+Pj5DYzogSmVmZiBUYW50c3VyYTsgQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJv Z2Rhbm92aWM7DQo+Pj4+cnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IExhZGlzbGF2IExob3RrYQ0K Pj4+PlN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRl cnMNCj4+Pj4NCj4+Pj5IaSBTdGVwaGFuZSwNCj4+Pj4NCj4+Pj5UaGF0IGlzIGdvaW5nIHRvIGJl IHZlcnkgaW50ZXJlc3RpbmcgaW5kZWVkLiBDb25zaWRlcmluZyB0aGF0IG51bWJlcg0KPj4+Pm9m IGN1c3RvbWVycyBoYXZlIHBhaWQgdmVuZG9ycyBtaWxsaW9ucyBmb3IgY3VzdG9taXplZCBleHRl bnNpb25zIGFuZA0KPj4+Pm9ubHkgc29tZSBvZiB0aGVtIG1hZGUgaXQgdG8gSUVURiBkcmFmdHMv cmZjcy4NCj4+Pj4NCj4+Pj5TbyB3aGF0IHdpbGwgbW9zdCBsaWtlbHkgaGFwcGVuIGlzIGdlbmVy YWwgWUFORyBtb2RlbCBvZiBub3QgbXVjaCB1c2UNCj4+Pj5hbmQgem9vIG9mIHByb3ByaWV0YXJ5 IHZlbmRvciBZQU5HIGV4dGVuc2lvbnMgbm90IGNvbXBhdGlibGUgYmV0d2Vlbg0KPj4+PmltcGxl bWVudGF0aW9ucy4NCj4+Pj4NCj4+Pj5JcyB0aGlzIHJlYWxseSB3aGVyZSB3ZSB3YW50IHRvIGdv IHdpdGggdGhpcyBlbnRpcmUgZWZmb3J0ID8NCj4+Pj4NCj4+Pj5CZXN0LA0KPj4+PnIuDQo+Pj4+ DQo+Pj4+DQo+Pj4+T24gRnJpLCBEZWMgMTksIDIwMTQgYXQgMTE6MDMgQU0sICA8c3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb20+DQo+Pj4+d3JvdGU6DQo+Pj4+PiBIaSwNCj4+Pj4+DQo+Pj4+ PiBJIHRoaW5rIHdvcmtpbmcgb2YgQkdQIFlBTkcgaXMgYSBnb29kIG9wcG9ydHVuaXR5IHRvIHN0 YXJ0IHdvcmtpbmcNCj4+Pj4+b24gcG9saWN5IGZyYW1ld29yay4NCj4+Pj4+IFdvcmsgb24gcHJv dG9jb2xzIFlBTkcgaXMgYWxyZWFkeSBoYXJkIGR1ZSB0byB2ZW5kb3IgY29uZmlnDQo+Pj4+PmRp c3ByZWNhbmNpZXMsIEkgZXhwZWN0IHBvbGljeSB3b3JrIHRvIGJlIG11Y2ggaGFyZGVyIC4uLg0K Pj4+Pj4NCj4+Pj4+IEJ1dCBJIHRoaW5rLCB0aGVyZSBpcyBhbiBvcHBvcnR1bml0eSB0byBzdGFy dCBzb21ldGhpbmcgbmV3IGZvcg0KPj4+Pj5ldmVyeW9uZSAodGhhdCBtYXkgY29leGlzdCB3aXRo IGV4aXN0aW5nIENMSSBwb2xpY2llcykgYW5kIG5vdA0KPj4+Pj5sb29raW5nIGF0IENMSSB0cmFu c2xhdGlvbiAoaXQgd2lsbCBiZSBpbXBvc3NpYmxlIHdpdGggcG9saWNpZXMpLg0KPj4+Pj5UaGVu IGl0IHdvdWxkIGJlIHVwIHRvIHNlcnZpY2UgcHJvdmlkZXJzIHRvIHJlcXVlc3QgdGhlIHN1cHBv cnQgb2YNCj4+Pj4+dGhpcyBieSB0aGVpciBmYXZvcml0ZSB2ZW5kb3JzLg0KPj4+Pj4NCj4+Pj4+ IEJlc3QgUmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBTdGVwaGFuZQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogcnJhc3p1a0BnbWFpbC5j b20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mDQo+Pj4+PiBSb2JlcnQg UmFzenVrDQo+Pj4+PiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE3LCAyMDE0IDIzOjI4DQo+ Pj4+PiBUbzogSmVmZiBUYW50c3VyYQ0KPj4+Pj4gQ2M6IEFjZWUgTGluZGVtIChhY2VlKTsgRGVh biBCb2dkYW5vdmljOyBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsNCj4+Pj4+IExJVEtPV1NLSSBT dGVwaGFuZSBTQ0UvSUJORjsgTGFkaXNsYXYgTGhvdGthDQo+Pj4+PiBTdWJqZWN0OiBSZTogW1J0 Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0ZXJzDQo+Pj4+Pg0KPj4+Pj4gU28g YXJlIHlvdSBzYXlpbmcgdGhhdCBmb3JtYWwgWUFORyBzcGVjaWZpY2F0aW9uIHNheSBmb3IgQkdQ IGJ5DQo+Pj4+PmRlc2lnbiB3aWxsIG5vdCBiZSBjb21wYXRpYmxlIHdpdGggc29tZSBpbXBsZW1l bnRhdGlvbnMgPw0KPj4+Pj4NCj4+Pj4+IE9yIGFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9ybWFsIGRl c2lnbiBzYXkgb2YgQkdQIHByb3RvY29sIHdpbGwgaGF2ZQ0KPj4+Pj50byB3YWl0IGZldyB5ZWFy cyB0aWxsIFlBTkcgZm9yIHBvbGljeSBzcGVjIGlzIGNvbXBsZXRlID8NCj4+Pj4+DQo+Pj4+PiBD aGVlcnMsDQo+Pj4+PiByLg0KPj4+Pj4NCj4+Pj4+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDEx OjE0IFBNLCBKZWZmIFRhbnRzdXJhDQo+Pj4+PjxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbT4g d3JvdGU6DQo+Pj4+Pj4gWWVzLCBleGFjdGx5LCBSb2JlcnQgLSB0aGUgYmVoYXZpb3IgeW91IGhh dmUgZGVzY3JpYmVkIGlzIGFuDQo+Pj4+Pj5pbXBsZW1lbnRhdGlvbiwgbm90IGEgZm9ybWFsIHNw ZWNpZmljYXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+IEplZmYNCj4+Pj4+ Pg0KPj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDI6MTIgUE0sIEFjZWUgTGluZGVtIChhY2Vl KSA8YWNlZUBjaXNjby5jb20+DQo+Pj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFdoeSBp cyB0aGlzIGEgcHJvYmxlbSBpZiB0aGUgZGVmYXVsdCBpcyB0byBub3QgdG8gcmVkaXN0cmlidXRl DQo+Pj4+Pj4+cm91dGVzIGJldHdlZW4gUklCcz8gTm90ZSB0aGF0IGl0IGlzbsK5dCBsaWtlIHdl IGhhdmUgYSBzZXQgb2YNCj4+Pj4+Pj5hcHByb3ZlZCByb3V0aW5nIHByb3RvY29sIG1vZGVscyB0 aGF0IGFyZSBkZXBlbmRlbnQgb24gdGhpcw0KPj4+Pj4+PmJlaGF2aW9yLg0KPj4+Pj4+PiBBY2Vl DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDU6MDcgUE0sIERlYW4gQm9n ZGFub3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ+DQo+Pj4+Pj4+Pndyb3RlOg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IFJvYmVydCwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBZb3VyIHByb3Bvc2FsIGlzIHZlcnkg c2Vuc2libGUgYW5kIEkgdGhpbmsgdGhpcyBpcyB0aGUgYmVzdA0KPj4+Pj4+Pj4gb3B0aW9uDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRGVhbg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiBEZWMgMTcsIDIw MTQsIGF0IDQ6NDkgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KPj4+Pj4+ Pj4+d3JvdGU6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBEZWFuLCBhbGwNCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+IFRoZSB3YXkgSSByZWFkIGl0IGN1cnJlbnRseSBpbiBzZWN0aW9uIDUuNSB0aGVyZSBh cmUgb25seSB0d28NCj4+Pj4+Pj4+PnJvdXRlIGZpbHRlcnMgcHJvcG9zZWQgKGRlbnktYWxsIG9y IGFsbG93LWFsbCkuIEFzIHdlIGtub3cgc29tZQ0KPj4+Pj4+Pj4+cm91dGluZyBwcm90b2NvbHMg cmVxdWlyZSBleHBsaWNpdCBwZXJtaXNzaW9uIHRvIG9wZXJhdGUgKGV4YW1wbGU6DQo+Pj4+Pj4+ Pj5FQkdQKS4NCj4+Pj4+Pj4+PiBJZiB3ZSByZW1vdmUgZXZlbiB0aG9zZSB0d28gcHJpbWl0aXZl IGZpbHRlcnMgdGhlcmUgY2FuIGJlDQo+Pj4+Pj4+Pj5pbXBhY3QgIHRvIG90aGVyIGNvbXBvbmVu dHMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBCdXQgSSBkbyBzdXBwb3J0IGEgc2VwYXJhdGUgd29y ayBmb3IgWUFORyBtb2RlbCBmb3IgcG9saWN5LiBJDQo+Pj4+Pj4+Pj4gZG8gZXhwZWN0IHRoaXMg dG8gYmUgYSB2ZXJ5IGludGVyZXN0aW5nIGFuZCBpbnZvbHZlZCB3b3JrDQo+Pj4+Pj4+Pj4gY29u c2lkZXJpbmcgc2lnbmlmaWNhbnQgZGl2ZXJzaXR5IG9mIHBvbGljeSBsYW5ndWFnZXMgYWNyb3Nz DQo+Pj4+Pj4+Pj4gYWxsIGltcGxlbWVudGF0aW9ucyB0b2RheS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+IE9uY2UgdGhhdCB3b3JrIGlzIGRvbmUgd2UgY291bGQgcmV0aXJlIHNlY3Rpb24gNS41IG9m DQo+Pj4+Pj4+Pj4gKi1uZXRtb2Qtcm91dGluZy0qDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+Pj4+IHIuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbiBX ZWQsIERlYyAxNywgMjAxNCBhdCAxMDowOSBQTSwgRGVhbiBCb2dkYW5vdmljDQo+Pj4+Pj4+Pj4+ PGRlYW5iQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+Pj4+Pj4+Pj4gSSdtIGluIHN1cHBvcnQgb2Yg cmVtb3Zpbmcgcm91dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0aW5nIGNmZw0KPj4+Pj4+Pj4+Pm1v ZGVsLiBSb3V0ZSBmaWx0ZXJzIHNob3VsZCBiZSBJTU8gcGFydCBvZiB0aGUgcG9saWN5IG1vZGVs LCBpbg0KPj4+Pj4+Pj4+PndoaWNoIGFsc28gQUNMIG1vZGVsIGJlbG9uZ3MgdG9vLiBBY3R1YWxs eSwgSSB3b3VsZCBhcmd1ZSB0aGF0DQo+Pj4+Pj4+Pj4+dGhlIGN1cnJlbnQgQUNMIG1vZGVsIGlz IHZlcnkgc3VpdGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ IERlYW4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQo+ Pj4+Pj4+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KPj4+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+IF8gX18gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pg0KPj4+Pj4gQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+Pj4+PmNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+ Pj4+PmRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdQ0KPj4+Pj5jZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlDQo+Pj4+PmRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzDQo+Pj4+PmV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlDQo+Pj4+PnNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4NCj4+Pj4+DQo+Pj4+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+Pj4+cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4+Pj4+YmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+Pj4+IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlcg0KPj4+Pj5hbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz Lg0KPj4+Pj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdA0KPj4+Pj5oYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPj4+Pj4gVGhhbmsgeW91Lg0KPj4+Pj4NCj4+Pj4NCj4+Pj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj5fDQo+Pj4+X19fDQo+Pj4+Xw0KPj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+DQo+Pj4+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+Pj4+Y29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMs DQo+Pj4+ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZQ0KPj4+PnBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpDQo+Pj4+cXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+Pj4+ ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlDQo+Pj4+YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4+ Pj4NCj4+Pj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3INCj4+Pj5wcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdA0KPj4+PmJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+Pj4+SWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+Pj4+YW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+Pj5BcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUN Cj4+Pj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+Pj5UaGFuayB5b3Uu DQo+Pj4+DQo+Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj5SdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+Pj5SdGcteWFuZy1jb29yZEBp ZXRmLm9yZw0KPj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlh bmctY29vcmQNCj4+Pj4NCj4+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj5fDQo+Pj4+X19fDQo+Pj4+Xw0K Pj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ DQo+Pj4+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zDQo+Pj4+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+Pj4+ZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPj4+PnBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpDQo+Pj4+cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+Pj4+ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+Pj4+YWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4+Pj4NCj4+Pj5UaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+Pj5wcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxk IG5vdA0KPj4+PmJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uDQo+Pj4+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+Pj4+YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4NCj4+Pj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4+Pj5iZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4NCj4+Pj5UaGFuayB5b3UuDQo+Pj4+DQo+Pj4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gUnRnLXlhbmct Y29vcmQgbWFpbGluZyBsaXN0DQo+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFJ0Zy15YW5nLWNv b3JkIG1haWxpbmcgbGlzdA0KPj4gUnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlJ0Zy15YW5nLWNvb3Jk IG1haWxpbmcgbGlzdA0KPlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+UnRnLXlhbmctY29vcmQgbWFpbGluZyBs aXN0DQo+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQoNCg== From nobody Fri Dec 26 22:42:18 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EAA1A212A for ; Fri, 26 Dec 2014 22:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-48_TRtJPbt for ; Fri, 26 Dec 2014 22:42:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE27F1A1EFD for ; Fri, 26 Dec 2014 22:42:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQN06734; Sat, 27 Dec 2014 06:42:09 +0000 (GMT) Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 27 Dec 2014 06:42:07 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.207]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.03.0158.001; Sat, 27 Dec 2014 14:41:57 +0800 From: wangzitao To: "Acee Lindem (acee)" , Robert Raszuk Thread-Topic: [Rtg-yang-coord] issue :R01: route filters Thread-Index: AQHQCLFsPsK01GVgzkOaWRN9dfYCGJySQZdAgAEaoICAAP0HAIAAC1uAgAAE9YCAAAFRAIAAALAAgAADzICAAmRx4P//8gEAgAAqRBCAAAUpwP//wG0AgABaZACACUeAB4AA/hvggAC/aoCAARlzAA== Date: Sat, 27 Dec 2014 06:41:57 +0000 Message-ID: References: <30031_1418732022_549021F6_30031_4698_1_9E32478DFA9976438E7A22F69B08FF920C746B3C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <52A4FA47-CC15-47A3-AB4F-B0DA79C79EF1@juniper.net> <1B04CCB0-B876-4CBC-B716-AA3583346A59@ericsson.com> <10354_1418983432_5493F808_10354_499_1_9E32478DFA9976438E7A22F69B08FF920C748CFF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <15106_1418990320_549412F0_15106_3325_1_9E32478DFA9976438E7A22F69B08FF920C748E85@OPEXCLILM34.corporate.adroot.infra.ftgroup> <14898_1418990448_54941370_14898_273_2_020b2faf-26b0-4cf7-bbe3-3042da8e84d6@OPEXCLILH01.corporate.adroot.infra.ftgroup> 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.138.41.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/ksbgBrS2yD0FWYxlscAjX5cgi3k Cc: "rtg-yang-coord@ietf.org" Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 06:42:16 -0000 SGkgQWNlZSwNCg0KSSB0aG91Z2h0IGJucCBpbmZvIG1vZGVsIGRyYWZ0IGhhcyBhbHJlYWR5IGxv b2tlZCBhdCBoaWdoIGxldmVsIFlBTkcgZGVmaW5pdGlvbiwgbWF5YmUgSSBhbSB3cm9uZywgYnV0 IEkgYWdyZWUgd2l0aCB5b3Ugd2Ugc2hvdWxkIGxpc3RlbiB0byBwcm92aWRlcidzIHZpZXcuDQoN CkJSDQotTWljaGFlbA0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBBY2VlIExp bmRlbSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTTl ubQxMuaciDI35pelIDU6NTMNCuaUtuS7tuS6ujogd2FuZ3ppdGFvOyBSb2JlcnQgUmFzenVrDQrm ioTpgIE6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQrkuLvpopg6IFJlOiBbUnRnLXlhbmctY29v cmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCg0KSGkgTWljaGFlbCwgDQoNCkkgdGhpbmsg aXQgd291bGQgYmUgZ3JlYXQgZm9yIHRoZSBwcm92aWRlcnMgdG8gZ2l2ZSB1cyB0aGVpciB2aWV3 IG9uIGhvdyByb3V0aW5nIHBvbGljeSBzaG91bGQgYmUgbW9kZWxlZCBiZWZvcmUgYW55b25lIGdv ZXMgZG93biB0byB0aGUgbG93IGxldmVsIFlBTkcgZGVmaW5pdGlvbnMuIEkgd2lsbCByZXZpZXcg dGhlIGluZm8gbW9kZWwgaW4gdGhlIHJlZmVyZW5jZWQgZHJhZnQgYXMgd2VsbC4gDQoNClRoYW5r cywNCkFjZWUgDQoNCk9uIDEyLzI1LzE0LCA5OjM0IFBNLCAid2FuZ3ppdGFvIiA8d2FuZ3ppdGFv QGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SGksIFJvYmVydDoNCj5XaGF0IGFib3V0IHRoZSBiYXNp YyBuZXR3b3JrIHBvbGljeSBkcmFmdCBpbiBJMlJTPw0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1oYXJlcy1pMnJzLWJucC1pbmZvLW1vZGVsLTAxDQo+dGhlIGJhc2ljIG5ldHdv cmsgcG9saWN5IG1vZGVsIHByb3Bvc2VkIGluIHRoZSBhYm92ZSBkcmFmdCBpcyB1c2VkIGFzIA0K PnRoZSBiYXNpcyB0byBidWlsZCBQQlIgbW9kZWwsIEkgYmVsaWV2ZSBpdCBhbHNvIGNhbiBiZSBh cHBsaWVkIHRvIA0KPmNvbnRyb2wgcGxhbmUgcG9saWN5IG1vZGVsLg0KPlNlY3Rpb24gNSBvZiB0 aGlzIGRyYWZ0IGdpdmVzIGEgQkdQIHBvbGljeSBleGFtcGxlLg0KPg0KPkJSDQo+LU1pY2hhZWwN Cj4tLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+5Y+R5Lu25Lq6OiBSdGcteWFuZy1jb29yZCBbbWFp bHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBSb2JlcnQgDQo+UmFz enVrDQo+5Y+R6YCB5pe26Ze0OiAyMDE05bm0MTLmnIgyNeaXpSAxOToxOA0KPuaUtuS7tuS6ujog UWluIFd1DQo+5oqE6YCBOiBydGcteWFuZy1jb29yZEBpZXRmLm9yZzsgc3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb207IERlYW4gDQo+Qm9nZGFub3ZpYzsgSmVmZiBUYW50c3VyYTsgTGFkaXNs YXYgTGhvdGthOyBEYXZpZCBTaW5pY3JvcGU7IEFjZWUgDQo+TGluZGVtDQo+KGFjZWUpDQo+5Li7 6aKYOiBSZTogW1J0Zy15YW5nLWNvb3JkXSBpc3N1ZSA6UjAxOiByb3V0ZSBmaWx0ZXJzDQo+DQo+ UWluLA0KPg0KPmRyYWZ0LWF0bGFzLWkycnMtcG9saWN5LWZyYW1ld29yay0wMCBjYW4gYmUgaGVs cGZ1bCB0byB0aGlzIHdvcmsuDQo+DQo+VGhlIG90aGVyIHR3byBkcmFmdHMgb24gUEJSIGFyZSBx dWl0ZSBpcnJlbGV2YW50LiBXZSBhcmUgbm90IHRhbGtpbmcgDQo+YWJvdXQgUEJSIGhlcmUgYXQg YWxsLiBJdCBpcyBqdXN0IG9uZSBzcGVjaWZpYyBhcHBsaWNhdGlvbiBvZiBkYXRhIA0KPnBsYW5l IHBvbGljeS4NCj4NCj5PdXIgZWZmb3J0IGZpcnN0IGlzIHRvIGRlZmluZSBZQU5HIG1vZGVsIGZv ciBjb250cm9sIHBsYW5lIHBvbGljeS4NCj4NCj5CZXN0LA0KPnIuDQo+DQo+DQo+DQo+DQo+DQo+ DQo+DQo+DQo+T24gVGh1LCBEZWMgMjUsIDIwMTQgYXQgMTI6MTIgUE0sIFFpbiBXdSA8YmlsbC53 dUBodWF3ZWkuY29tPiB3cm90ZToNCj4+IEplZmY6DQo+PiBJc24ndCB0aGlzIHRvcGljIHN1YnN1 bWVkIGludG8gSTJSUz8NCj4+IFdoYXQgYW0gSSBtaXNzaW5nPw0KPj4NCj4+IFJlZ2FyZHMhDQo+ PiAtUWluDQo+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+PiDlj5Hku7bkuro6IFJ0Zy15YW5n LWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEpl ZmYgDQo+PiBUYW50c3VyYQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0MTLmnIgyMOaXpSA1OjM2 DQo+PiDmlLbku7bkuro6IEFjZWUgTGluZGVtIChhY2VlKTsgc3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb207IFJvYmVydCBSYXN6dWsNCj4+IOaKhOmAgTogcnRnLXlhbmctY29vcmRAaWV0Zi5v cmc7IERlYW4gQm9nZGFub3ZpYzsgTGFkaXNsYXYgTGhvdGthDQo+PiDkuLvpopg6IFJlOiBbUnRn LXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4+DQo+PiBJ4oCZZCBsaWtl IHRvIGJlIGludm9sdmVkLCBhcyB3ZWxsIGFzIGdpdmluZyBpdCBhIGhvbWUgaW4gcnRnd2cNCj4+ DQo+PiBDaGVlcnMsDQo+PiBKZWZmDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+DQo+Pj4NCj4+Pk9uIDEyLzE5LzE0LCA3OjAwIEFNLCAic3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb20iDQo+Pj48c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+ IHdyb3RlOg0KPj4+DQo+Pj4+QW5kIHF1ZXN0aW9uIDogV2hvIGlzIGludGVyZXN0ZWQgdG8gc3Rh cnQgbm93IHRoZSB3b3JrIG9uIHN0YW5kYXJkIA0KPj4+PnJvdXRpbmcgcG9saWN5ID8NCj4+Pj4N Cj4+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PkZyb206IFJ0Zy15YW5n LWNvb3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+Pj4+ QmVoYWxmIE9mIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tDQo+Pj4+U2VudDogRnJpZGF5 LCBEZWNlbWJlciAxOSwgMjAxNCAxMjo1OQ0KPj4+PlRvOiBSb2JlcnQgUmFzenVrDQo+Pj4+Q2M6 IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFu b3ZpYzsgDQo+Pj4+SmVmZiBUYW50c3VyYTsgTGFkaXNsYXYgTGhvdGthDQo+Pj4+U3ViamVjdDog UmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVycw0KPj4+Pg0KPj4+ PlJvYmVydCwNCj4+Pj4NCj4+Pj5Zb3UgYXJlIHRvdWNoaW5nIGFuIGludGVyZXN0aW5nIHBvaW50 IDopIEluIGZhY3QgdGhlcmUgYXJlIHR3byB3YXlzIA0KPj4+Pm9mIHZpZXdpbmcgdGhpbmtzIDoN Cj4+Pj4tIHNlcnZpY2UgcHJvdmlkZXJzL2N1c3RvbWVycyB3aG8gd291bGQgbGlrZSB0byB1c2Ug b25seSBzdGFuZGFyZCANCj4+Pj5tb2RlbHMgdG8gZmFjaWxpdGF0ZSBuZXR3b3JrIHByb3Zpc2lv biAmIG9wZXJhdGlvbg0KPj4+Pi0gdmVuZG9ycyB3aG8gbWF5IG5vdCB3YW50IHRvIG1ha2UgZGV2 ZWxvcG1lbnQgdG8gaW1wbGVtZW50IG5ldyANCj4+Pj5mZWF0dXJlcyB0byBiZSBjb21wbGlhbnQg d2l0aCBhIHN0YW5kYXJkIHlhbmcgbW9kZWwgIChhcyBkZXYgY29zdCANCj4+Pj5tb25leSkuIEFz IHlvdSBtZW50aW9uZWQsIG9wZXJhdGlvbiBvZiBib3hlcyBpcyB0b2RheSBhIGtleSANCj4+Pj5k aWZmZXJlbnRpYXRvciB3aGVuIGNob29zaW5nIGEgdmVuZG9yLg0KPj4+PldlIGNsZWFybHkgdGhp cyBkaXZlcmdlbmNlIHRvZGF5IGluIHByb2R1Y2VkIFlhbmcgbW9kZWwgKG9wZXJhdG9yIA0KPj4+ PmF1dGhvcnMgbW9kZWxzIHZzIHZlbmRvciBhdXRob3JzIG1vZGVsKQ0KPj4+Pg0KPj4+PkFzIGEg c2VydmljZSBwcm92aWRlciwgSSdtIGNsZWFybHkgcHVzaGluZyB0byB1c2Ugb25seSBzdGFuZGFy ZCANCj4+Pj5tb2RlbCBhdCBsZWFzdCBmb3IgbW9zdCBvZiB0aGUgYmFzZSBzdHJ1Y3R1cmUgb2Yg c2VydmljZXMgYW5kIEkgd2lsbCANCj4+Pj5wdXNoIG15IHZlbmRvcnMgdG8gc3VwcG9ydCBpdCBh cyBtb3JlIGFzIHBvc3NpYmxlLiBJIHdvdWxkIHNheSB0aGF0IA0KPj4+Pm1vcmUgdGhhbiA5MCUg b2YgcGFyYW1ldGVycyBvZiBhIHNlcnZpY2UgYXJlIGNvbW1vbiB0byBhbGwgDQo+Pj4+aW1wbGVt ZW50YXRpb25zIChqdXN0IGRldGFpbHMgYXJlIGNoYW5naW5nICA6IGxvY2FsaXphdGlvbiBvZiB0 aGUgDQo+Pj4+Y29uZmlnIHN0YXRlbWVudCBvciBncmFudWxhcml0eSBvZiB0aGUgcGFyYW1ldGVy KS4gU28gSSB0aGluayB0aGF0IA0KPj4+PmNyZWF0aW5nIHVzYWJsZSBzdGFuZGFyZCBtb2RlbCBj YW4gd29yay4gVGhlIHJlbWFpbmluZyB4JSBjYW4gYmUgDQo+Pj4+YWRkcmVzc2VkIGJ5IHZlbmRv ciBleHRlbnNpb25zLg0KPj4+Pg0KPj4+PkNvbWluZyBiYWNrIHRvIHJvdXRpbmcgcG9saWNpZXMu IEkgZG8gdGhpbmsgdGhhdCByZXN0YXJ0aW5nIGEgbmV3IA0KPj4+PmZyYW1ld29yayBmcm9tIHN0 cmF0Y2ggaXMgdGhlIHJpZ2h0IHdheSB0byBkbyBpdC4gQW5kIGFzIGFueSANCj4+Pj5wcm90b2Nv bCBleHRlbnNpb24gb3IgZmVhdHVyZSBzdGFuZGFyZGl6ZWQgaW4gSUVURiwgaXQgd2lsbCBiZSB1 cCB0byANCj4+Pj5jdXN0b21lcnMgdG8gcmVxdWVzdCB0aGVpciB2ZW5kb3JzIGZvciBpbXBsZW1l bnRhdGlvbnMuDQo+Pj4+DQo+Pj4+VG9kYXkgcm91dGluZyBwb2xpY3kgbWFuYWdlbWVudCBiZXR3 ZWVuIGRpZmZlcmVudCB2ZW5kb3JzIGlzIGNyYXp5Lg0KPj4+PkNvbnNpZGVyIHlvdSBoYXZlIGEg VmVuZG9yIFggbmV0d29yayB3aXRoIHdpZGVseSBkZXBsb3llZCBjb21wbGV4IA0KPj4+PnJvdXRp bmcgcG9saWNpZXMsIGFuZCB5b3Ugd2FudCB0byBpbnRyb2R1Y2UgdG8gdmVuZG9yIFksIHRyYW5z bGF0aW9uIA0KPj4+Pm9mIHJvdXRpbmcgcG9saWNpZXMgZnJvbSBsYW5ndWFnZSBYIHRvIFkgaXMg YSB2ZXJ5IGNvbXBsZXggd29yay4NCj4+Pj4NCj4+Pj5Nb3Jlb3ZlciB3ZSBjYW4gc2VlIHRoYXQg ZnJhbWV3b3JrIG9mIHBvbGljeSBtb2RlbCBpcyBhbHJlYWR5IA0KPj4+PmV4aXN0aW5nIGZvciBp bnRlcm5ldCByZWdpc3RyaWVzIHVzaW5nIFJQU0wuDQo+Pj4+DQo+Pj4+SSBkbyBub3Qga25vdyB0 b2RheSB3aGVyZSB0aGlzIFlhbmcgaW5pdGlhdGl2ZSB3aWxsIGdvIC4uLiBidXQgSSANCj4+Pj53 aWxsIHByb25lIGEgY29uc2Vuc3VzIG9uIHN0cm9uZyBhZG9wdGlvbiBvZiBzdGFuZGFyZCBZQU5H IG1vZGVscyANCj4+Pj5yYXRoZXIgdGhhbiB2ZW5kb3Igc3BlY2lmaWMgb25seS4NCj4+Pj4NCj4+ Pj4NCj4+Pj5TdGVwaGFuZQ0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+RnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFz enVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIA0KPj4+PlJvYmVydCBSYXN6dWsNCj4+Pj5TZW50 OiBGcmlkYXksIERlY2VtYmVyIDE5LCAyMDE0IDExOjEwDQo+Pj4+VG86IExJVEtPV1NLSSBTdGVw aGFuZSBTQ0UvSUJORg0KPj4+PkNjOiBKZWZmIFRhbnRzdXJhOyBBY2VlIExpbmRlbSAoYWNlZSk7 IERlYW4gQm9nZGFub3ZpYzsgDQo+Pj4+cnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IExhZGlzbGF2 IExob3RrYQ0KPj4+PlN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJv dXRlIGZpbHRlcnMNCj4+Pj4NCj4+Pj5IaSBTdGVwaGFuZSwNCj4+Pj4NCj4+Pj5UaGF0IGlzIGdv aW5nIHRvIGJlIHZlcnkgaW50ZXJlc3RpbmcgaW5kZWVkLiBDb25zaWRlcmluZyB0aGF0IG51bWJl ciANCj4+Pj5vZiBjdXN0b21lcnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWlsbGlvbnMgZm9yIGN1c3Rv bWl6ZWQgZXh0ZW5zaW9ucyANCj4+Pj5hbmQgb25seSBzb21lIG9mIHRoZW0gbWFkZSBpdCB0byBJ RVRGIGRyYWZ0cy9yZmNzLg0KPj4+Pg0KPj4+PlNvIHdoYXQgd2lsbCBtb3N0IGxpa2VseSBoYXBw ZW4gaXMgZ2VuZXJhbCBZQU5HIG1vZGVsIG9mIG5vdCBtdWNoIA0KPj4+PnVzZSBhbmQgem9vIG9m IHByb3ByaWV0YXJ5IHZlbmRvciBZQU5HIGV4dGVuc2lvbnMgbm90IGNvbXBhdGlibGUgDQo+Pj4+ YmV0d2VlbiBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4+DQo+Pj4+SXMgdGhpcyByZWFsbHkgd2hlcmUg d2Ugd2FudCB0byBnbyB3aXRoIHRoaXMgZW50aXJlIGVmZm9ydCA/DQo+Pj4+DQo+Pj4+QmVzdCwN Cj4+Pj5yLg0KPj4+Pg0KPj4+Pg0KPj4+Pk9uIEZyaSwgRGVjIDE5LCAyMDE0IGF0IDExOjAzIEFN LCAgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPg0KPj4+Pndyb3RlOg0KPj4+Pj4gSGks DQo+Pj4+Pg0KPj4+Pj4gSSB0aGluayB3b3JraW5nIG9mIEJHUCBZQU5HIGlzIGEgZ29vZCBvcHBv cnR1bml0eSB0byBzdGFydCB3b3JraW5nIA0KPj4+Pj5vbiBwb2xpY3kgZnJhbWV3b3JrLg0KPj4+ Pj4gV29yayBvbiBwcm90b2NvbHMgWUFORyBpcyBhbHJlYWR5IGhhcmQgZHVlIHRvIHZlbmRvciBj b25maWcgDQo+Pj4+PmRpc3ByZWNhbmNpZXMsIEkgZXhwZWN0IHBvbGljeSB3b3JrIHRvIGJlIG11 Y2ggaGFyZGVyIC4uLg0KPj4+Pj4NCj4+Pj4+IEJ1dCBJIHRoaW5rLCB0aGVyZSBpcyBhbiBvcHBv cnR1bml0eSB0byBzdGFydCBzb21ldGhpbmcgbmV3IGZvciANCj4+Pj4+ZXZlcnlvbmUgKHRoYXQg bWF5IGNvZXhpc3Qgd2l0aCBleGlzdGluZyBDTEkgcG9saWNpZXMpIGFuZCBub3QgDQo+Pj4+Pmxv b2tpbmcgYXQgQ0xJIHRyYW5zbGF0aW9uIChpdCB3aWxsIGJlIGltcG9zc2libGUgd2l0aCBwb2xp Y2llcykuDQo+Pj4+PlRoZW4gaXQgd291bGQgYmUgdXAgdG8gc2VydmljZSBwcm92aWRlcnMgdG8g cmVxdWVzdCB0aGUgc3VwcG9ydCBvZiANCj4+Pj4+dGhpcyBieSB0aGVpciBmYXZvcml0ZSB2ZW5k b3JzLg0KPj4+Pj4NCj4+Pj4+IEJlc3QgUmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBTdGVwaGFuZQ0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJv bTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxm IE9mIA0KPj4+Pj4gUm9iZXJ0IFJhc3p1aw0KPj4+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJl ciAxNywgMjAxNCAyMzoyOA0KPj4+Pj4gVG86IEplZmYgVGFudHN1cmENCj4+Pj4+IENjOiBBY2Vl IExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgcnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7 IA0KPj4+Pj4gTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBMYWRpc2xhdiBMaG90a2ENCj4+ Pj4+IFN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRl cnMNCj4+Pj4+DQo+Pj4+PiBTbyBhcmUgeW91IHNheWluZyB0aGF0IGZvcm1hbCBZQU5HIHNwZWNp ZmljYXRpb24gc2F5IGZvciBCR1AgYnkgDQo+Pj4+PmRlc2lnbiB3aWxsIG5vdCBiZSBjb21wYXRp YmxlIHdpdGggc29tZSBpbXBsZW1lbnRhdGlvbnMgPw0KPj4+Pj4NCj4+Pj4+IE9yIGFyZSB5b3Ug c2F5aW5nIHRoYXQgZm9ybWFsIGRlc2lnbiBzYXkgb2YgQkdQIHByb3RvY29sIHdpbGwgaGF2ZSAN Cj4+Pj4+dG8gd2FpdCBmZXcgeWVhcnMgdGlsbCBZQU5HIGZvciBwb2xpY3kgc3BlYyBpcyBjb21w bGV0ZSA/DQo+Pj4+Pg0KPj4+Pj4gQ2hlZXJzLA0KPj4+Pj4gci4NCj4+Pj4+DQo+Pj4+PiBPbiBX ZWQsIERlYyAxNywgMjAxNCBhdCAxMToxNCBQTSwgSmVmZiBUYW50c3VyYSANCj4+Pj4+PGplZmYu dGFudHN1cmFAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4+PiBZZXMsIGV4YWN0bHksIFJvYmVy dCAtIHRoZSBiZWhhdmlvciB5b3UgaGF2ZSBkZXNjcmliZWQgaXMgYW4gDQo+Pj4+Pj5pbXBsZW1l bnRhdGlvbiwgbm90IGEgZm9ybWFsIHNwZWNpZmljYXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+IEplZmYNCj4+Pj4+Pg0KPj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDI6 MTIgUE0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQo+Pj4+Pj4+d3JvdGU6 DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFdoeSBpcyB0aGlzIGEgcHJvYmxlbSBpZiB0aGUgZGVmYXVsdCBp cyB0byBub3QgdG8gcmVkaXN0cmlidXRlIA0KPj4+Pj4+PnJvdXRlcyBiZXR3ZWVuIFJJQnM/IE5v dGUgdGhhdCBpdCBpc27CuXQgbGlrZSB3ZSBoYXZlIGEgc2V0IG9mIA0KPj4+Pj4+PmFwcHJvdmVk IHJvdXRpbmcgcHJvdG9jb2wgbW9kZWxzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiB0aGlzIA0KPj4+ Pj4+PmJlaGF2aW9yLg0KPj4+Pj4+PiBBY2VlDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiBEZWMgMTcs IDIwMTQsIGF0IDU6MDcgUE0sIERlYW4gQm9nZGFub3ZpYyANCj4+Pj4+Pj4+PGRlYW5iQGp1bmlw ZXIubmV0Pg0KPj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSb2JlcnQsDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gWW91ciBwcm9wb3NhbCBpcyB2ZXJ5IHNlbnNpYmxlIGFuZCBJIHRoaW5r IHRoaXMgaXMgdGhlIGJlc3QgDQo+Pj4+Pj4+PiBvcHRpb24NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBE ZWFuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNDo0OSBQTSwgUm9i ZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQo+Pj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IERlYW4sIGFsbA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhlIHdheSBJIHJl YWQgaXQgY3VycmVudGx5IGluIHNlY3Rpb24gNS41IHRoZXJlIGFyZSBvbmx5IHR3byANCj4+Pj4+ Pj4+PnJvdXRlIGZpbHRlcnMgcHJvcG9zZWQgKGRlbnktYWxsIG9yIGFsbG93LWFsbCkuIEFzIHdl IGtub3cgc29tZSANCj4+Pj4+Pj4+PnJvdXRpbmcgcHJvdG9jb2xzIHJlcXVpcmUgZXhwbGljaXQg cGVybWlzc2lvbiB0byBvcGVyYXRlIChleGFtcGxlOg0KPj4+Pj4+Pj4+RUJHUCkuDQo+Pj4+Pj4+ Pj4gSWYgd2UgcmVtb3ZlIGV2ZW4gdGhvc2UgdHdvIHByaW1pdGl2ZSBmaWx0ZXJzIHRoZXJlIGNh biBiZSANCj4+Pj4+Pj4+PmltcGFjdCAgdG8gb3RoZXIgY29tcG9uZW50cy4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IEJ1dCBJIGRvIHN1cHBvcnQgYSBzZXBhcmF0ZSB3b3JrIGZvciBZQU5HIG1vZGVs IGZvciBwb2xpY3kuIEkgDQo+Pj4+Pj4+Pj4gZG8gZXhwZWN0IHRoaXMgdG8gYmUgYSB2ZXJ5IGlu dGVyZXN0aW5nIGFuZCBpbnZvbHZlZCB3b3JrIA0KPj4+Pj4+Pj4+IGNvbnNpZGVyaW5nIHNpZ25p ZmljYW50IGRpdmVyc2l0eSBvZiBwb2xpY3kgbGFuZ3VhZ2VzIGFjcm9zcyANCj4+Pj4+Pj4+PiBh bGwgaW1wbGVtZW50YXRpb25zIHRvZGF5Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT25jZSB0aGF0 IHdvcmsgaXMgZG9uZSB3ZSBjb3VsZCByZXRpcmUgc2VjdGlvbiA1LjUgb2YNCj4+Pj4+Pj4+PiAq LW5ldG1vZC1yb3V0aW5nLSoNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+ Pj4gci4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9uIFdlZCwgRGVjIDE3LCAy MDE0IGF0IDEwOjA5IFBNLCBEZWFuIEJvZ2Rhbm92aWMgDQo+Pj4+Pj4+Pj4+PGRlYW5iQGp1bmlw ZXIubmV0PiB3cm90ZToNCj4+Pj4+Pj4+Pj4gSSdtIGluIHN1cHBvcnQgb2YgcmVtb3Zpbmcgcm91 dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0aW5nIGNmZyANCj4+Pj4+Pj4+Pj5tb2RlbC4gUm91dGUg ZmlsdGVycyBzaG91bGQgYmUgSU1PIHBhcnQgb2YgdGhlIHBvbGljeSBtb2RlbCwgDQo+Pj4+Pj4+ Pj4+aW4gd2hpY2ggYWxzbyBBQ0wgbW9kZWwgYmVsb25ncyB0b28uIEFjdHVhbGx5LCBJIHdvdWxk IGFyZ3VlIA0KPj4+Pj4+Pj4+PnRoYXQgdGhlIGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3Vp dGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IERlYW4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+Pj4gUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBS dGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KPj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4gXyBfIF9fIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4NCj4+Pj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCj4+Pj4+Y29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgDQo+Pj4+PmRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSANCj4+Pj4+Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl ciBhIGwnZXhwZWRpdGV1ciBldCBsZSANCj4+Pj4+ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgDQo+Pj4+PmV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIA0KPj4+Pj5yZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIA0KPj4+Pj5wcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIA0KPj4+Pj5ub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+Pj4+IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciANCj4+Pj4+YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4NCj4+Pj4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgDQo+Pj4+PmhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQo+Pj4+PiBUaGFuayB5b3UuDQo+Pj4+Pg0KPj4+Pg0KPj4+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+Xw0KPj4+Pl8NCj4+Pj5fX18NCj4+Pj5fDQo+Pj4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4NCj4+Pj5DZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQo+Pj4+Y29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUg DQo+Pj4+ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IA0KPj4+PmNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgDQo+Pj4+ZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgDQo+Pj4+ZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgDQo+Pj4+c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLg0KPj4+Pg0KPj4+PlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciANCj4+Pj5wcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCANCj4+Pj5iZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj4+PklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciANCj4+Pj5hbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K Pj4+PkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgDQo+Pj4+aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NCj4+Pj5UaGFuayB5b3UuDQo+Pj4+DQo+Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj5SdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+ Pj5SdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4+Pj4NCj4+Pj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pl8N Cj4+Pj5fDQo+Pj4+X19fDQo+Pj4+Xw0KPj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+DQo+Pj4+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0KPj4+PmNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIA0KPj4+PmRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSANCj4+Pj5jZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy IGEgbCdleHBlZGl0ZXVyIGV0IGxlIA0KPj4+PmRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIA0KPj4+PmV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIA0K Pj4+PnNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4NCj4+Pj4NCj4+Pj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgDQo+Pj4+cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgDQo+Pj4+YmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+Pj5JZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgDQo+ Pj4+YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+Pj5BcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IA0KPj4+PmhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+Pj4+ VGhhbmsgeW91Lg0KPj4+Pg0KPj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPj4g UnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+IFJ0 Zy15YW5nLWNvb3JkQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5SdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj5SdGcteWFu Zy1jb29yZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRnLXlhbmctY29vcmQNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPlJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPlJ0Zy15YW5nLWNvb3JkQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1j b29yZA0KDQo= From nobody Sat Dec 27 21:57:26 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F671ACEA6; Sat, 27 Dec 2014 21:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_jJg7tViUvU; Sat, 27 Dec 2014 21:57:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416221ACEA4; Sat, 27 Dec 2014 21:57:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNJ63004; Sun, 28 Dec 2014 05:57:21 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Dec 2014 05:57:18 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.3]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sun, 28 Dec 2014 13:57:14 +0800 From: Yangang To: "rtgwg@ietf.org" , "rtg-yang-coord@ietf.org" Thread-Topic: =?utf-8?B?QWJvdXQgbmV3IHJvdXRlLXBvbGljeSB5YW5nIG1vZGVsLi8vLy8v6L2s5Y+R?= =?utf-8?B?OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXlhbi1ydGd3?= =?utf-8?Q?g-routing-policy-yang-00.txt?= Thread-Index: AQHQIaR5ZOYENOzSHUGPHGLsoibGJJykfAsA Date: Sun, 28 Dec 2014 05:57:13 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/zrAqu52g4GHp4PWvuTst_8EIBE4 Subject: [Rtg-yang-coord] =?utf-8?q?About_new_route-policy_yang_model=2E//?= =?utf-8?q?///=E8=BD=AC=E5=8F=91=3A_New_Version_Notification_for_draft-yan?= =?utf-8?q?-rtgwg-routing-policy-yang-00=2Etxt?= X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 05:57:26 -0000 SGksIEFsbA0KDQogICBNeSBjb2xsZWFndWUgYW5kIG1lIGp1c3QgZmluaXNoIHRoZSBkcmFmdCBv ZiByb3V0ZS1wb2xpY3kgeWFuZyBtb2RlbCwgYW5kIHN1Ym1pdCBvbiBydGd3ZyB5ZXN0ZXJkYXku IElmIHlvdSBoYXZlIHRpbWUsIHBsZWFzZSByZXZpZXcgaXQgYW5kIHByb3ZpZGUgeW91ciBjb21t ZW50cy4NCg0KICAgUmlnaHQgbm93LCBhbG1vc3QgYWxsIHJvdXRpbmcgcHJvdG9jb2wncyB5YW5n IG1vZGVsIGFscmVhZHkgaXMgcHJvY2Vzc2luZywganVzdCBubyBwb2xpY3kgbW9kZWwsIHNvIHdl IHByZXBhcmUgaXQuIA0KDQogICBUaHJvdWdoIHdlIGtub3cgdGhlcmUgYXJlIG11Y2ggZGlmZmVy ZW50IGluIHJvdXRlLXBvbGljeSwgd2Ugc3RpbGwgcHJvdmlkZSB0aGUgbW9zdCBkZXRhaWwgdGhh dCB3ZSBjYW4gcHJvdmlkZSwgd2UgZG9uJ3QgYXNzdW1lIHdoYXQgaXMgdGhlIGJhc2ljIG1vZGVs IGFuZCB3aGF0IGlzIHRoZSBleHBhbnNpYmlsaXR5LiBXZSB0aGluayBtYXliZSB3ZSBjYW4gZ2F0 aGVyIGFsbCBkaWZmZXJlbmNlIGF0IGZpcnN0LCBhbmQgdGhlbiB3ZSBjYW4gZ2V0IGEgYWJzdHJh Y3QgbW9kZWwgdGhhdCBlYXN5IHRvIGV4cGFuZC4gTWF5YmUgaXQgY2FuIGltcHJvdmUgdGhlIHBy b2dyZXNzLg0KDQogICBGaW5hbGx5LCBzdGlsbCBhYm91dCB0aGUgcmV2aWV3IGNvbW1lbnRzLiBB bGwgb2YgeW91ciBjb21tZW50cyB3aWxsIGJlIHdlbGNvbWUgYWx3YXlzLg0KDQpUaGFua3MgYSBs b3QuDQpZYW5nYW5nLg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrl j5HpgIHml7bpl7Q6IDIwMTTlubQxMuaciDI35pelIDE1OjEyDQrmlLbku7bkuro6IFpodWFuZ3No dW53YW47IFpodWFuZ3NodW53YW47IFlhbmdhbmc7IFlhbmdhbmcNCuS4u+mimDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15YW4tcnRnd2ctcm91dGluZy1wb2xpY3kteWFuZy0w MC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteWFuLXJ0Z3dnLXJvdXRpbmct cG9saWN5LXlhbmctMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNo dW53YW4gWmh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LXlhbi1ydGd3Zy1yb3V0aW5nLXBvbGljeS15YW5nDQpSZXZpc2lvbjoJMDANClRpdGxl OgkJWWFuZyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIFBvbGljeQ0KRG9jdW1lbnQgZGF0ZToJMjAx NC0xMi0yNw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNTANClVSTDog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW4t cnRnd2ctcm91dGluZy1wb2xpY3kteWFuZy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15YW4tcnRnd2ctcm91dGluZy1wb2xpY3kt eWFuZy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15 YW4tcnRnd2ctcm91dGluZy1wb2xpY3kteWFuZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8gY29u ZmlndXJlDQogICBhbmQgbWFuYWdlIHJvdXRpbmcgcG9saWNpZXMuDQoNCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Dec 29 00:17:26 2014 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1DE1A1B40 for ; Thu, 25 Dec 2014 18:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2UZuVQUoBmV for ; Thu, 25 Dec 2014 18:16:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFCE1A1A4E for ; Thu, 25 Dec 2014 18:16:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQM28318; Fri, 26 Dec 2014 02:16:21 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Dec 2014 02:16:20 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 26 Dec 2014 10:16:08 +0800 From: Qin Wu To: Anees Shaikh , "Acee Lindem (acee)" , Lizhenbin , Susan Hares , "Jeff Tantsura" , "stephane.litkowski@orange.com" , Robert Raszuk Thread-Topic: [Rtg-yang-coord] RE: issue :R01: route filters Thread-Index: AQHQILHp5LA4thAQ5EuaiFgPPbrXBA== Date: Fri, 26 Dec 2014 02:16:08 +0000 Message-ID: References: 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.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA846987ECnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/x-JjOuhJQbFhTCjspXm3-SYLIa0 X-Mailman-Approved-At: Mon, 29 Dec 2014 00:17:24 -0800 Cc: "rtg-yang-coord@ietf.org" , David Sinicrope , Dean Bogdanovic , Ladislav Lhotka Subject: Re: [Rtg-yang-coord] issue :R01: route filters X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 02:16:42 -0000 --_000_B8F9A780D330094D99AF023C5877DABA846987ECnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5lZXM6DQpUaGFua3MgZm9yIHNoYXJpbmcgdGhlIGxpbms6DQpodHRwczovL2dpdGh1Yi5jb20v WWFuZ01vZGVscy95YW5nL3RyZWUvbWFzdGVyL2V4cGVyaW1lbnRhbC9vcGVuY29uZmlnL3BvbGlj eQ0KSSB0aGluayB0aGF0IGhlbHBzIHRoZSBkaXNjdXNzaW9uLg0KDQpSZWdhcmRzIQ0KLVFpbg0K 5Y+R5Lu25Lq6OiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNA aWV0Zi5vcmddIOS7o+ihqCBBbmVlcyBTaGFpa2gNCuWPkemAgeaXtumXtDogMjAxNOW5tDEy5pyI Mjbml6UgOTo1Mw0K5pS25Lu25Lq6OiBBY2VlIExpbmRlbSAoYWNlZSk7IExpemhlbmJpbjsgU3Vz YW4gSGFyZXM7IEplZmYgVGFudHN1cmE7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBS b2JlcnQgUmFzenVrDQrmioTpgIE6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3JnOyBEZWFuIEJvZ2Rh bm92aWM7IExhZGlzbGF2IExob3RrYQ0K5Li76aKYOiBSZTogW1J0Zy15YW5nLWNvb3JkXSDnrZTl pI06IGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCg0KDQpUaGUgT3BlbkNvbmZpZyBuZXR3b3Jr IG9wZXJhdG9ycyB3b3JraW5nIGdyb3VwIHJlY2VudGx5IHB1Ymxpc2hlZCBhbiB1cGRhdGUgdG8g b3VyIEJHUCBkYXRhIG1vZGVsIHRoYXQgbWF5IGJlIG9mIGludGVyZXN0IHRvIHRoaXMgZGlzY3Vz c2lvbi4gIEl0IGFsc28gaW5jbHVkZWQgYSBnZW5lcmFsaXphdGlvbiBvZiByb3V0aW5nIHBvbGlj eSBpbnRvIGEgc2VwYXJhdGUgbW9kZWwgdG8gYmUgdXNlZCBhY3Jvc3MgbXVsdGlwbGUgcm91dGlu ZyBwcm90b2NvbHMsIFZSRnMsIGV0Yy4gICBPdXIgdmlldyBpcyB0aGF0IGl0IGlzIHBvc3NpYmxl IHRvIGNvbWUgdXAgd2l0aCByb3V0aW5nIHBvbGljeSBleHByZXNzaW9uIHRoYXQgY2FuIGJlIG1h cHBlZCByZWxhdGl2ZWx5IGVhc2lseSB0byBhIG51bWJlciBvZiB3aWRlbHkgdXNlZCBpbXBsZW1l bnRhdGlvbnMuICAgSSdtIHBhc3RpbmcgdGhlIGFubm91bmNlbWVudCBlbWFpbCBiZWxvdyB3aXRo IGEgbGluayB0byB0aGUgbW9kdWxlcyBmb3IgYW55b25lIGludGVyZXN0ZWQuDQoNCnRoYW5rcy4N Ci0tIEFuZWVzDQoNCi0tLS0tLS0tLS0tLS0NCmhpIEZvbGtzLCAgdGhlIHdvcmtpbmcgZ3JvdXAg aGFzIHB1Ymxpc2hlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBCR1AgbW9kZWwgd2l0aCBhIG51bWJl ciBvZiBjaGFuZ2VzIGJhc2VkIG9uIGFkZGl0aW9uYWwgb3BlcmF0b3IgaW5wdXQgYXMgd2VsbCBh cyBmcm9tIHRoZSBicm9hZGVyIGNvbW11bml0eS4NCg0KVGhlIHVwZGF0ZWQgbW9kZWxzIGFyZSBh dmFpbGFibGUgaW4gdGhlIFlhbmdNb2RlbHMgcHVibGljIGdpdGh1YjxodHRwczovL2dpdGh1Yi5j b20vWWFuZ01vZGVscy95YW5nL3RyZWUvbWFzdGVyL2V4cGVyaW1lbnRhbC9vcGVuY29uZmlnPiBy ZXBvLg0KDQpIaWdobGlnaHRzIG9mIHRoZSBjaGFuZ2VzOg0KDQpSZWZhY3RvcmVkIG11bHRpcHJv dG9jb2wgbW9kdWxlIHdpdGggZXhwbGljaXQgc2V0IG9mIHN1cHBvcnRlZA0KQUZJLVNBRkkgY29t YmluYXRpb25zICh1c2luZyBZQU5HIGlkZW50aXRpZXMpIGluIGEgZmxhdHRlbmVkIGxpc3QuDQpG b2N1cyB3YXMgb24gY29tbW9uIGNvbmZpZyB3aXRoIG1vcmUgQUZJLVNBRkkgc3BlY2lmaWMgY29u ZmlndXJhdGlvbg0KZm9ydGhjb21pbmcuDQoNClJlZmFjdG9yZWQgQkdQIHBvbGljeSBtb2R1bGUg dG8gd29yayB3aXRoIGEgbmV3IGdlbmVyYWwgcm91dGluZyBwb2xpY3kgbW9kdWxlIChzZWUgYmVs b3cpIGJ5IGF1Z21lbnRpbmcgaXQgd2l0aCBCR1Atc3BlY2lmaWMgcG9saWN5IG9wdGlvbnMgKGNv bmRpdGlvbnMgYW5kIGFjdGlvbnMpLg0KDQpTZXZlcmFsIG5ldyBjb25maWd1cmF0aW9uIGl0ZW1z IGFkZGVkIHRvIGJhc2UgYmdwIG1vZHVsZS4NCg0KVGhlIGJncC1vcGVyYXRpb25hbCBtb2R1bGUg aXMgbGFyZ2VseSB1bmNoYW5nZWQgLS0gdGhlIG5leHQgcmVsZWFzZQ0KaXMgZXhwZWN0ZWQgdG8g Y29udGFpbiBhIHNpZ25pZmljYW50IHVwZGF0ZS4NCg0KSW5pdGlhbCB2ZXJzaW9uIG9mIGEgZ2Vu ZXJhbCByb3V0aW5nLXBvbGljeSBtb2R1bGUgYW5kIGFzc29jaWF0ZWQNCnJldXNhYmxlIHR5cGVz IG1vZHVsZSBmb3IgcG9saWN5LiAgVGhlIHJvdXRpbmcgcG9saWN5IG1vZHVsZSBpcw0KY3VycmVu dGx5IGF1Z21lbnRlZCBieSB0aGUgYmdwLXBvbGljeSBtb2R1bGUgZm9yIGJncC1zcGVjaWZpYw0K cm91dGluZyBwb2xpY3kgb3B0aW9ucy4NCg0KVGhlIElHUCBwb2xpY3kgaXRlbXMgaW4gdGhpcyB2 ZXJzaW9uIG9mIHRoZSBtb2R1bGUgYXJlIGxpbWl0ZWQgdG8NCmdlbmVyaWMgaXRlbXMgYXZhaWxh YmxlIGluIHdpZGVseSB1c2VkIHByb3RvY29scyBsaWtlIElTLUlTIGFuZCBPU1BGLg0KDQpPbiBU aHUgRGVjIDI1IDIwMTQgYXQgNDozNjowMiBQTSBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lz Y28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KUm9iaW4sDQoNCkFzIHlvdSBo YXZlIG5vdGVkLCB0aGVyZSBoYXMgYWxyZWFkeSBiZWVuIHNvbWUgcHJpb3Igd29yayBvbiByb3V0 aW5nDQpwb2xpY3kuIEluIGZhY3QsIGFsbCB0aGUgQkdQIGRyYWZ0cyBoYXZlIGVsZW1lbnRzIG9m IHJvdXRpbmcgcG9saWN5Lg0KVGhlcmVmb3JlLCB0aGUgZmFjdCB0aGF0IHlvdSBoYXZlIGNoYXJ0 ZXJlZCB3b3JrIG9uIHJvdXRpbmcgcG9saWN5IGlzIGJ5DQpubyBtZWFucyBhIGd1YXJhbnRlZSB0 aGF0IHlvdXIgd29yayB3aWxsIGJlY29tZSB0aGUgc3RhbmRhcmQuIEl0IGNhbiwNCmhvd2V2ZXIs IGJlIGFuIGlucHV0IHRvIHRoZSBwcm9jZXNzLg0KDQpUaGFua3MsDQpBY2VlDQoNCk9uIDEyLzI1 LzE0LCA4OjMzIEFNLCAiTGl6aGVuYmluIiA8bGl6aGVuYmluQGh1YXdlaS5jb208bWFpbHRvOmxp emhlbmJpbkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCj5IaSBmb2xrcywNCj5SZWdhcmRpbmcgdGhl IFlhbmcgbW9kZWxzLCBJIGhhdmUgZm9sbG93aW5nIG9waW5pb24gZm9yIGRpc2N1c3Npb246DQo+ MS4gV2UgdGhpbmsgdGhlIGZvcndhcmRpbmcsIHRvcG9sb2d5IGFuZCBwb2xpY3kgYXJlIHRoZSBi YXNpYyBjb21wb25lbnRzDQo+Zm9yIEkyUlMuIEl0IGlzIGJldHRlciB0aGUgWWFuZyBtb2RlbHMg Zm9yIHRoZSBwb2xpY3kgc2hvdWxkIGJlIGRlZmluZWQNCj5pbiB0aGUgSTJSUyBXRyBpbnN0ZWFk IG9mIFJUR1dHLg0KPjIuIFRob3VnaCB0aGUgcm91dGUgcG9saWN5IGhhcyBtdWNoIHJlbGF0aW9u IHdpdGggQkdQLCB3ZSB0aGluayB0aGUNCj5wb2xpY3kgc2hvdWxkIGJlIGluZGVwZW5kZW50IHNp bmNlIGl0IG1heSBiZSB1c2VkIGZvciBvdGhlciBwcm90b2NvbHMuDQo+Tm93IElQIHByZWZpeCBs aXN0IGlzIGRlZmluZWQgaW4gQkdQIHlhbmcgbW9kZWxzLiBXZSBob3BlIGl0IHNob3VsZCBiZQ0K PmRlZmluZWQgaW4gdGhlIHJvdXRpbmcgcG9saWN5LiBUaGUgZGVjb3VwbGluZyBvZiB0aGUgcG9s aWN5IGZyb20gdGhlDQo+cHJvdG9jb2wgbWF5IGJlbmVmaXQgdGhlIFlhbmcgbW9kZWwgZGVmaW5p dGlvbiBmb3IgdGhlIHBvdG9jb2wuDQo+My4gVGhvdWdoIHdlIGFyZSBkZWZpbmluZyB0aGUgWWFu ZyBtb2RlbHMgZm9yIHRoZSByb3V0ZSBwb2xpY3ksIHdlIGFyZQ0KPmF3YXJlIHRoZXkgYXJlIG5v dCBmbGV4aWJsZSBlbm91Z2ggZm9yIHNvbWUgc2NlbmFyaW9zLiBDb3VsZCB3ZSBzdGFydCB0bw0K PnN0YW5kYXJkaXplIHNvbWUgcG9saWN5IHNwZWNpZmljIGxhbmd1YWdlIHN1Y2ggYXMgUlBTTCB3 aGlsZSBkZWZpbmUgdGhlDQo+WWFuZyBtb2RlbHMgZm9yIHRoZSByb3V0aW5nIHBvbGljeT8NCj4N Cj4NCj5SZWdhcmRzLA0KPlJvYmluDQo+DQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPuWPkeS7tuS6ujogUnRnLXlhbmctY29vcmQgW3J0Zy15 YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNA aWV0Zi5vcmc+XSDku6PooaggU3VzYW4gSGFyZXMNCj5bc2hhcmVzQG5kemguY29tPG1haWx0bzpz aGFyZXNAbmR6aC5jb20+XQ0KPuWPkemAgeaXtumXtDogMjAxNOW5tDEy5pyIMjDml6UgNzowOQ0K PuaUtuS7tuS6ujogJ0plZmYgVGFudHN1cmEnOyAnQWNlZSBMaW5kZW0gKGFjZWUpJzsNCj5zdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20+OyAnUm9iZXJ0IFJhc3p1aycNCj7mioTpgIE6IHJ0Zy15YW5nLWNvb3JkQGlldGYub3Jn PG1haWx0bzpydGcteWFuZy1jb29yZEBpZXRmLm9yZz47ICdEZWFuIEJvZ2Rhbm92aWMnOyAnTGFk aXNsYXYgTGhvdGthJw0KPuS4u+mimDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTog cm91dGUgZmlsdGVycw0KPg0KPlN0ZXBoZW46DQo+DQo+SSBhbSBpbnRlcmVzdGVkLiAgV2UgaGF2 aW5nIHJvdXRpbmcgcG9saWN5IGRpc2N1c3Npb24gaW4gSTJSUyByZWxhdGluZyBQQlINCj5hbmQg cG9saWN5LiAgSXQgbmVlZHMgdG8gbGluayB0byBhIGJhc2Ugc3BlY2lmaWNhdGlvbi4NCj4NCj5T dWUNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFJ0Zy15YW5nLWNvb3Jk IFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLXlhbmct Y29vcmQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZg0KPkplZmYgVGFudHN1cmENCj5T ZW50OiBGcmlkYXksIERlY2VtYmVyIDE5LCAyMDE0IDQ6MzYgUE0NCj5UbzogQWNlZSBMaW5kZW0g KGFjZWUpOyBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb20+OyBSb2JlcnQgUmFzenVrDQo+Q2M6IHJ0Zy15YW5nLWNvb3JkQGll dGYub3JnPG1haWx0bzpydGcteWFuZy1jb29yZEBpZXRmLm9yZz47IERlYW4gQm9nZGFub3ZpYzsg TGFkaXNsYXYgTGhvdGthDQo+U3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIw MTogcm91dGUgZmlsdGVycw0KPg0KPknigJlkIGxpa2UgdG8gYmUgaW52b2x2ZWQsIGFzIHdlbGwg YXMgZ2l2aW5nIGl0IGEgaG9tZSBpbiBydGd3Zw0KPg0KPkNoZWVycywNCj5KZWZmDQo+DQo+DQo+ DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4NCj4+DQo+Pk9uIDEyLzE5LzE0LCA3 OjAwIEFNLCAic3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tPiINCj4+PHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1h aWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KPj4NCj4+PkFuZCBx dWVzdGlvbiA6IFdobyBpcyBpbnRlcmVzdGVkIHRvIHN0YXJ0IG5vdyB0aGUgd29yayBvbiBzdGFu ZGFyZA0KPj4+cm91dGluZyBwb2xpY3kgPw0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj5Gcm9tOiBSdGcteWFuZy1jb29yZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3Jk LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbg0KPj4+QmVoYWxmIE9mIHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4NCj4+PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg MTksIDIwMTQgMTI6NTkNCj4+PlRvOiBSb2JlcnQgUmFzenVrDQo+Pj5DYzogcnRnLXlhbmctY29v cmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPjsgQWNlZSBMaW5kZW0g KGFjZWUpOyBEZWFuIEJvZ2Rhbm92aWM7IEplZmYNCj4+PlRhbnRzdXJhOyBMYWRpc2xhdiBMaG90 a2ENCj4+PlN1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZp bHRlcnMNCj4+Pg0KPj4+Um9iZXJ0LA0KPj4+DQo+Pj5Zb3UgYXJlIHRvdWNoaW5nIGFuIGludGVy ZXN0aW5nIHBvaW50IDopIEluIGZhY3QgdGhlcmUgYXJlIHR3byB3YXlzIG9mDQo+Pj52aWV3aW5n IHRoaW5rcyA6DQo+Pj4tIHNlcnZpY2UgcHJvdmlkZXJzL2N1c3RvbWVycyB3aG8gd291bGQgbGlr ZSB0byB1c2Ugb25seSBzdGFuZGFyZA0KPj4+bW9kZWxzIHRvIGZhY2lsaXRhdGUgbmV0d29yayBw cm92aXNpb24gJiBvcGVyYXRpb24NCj4+Pi0gdmVuZG9ycyB3aG8gbWF5IG5vdCB3YW50IHRvIG1h a2UgZGV2ZWxvcG1lbnQgdG8gaW1wbGVtZW50IG5ldw0KPj4+ZmVhdHVyZXMgdG8gYmUgY29tcGxp YW50IHdpdGggYSBzdGFuZGFyZCB5YW5nIG1vZGVsICAoYXMgZGV2IGNvc3QNCj4+Pm1vbmV5KS4g QXMgeW91IG1lbnRpb25lZCwgb3BlcmF0aW9uIG9mIGJveGVzIGlzIHRvZGF5IGEga2V5DQo+Pj5k aWZmZXJlbnRpYXRvciB3aGVuIGNob29zaW5nIGEgdmVuZG9yLg0KPj4+V2UgY2xlYXJseSB0aGlz IGRpdmVyZ2VuY2UgdG9kYXkgaW4gcHJvZHVjZWQgWWFuZyBtb2RlbCAob3BlcmF0b3INCj4+PmF1 dGhvcnMgbW9kZWxzIHZzIHZlbmRvciBhdXRob3JzIG1vZGVsKQ0KPj4+DQo+Pj5BcyBhIHNlcnZp Y2UgcHJvdmlkZXIsIEknbSBjbGVhcmx5IHB1c2hpbmcgdG8gdXNlIG9ubHkgc3RhbmRhcmQgbW9k ZWwNCj4+PmF0IGxlYXN0IGZvciBtb3N0IG9mIHRoZSBiYXNlIHN0cnVjdHVyZSBvZiBzZXJ2aWNl cyBhbmQgSSB3aWxsIHB1c2ggbXkNCj4+PnZlbmRvcnMgdG8gc3VwcG9ydCBpdCBhcyBtb3JlIGFz IHBvc3NpYmxlLiBJIHdvdWxkIHNheSB0aGF0IG1vcmUgdGhhbg0KPj4+OTAlIG9mIHBhcmFtZXRl cnMgb2YgYSBzZXJ2aWNlIGFyZSBjb21tb24gdG8gYWxsIGltcGxlbWVudGF0aW9ucyAoanVzdA0K Pj4+ZGV0YWlscyBhcmUgY2hhbmdpbmcgIDogbG9jYWxpemF0aW9uIG9mIHRoZSBjb25maWcgc3Rh dGVtZW50IG9yDQo+Pj5ncmFudWxhcml0eSBvZiB0aGUgcGFyYW1ldGVyKS4gU28gSSB0aGluayB0 aGF0IGNyZWF0aW5nIHVzYWJsZQ0KPj4+c3RhbmRhcmQgbW9kZWwgY2FuIHdvcmsuIFRoZSByZW1h aW5pbmcgeCUgY2FuIGJlIGFkZHJlc3NlZCBieSB2ZW5kb3INCj5leHRlbnNpb25zLg0KPj4+DQo+ Pj5Db21pbmcgYmFjayB0byByb3V0aW5nIHBvbGljaWVzLiBJIGRvIHRoaW5rIHRoYXQgcmVzdGFy dGluZyBhIG5ldw0KPj4+ZnJhbWV3b3JrIGZyb20gc3RyYXRjaCBpcyB0aGUgcmlnaHQgd2F5IHRv IGRvIGl0LiBBbmQgYXMgYW55IHByb3RvY29sDQo+Pj5leHRlbnNpb24gb3IgZmVhdHVyZSBzdGFu ZGFyZGl6ZWQgaW4gSUVURiwgaXQgd2lsbCBiZSB1cCB0byBjdXN0b21lcnMNCj4+PnRvIHJlcXVl c3QgdGhlaXIgdmVuZG9ycyBmb3IgaW1wbGVtZW50YXRpb25zLg0KPj4+DQo+Pj5Ub2RheSByb3V0 aW5nIHBvbGljeSBtYW5hZ2VtZW50IGJldHdlZW4gZGlmZmVyZW50IHZlbmRvcnMgaXMgY3Jhenku DQo+Pj5Db25zaWRlciB5b3UgaGF2ZSBhIFZlbmRvciBYIG5ldHdvcmsgd2l0aCB3aWRlbHkgZGVw bG95ZWQgY29tcGxleA0KPj4+cm91dGluZyBwb2xpY2llcywgYW5kIHlvdSB3YW50IHRvIGludHJv ZHVjZSB0byB2ZW5kb3IgWSwgdHJhbnNsYXRpb24NCj4+Pm9mIHJvdXRpbmcgcG9saWNpZXMgZnJv bSBsYW5ndWFnZSBYIHRvIFkgaXMgYSB2ZXJ5IGNvbXBsZXggd29yay4NCj4+Pg0KPj4+TW9yZW92 ZXIgd2UgY2FuIHNlZSB0aGF0IGZyYW1ld29yayBvZiBwb2xpY3kgbW9kZWwgaXMgYWxyZWFkeSBl eGlzdGluZw0KPj4+Zm9yIGludGVybmV0IHJlZ2lzdHJpZXMgdXNpbmcgUlBTTC4NCj4+Pg0KPj4+ SSBkbyBub3Qga25vdyB0b2RheSB3aGVyZSB0aGlzIFlhbmcgaW5pdGlhdGl2ZSB3aWxsIGdvIC4u LiBidXQgSSB3aWxsDQo+Pj5wcm9uZSBhIGNvbnNlbnN1cyBvbiBzdHJvbmcgYWRvcHRpb24gb2Yg c3RhbmRhcmQgWUFORyBtb2RlbHMgcmF0aGVyDQo+Pj50aGFuIHZlbmRvciBzcGVjaWZpYyBvbmx5 Lg0KPj4+DQo+Pj4NCj4+PlN0ZXBoYW5lDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJh c3p1a0BnbWFpbC5jb20+IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtA Z21haWwuY29tPl0gT24gQmVoYWxmIE9mIFJvYmVydA0KPj4+UmFzenVrDQo+Pj5TZW50OiBGcmlk YXksIERlY2VtYmVyIDE5LCAyMDE0IDExOjEwDQo+Pj5UbzogTElUS09XU0tJIFN0ZXBoYW5lIFND RS9JQk5GDQo+Pj5DYzogSmVmZiBUYW50c3VyYTsgQWNlZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJv Z2Rhbm92aWM7DQo+Pj5ydGcteWFuZy1jb29yZEBpZXRmLm9yZzxtYWlsdG86cnRnLXlhbmctY29v cmRAaWV0Zi5vcmc+OyBMYWRpc2xhdiBMaG90a2ENCj4+PlN1YmplY3Q6IFJlOiBbUnRnLXlhbmct Y29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4+Pg0KPj4+SGkgU3RlcGhhbmUsDQo+ Pj4NCj4+PlRoYXQgaXMgZ29pbmcgdG8gYmUgdmVyeSBpbnRlcmVzdGluZyBpbmRlZWQuIENvbnNp ZGVyaW5nIHRoYXQgbnVtYmVyDQo+Pj5vZiBjdXN0b21lcnMgaGF2ZSBwYWlkIHZlbmRvcnMgbWls bGlvbnMgZm9yIGN1c3RvbWl6ZWQgZXh0ZW5zaW9ucyBhbmQNCj4+Pm9ubHkgc29tZSBvZiB0aGVt IG1hZGUgaXQgdG8gSUVURiBkcmFmdHMvcmZjcy4NCj4+Pg0KPj4+U28gd2hhdCB3aWxsIG1vc3Qg bGlrZWx5IGhhcHBlbiBpcyBnZW5lcmFsIFlBTkcgbW9kZWwgb2Ygbm90IG11Y2ggdXNlDQo+Pj5h bmQgem9vIG9mIHByb3ByaWV0YXJ5IHZlbmRvciBZQU5HIGV4dGVuc2lvbnMgbm90IGNvbXBhdGli bGUgYmV0d2Vlbg0KPj4+aW1wbGVtZW50YXRpb25zLg0KPj4+DQo+Pj5JcyB0aGlzIHJlYWxseSB3 aGVyZSB3ZSB3YW50IHRvIGdvIHdpdGggdGhpcyBlbnRpcmUgZWZmb3J0ID8NCj4+Pg0KPj4+QmVz dCwNCj4+PnIuDQo+Pj4NCj4+Pg0KPj4+T24gRnJpLCBEZWMgMTksIDIwMTQgYXQgMTE6MDMgQU0s ICA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tPj4NCj4+Pndyb3RlOg0KPj4+PiBIaSwNCj4+Pj4NCj4+Pj4gSSB0aGluayB3 b3JraW5nIG9mIEJHUCBZQU5HIGlzIGEgZ29vZCBvcHBvcnR1bml0eSB0byBzdGFydCB3b3JraW5n DQo+Pj4+b24gcG9saWN5IGZyYW1ld29yay4NCj4+Pj4gV29yayBvbiBwcm90b2NvbHMgWUFORyBp cyBhbHJlYWR5IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWcNCj4+Pj5kaXNwcmVjYW5jaWVzLCBJ IGV4cGVjdCBwb2xpY3kgd29yayB0byBiZSBtdWNoIGhhcmRlciAuLi4NCj4+Pj4NCj4+Pj4gQnV0 IEkgdGhpbmssIHRoZXJlIGlzIGFuIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHNvbWV0aGluZyBuZXcg Zm9yDQo+Pj4+ZXZlcnlvbmUgKHRoYXQgbWF5IGNvZXhpc3Qgd2l0aCBleGlzdGluZyBDTEkgcG9s aWNpZXMpIGFuZCBub3QNCj4+Pj5sb29raW5nIGF0IENMSSB0cmFuc2xhdGlvbiAoaXQgd2lsbCBi ZSBpbXBvc3NpYmxlIHdpdGggcG9saWNpZXMpLg0KPj4+PlRoZW4gaXQgd291bGQgYmUgdXAgdG8g c2VydmljZSBwcm92aWRlcnMgdG8gcmVxdWVzdCB0aGUgc3VwcG9ydCBvZg0KPj4+PnRoaXMgYnkg dGhlaXIgZmF2b3JpdGUgdmVuZG9ycy4NCj4+Pj4NCj4+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+Pg0K Pj4+PiBTdGVwaGFuZQ0KPj4+Pg0KPj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+PiBGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+ IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gT24g QmVoYWxmIE9mDQo+Pj4+IFJvYmVydCBSYXN6dWsNCj4+Pj4gU2VudDogV2VkbmVzZGF5LCBEZWNl bWJlciAxNywgMjAxNCAyMzoyOA0KPj4+PiBUbzogSmVmZiBUYW50c3VyYQ0KPj4+PiBDYzogQWNl ZSBMaW5kZW0gKGFjZWUpOyBEZWFuIEJvZ2Rhbm92aWM7IHJ0Zy15YW5nLWNvb3JkQGlldGYub3Jn PG1haWx0bzpydGcteWFuZy1jb29yZEBpZXRmLm9yZz47DQo+Pj4+IExJVEtPV1NLSSBTdGVwaGFu ZSBTQ0UvSUJORjsgTGFkaXNsYXYgTGhvdGthDQo+Pj4+IFN1YmplY3Q6IFJlOiBbUnRnLXlhbmct Y29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnMNCj4+Pj4NCj4+Pj4gU28gYXJlIHlvdSBz YXlpbmcgdGhhdCBmb3JtYWwgWUFORyBzcGVjaWZpY2F0aW9uIHNheSBmb3IgQkdQIGJ5DQo+Pj4+ ZGVzaWduIHdpbGwgbm90IGJlIGNvbXBhdGlibGUgd2l0aCBzb21lIGltcGxlbWVudGF0aW9ucyA/ DQo+Pj4+DQo+Pj4+IE9yIGFyZSB5b3Ugc2F5aW5nIHRoYXQgZm9ybWFsIGRlc2lnbiBzYXkgb2Yg QkdQIHByb3RvY29sIHdpbGwgaGF2ZQ0KPj4+PnRvIHdhaXQgZmV3IHllYXJzIHRpbGwgWUFORyBm b3IgcG9saWN5IHNwZWMgaXMgY29tcGxldGUgPw0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+IHIu DQo+Pj4+DQo+Pj4+IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0IDExOjE0IFBNLCBKZWZmIFRhbnRz dXJhDQo+Pj4+PGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPG1haWx0bzpqZWZmLnRhbnRzdXJh QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPj4+Pj4gWWVzLCBleGFjdGx5LCBSb2JlcnQgLSB0aGUg YmVoYXZpb3IgeW91IGhhdmUgZGVzY3JpYmVkIGlzIGFuDQo+Pj4+PmltcGxlbWVudGF0aW9uLCBu b3QgYSBmb3JtYWwgc3BlY2lmaWNhdGlvbi4NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4g SmVmZg0KPj4+Pj4NCj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTQsIGF0IDI6MTIgUE0sIEFjZWUgTGlu ZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCj4+Pj4+ Pndyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gV2h5IGlzIHRoaXMgYSBwcm9ibGVtIGlmIHRoZSBkZWZh dWx0IGlzIHRvIG5vdCB0byByZWRpc3RyaWJ1dGUNCj4+Pj4+PnJvdXRlcyBiZXR3ZWVuIFJJQnM/ IE5vdGUgdGhhdCBpdCBpc27CuXQgbGlrZSB3ZSBoYXZlIGEgc2V0IG9mDQo+Pj4+Pj5hcHByb3Zl ZCByb3V0aW5nIHByb3RvY29sIG1vZGVscyB0aGF0IGFyZSBkZXBlbmRlbnQgb24gdGhpcyBiZWhh dmlvci4NCj4+Pj4+PiBBY2VlDQo+Pj4+Pj4NCj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDE0LCBhdCA1 OjA3IFBNLCBEZWFuIEJvZ2Rhbm92aWMgPGRlYW5iQGp1bmlwZXIubmV0PG1haWx0bzpkZWFuYkBq dW5pcGVyLm5ldD4+DQo+Pj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJvYmVydCwNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gWW91ciBwcm9wb3NhbCBpcyB2ZXJ5IHNlbnNpYmxlIGFuZCBJIHRoaW5r IHRoaXMgaXMgdGhlIGJlc3QNCj4+Pj4+Pj4gb3B0aW9uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IERlYW4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4+IE9uIERlYyAxNywgMjAxNCwgYXQgNDo0OSBQTSwgUm9iZXJ0IFJh c3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCj4+Pj4+ Pj4+d3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRGVhbiwgYWxsDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gVGhlIHdheSBJIHJlYWQgaXQgY3VycmVudGx5IGluIHNlY3Rpb24gNS41IHRoZXJlIGFyZSBv bmx5IHR3bw0KPj4+Pj4+Pj5yb3V0ZSBmaWx0ZXJzIHByb3Bvc2VkIChkZW55LWFsbCBvciBhbGxv dy1hbGwpLiBBcyB3ZSBrbm93IHNvbWUNCj4+Pj4+Pj4+cm91dGluZyBwcm90b2NvbHMgcmVxdWly ZSBleHBsaWNpdCBwZXJtaXNzaW9uIHRvIG9wZXJhdGUgKGV4YW1wbGU6DQo+Pj4+Pj4+PkVCR1Ap Lg0KPj4+Pj4+Pj4gSWYgd2UgcmVtb3ZlIGV2ZW4gdGhvc2UgdHdvIHByaW1pdGl2ZSBmaWx0ZXJz IHRoZXJlIGNhbiBiZQ0KPj4+Pj4+Pj5pbXBhY3QgIHRvIG90aGVyIGNvbXBvbmVudHMuDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gQnV0IEkgZG8gc3VwcG9ydCBhIHNlcGFyYXRlIHdvcmsgZm9yIFlBTkcg bW9kZWwgZm9yIHBvbGljeS4gSSBkbw0KPj4+Pj4+Pj4gZXhwZWN0IHRoaXMgdG8gYmUgYSB2ZXJ5 IGludGVyZXN0aW5nIGFuZCBpbnZvbHZlZCB3b3JrDQo+Pj4+Pj4+PiBjb25zaWRlcmluZyBzaWdu aWZpY2FudCBkaXZlcnNpdHkgb2YgcG9saWN5IGxhbmd1YWdlcyBhY3Jvc3MgYWxsDQo+Pj4+Pj4+ PiBpbXBsZW1lbnRhdGlvbnMgdG9kYXkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT25jZSB0aGF0IHdv cmsgaXMgZG9uZSB3ZSBjb3VsZCByZXRpcmUgc2VjdGlvbiA1LjUgb2YNCj4+Pj4+Pj4+ICotbmV0 bW9kLXJvdXRpbmctKg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+PiByLg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT24gV2VkLCBEZWMgMTcsIDIwMTQgYXQgMTA6 MDkgUE0sIERlYW4gQm9nZGFub3ZpYw0KPj4+Pj4+Pj4+PGRlYW5iQGp1bmlwZXIubmV0PG1haWx0 bzpkZWFuYkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KPj4+Pj4+Pj4+IEknbSBpbiBzdXBwb3J0IG9m IHJlbW92aW5nIHJvdXRlIGZpbHRlcnMgZnJvbSB0aGUgcm91dGluZyBjZmcNCj4+Pj4+Pj4+Pm1v ZGVsLiBSb3V0ZSBmaWx0ZXJzIHNob3VsZCBiZSBJTU8gcGFydCBvZiB0aGUgcG9saWN5IG1vZGVs LCBpbg0KPj4+Pj4+Pj4+d2hpY2ggYWxzbyBBQ0wgbW9kZWwgYmVsb25ncyB0b28uIEFjdHVhbGx5 LCBJIHdvdWxkIGFyZ3VlIHRoYXQNCj4+Pj4+Pj4+PnRoZSBjdXJyZW50IEFDTCBtb2RlbCBpcyB2 ZXJ5IHN1aXRhYmxlIGZvciByb3V0ZSBmaWx0ZXJzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gRGVh bg0KPj4+Pj4+Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+PiBSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4g UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPg0K Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNv b3JkDQo+Pj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gX18gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+DQo+Pj4+IENlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucw0KPj4+PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPj4+PmV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4+Pj5wYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaQ0K Pj4+PnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcw0KPj4+PmQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPj4+PmFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuDQo+Pj4+DQo+Pj4+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPj4+PnByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90DQo+Pj4+ YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+ Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyDQo+Pj4+YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCj4+Pj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdA0KPj4+PmhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQo+Pj4+IFRoYW5rIHlvdS4NCj4+Pj4NCj4+Pg0KPj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+X19fDQo+Pj5fDQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+DQo+Pj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4+PmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPj4+ZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZQ0KPj4+cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kNCj4+PnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcw0KPj4+ZCdhbHRlcmF0aW9uLCBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlDQo+Pj5h bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4+DQo+Pj5UaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+PnByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91 bGQgbm90DQo+Pj5iZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KPj4+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPj4+ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KPj4+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+Pj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4+PlRoYW5rIHlvdS4NCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PlJ0Zy15YW5nLWNvb3JkIG1haWxpbmcg bGlzdA0KPj4+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGll dGYub3JnPg0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFu Zy1jb29yZA0KPj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5fX18NCj4+Pl8NCj4+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4NCj4+PkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cw0KPj4+Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMg cGFzIGV0cmUgZGlmZnVzZXMsDQo+Pj5leHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlDQo+Pj5wYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaQ0KPj4+cXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzDQo+Pj5kJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUNCj4+PmFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuDQo+Pj4NCj4+PlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvcg0KPj4+cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4+PmJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+Pj5JZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k DQo+Pj5kZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+Pj5BcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUNCj4+PmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4+VGhhbmsg eW91Lg0KPj4+DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+UnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQo+UnRnLXlhbmctY29vcmRA aWV0Zi5vcmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlJ0Zy15YW5nLWNvb3JkIG1haWxp bmcgbGlzdA0KPlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPG1haWx0bzpSdGcteWFuZy1jb29yZEBp ZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5n LWNvb3JkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNClJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPG1h aWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCg== --_000_B8F9A780D330094D99AF023C5877DABA846987ECnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmVlczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3Igc2hhcmluZyB0aGUgbGlu azo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmh0dHBzOi8vZ2l0 aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcvdHJlZS9tYXN0ZXIvZXhwZXJpbWVudGFsL29wZW5jb25m aWcvcG9saWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRo aW5rIHRoYXQgaGVscHMgdGhlIGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4tUWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gUnRnLXlhbmctY29vcmQgW21haWx0 bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFuZWVzIFNoYWlraDxicj4NCjwvc3Bhbj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3Bh biBsYW5nPSJFTi1VUyI+MTI8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjI2PC9zcGFuPuaX pTxzcGFuIGxhbmc9IkVOLVVTIj4gOTo1Mzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBBY2VlIExpbmRlbSAo YWNlZSk7IExpemhlbmJpbjsgU3VzYW4gSGFyZXM7IEplZmYgVGFudHN1cmE7IHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tOyBSb2JlcnQgUmFzenVrPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxz cGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHJ0Zy15YW5n LWNvb3JkQGlldGYub3JnOyBEZWFuIEJvZ2Rhbm92aWM7IExhZGlzbGF2IExob3RrYTxicj4NCjwv c3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBSZTogW1J0Zy15YW5nLWNvb3JkXQ0KPC9zcGFuPuetlOWkjTxzcGFuIGxhbmc9IkVO LVVTIj46IGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxicj4NClRoZSBPcGVuQ29uZmlnIG5ldHdvcmsgb3BlcmF0b3JzIHdvcmtpbmcg Z3JvdXAgcmVjZW50bHkgcHVibGlzaGVkIGFuIHVwZGF0ZSB0byBvdXIgQkdQIGRhdGEgbW9kZWwg dGhhdCBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gdGhpcyBkaXNjdXNzaW9uLiZuYnNwOyBJdCBhbHNv IGluY2x1ZGVkIGEgZ2VuZXJhbGl6YXRpb24gb2Ygcm91dGluZyBwb2xpY3kgaW50byBhIHNlcGFy YXRlIG1vZGVsIHRvIGJlIHVzZWQgYWNyb3NzIG11bHRpcGxlIHJvdXRpbmcgcHJvdG9jb2xzLA0K IFZSRnMsIGV0Yy4gJm5ic3A7IE91ciB2aWV3IGlzIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gY29t ZSB1cCB3aXRoIHJvdXRpbmcgcG9saWN5IGV4cHJlc3Npb24gdGhhdCBjYW4gYmUgbWFwcGVkIHJl bGF0aXZlbHkgZWFzaWx5IHRvIGEgbnVtYmVyIG9mIHdpZGVseSB1c2VkIGltcGxlbWVudGF0aW9u cy4gJm5ic3A7IEknbSBwYXN0aW5nIHRoZSBhbm5vdW5jZW1lbnQgZW1haWwgYmVsb3cgd2l0aCBh IGxpbmsgdG8gdGhlIG1vZHVsZXMgZm9yIGFueW9uZSBpbnRlcmVzdGVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ LS0gQW5lZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLS0t LS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPmhpIEZvbGtzLCAm bmJzcDt0aGUgd29ya2luZyBncm91cCBoYXMgcHVibGlzaGVkIGEgbmV3IHZlcnNpb24gb2YgdGhl IEJHUCBtb2RlbCB3aXRoIGEgbnVtYmVyIG9mIGNoYW5nZXMgYmFzZWQgb24gYWRkaXRpb25hbCBv cGVyYXRvciBpbnB1dCBhcyB3ZWxsIGFzIGZyb20gdGhlIGJyb2FkZXINCiBjb21tdW5pdHkuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFs aWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+VGhlIHVw ZGF0ZWQgbW9kZWxzIGFyZSBhdmFpbGFibGUgaW4gdGhlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy90cmVlL21hc3Rlci9leHBlcmltZW50YWwvb3BlbmNv bmZpZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojNjYxMUNDO2JvcmRlcjpu b25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY207dGV4dC1kZWNvcmF0aW9uOm5vbmUiPllh bmdNb2RlbHMNCiBwdWJsaWMgZ2l0aHViPC9zcGFuPjwvYT4mbmJzcDtyZXBvLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5IaWdobGlnaHRzIG9mIHRoZSBjaGFuZ2Vz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246YmFz ZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5SZWZhY3RvcmVkIG11 bHRpcHJvdG9jb2wgbW9kdWxlIHdpdGggZXhwbGljaXQgc2V0IG9mIHN1cHBvcnRlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy MjIyMjIiPkFGSS1TQUZJIGNvbWJpbmF0aW9ucyAodXNpbmcgWUFORyBpZGVudGl0aWVzKSBpbiBh IGZsYXR0ZW5lZCBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPkZvY3VzIHdhcyBvbiBjb21tb24gY29uZmln IHdpdGggbW9yZSBBRkktU0FGSSBzcGVjaWZpYyBjb25maWd1cmF0aW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ Zm9ydGhjb21pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWdu OmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+UmVmYWN0b3Jl ZCBCR1AgcG9saWN5IG1vZHVsZSB0byB3b3JrIHdpdGggYSBuZXcgZ2VuZXJhbCByb3V0aW5nIHBv bGljeSBtb2R1bGUgKHNlZSBiZWxvdykgYnkgYXVnbWVudGluZyBpdCB3aXRoIEJHUC1zcGVjaWZp YyBwb2xpY3kNCiBvcHRpb25zIChjb25kaXRpb25zIGFuZCBhY3Rpb25zKS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVy dGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIy Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMjIyMjIyIj5TZXZlcmFsIG5ldyBjb25maWd1cmF0aW9uIGl0ZW1zIGFk ZGVkIHRvIGJhc2UgYmdwIG1vZHVsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246YmFzZWxpbmUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVy dGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIy Ij5UaGUgYmdwLW9wZXJhdGlvbmFsIG1vZHVsZSBpcyBsYXJnZWx5IHVuY2hhbmdlZCAtLSB0aGUg bmV4dCByZWxlYXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+aXMgZXhwZWN0ZWQgdG8gY29udGFpbiBhIHNpZ25p ZmljYW50IHVwZGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MjIyMjIyIj5Jbml0aWFsIHZlcnNpb24gb2YgYSBnZW5lcmFsIHJvdXRpbmctcG9saWN5IG1vZHVs ZSBhbmQgYXNzb2NpYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPnJldXNhYmxlIHR5cGVzIG1vZHVsZSBmb3Ig cG9saWN5LiZuYnNwOyBUaGUgcm91dGluZyBwb2xpY3kgbW9kdWxlIGlzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ Y3VycmVudGx5IGF1Z21lbnRlZCBieSB0aGUgYmdwLXBvbGljeSBtb2R1bGUgZm9yIGJncC1zcGVj aWZpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMyMjIyMjIiPnJvdXRpbmcgcG9saWN5IG9wdGlvbnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzIyMjIyMiI+VGhlIElHUCBwb2xpY3kgaXRlbXMgaW4gdGhpcyB2ZXJzaW9u IG9mIHRoZSBtb2R1bGUgYXJlIGxpbWl0ZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idmVydGljYWwtYWxpZ246YmFz ZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5nZW5lcmljIGl0ZW1z IGF2YWlsYWJsZSBpbiB3aWRlbHkgdXNlZCBwcm90b2NvbHMgbGlrZSBJUy1JUyBhbmQgT1NQRi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+T24gVGh1IERlYyAyNSAyMDE0IGF0IDQ6MzY6MDIgUE0gQWNlZSBMaW5kZW0gKGFj ZWUpICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlJvYmluLDxicj4NCjxicj4NCkFzIHlvdSBoYXZlIG5vdGVkLCB0 aGVyZSBoYXMgYWxyZWFkeSBiZWVuIHNvbWUgcHJpb3Igd29yayBvbiByb3V0aW5nPGJyPg0KcG9s aWN5LiBJbiBmYWN0LCBhbGwgdGhlIEJHUCBkcmFmdHMgaGF2ZSBlbGVtZW50cyBvZiByb3V0aW5n IHBvbGljeS48YnI+DQpUaGVyZWZvcmUsIHRoZSBmYWN0IHRoYXQgeW91IGhhdmUgY2hhcnRlcmVk IHdvcmsgb24gcm91dGluZyBwb2xpY3kgaXMgYnk8YnI+DQpubyBtZWFucyBhIGd1YXJhbnRlZSB0 aGF0IHlvdXIgd29yayB3aWxsIGJlY29tZSB0aGUgc3RhbmRhcmQuIEl0IGNhbiw8YnI+DQpob3dl dmVyLCBiZSBhbiBpbnB1dCB0byB0aGUgcHJvY2Vzcy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0K QWNlZTxicj4NCjxicj4NCk9uIDEyLzI1LzE0LCA4OjMzIEFNLCAmcXVvdDtMaXpoZW5iaW4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsaXpoZW5iaW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmxpemhlbmJpbkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0O0hp IGZvbGtzLDxicj4NCiZndDtSZWdhcmRpbmcgdGhlIFlhbmcgbW9kZWxzLCBJIGhhdmUgZm9sbG93 aW5nIG9waW5pb24gZm9yIGRpc2N1c3Npb246PGJyPg0KJmd0OzEuIFdlIHRoaW5rIHRoZSBmb3J3 YXJkaW5nLCB0b3BvbG9neSBhbmQgcG9saWN5IGFyZSB0aGUgYmFzaWMgY29tcG9uZW50czxicj4N CiZndDtmb3IgSTJSUy4gSXQgaXMgYmV0dGVyIHRoZSBZYW5nIG1vZGVscyBmb3IgdGhlIHBvbGlj eSBzaG91bGQgYmUgZGVmaW5lZDxicj4NCiZndDtpbiB0aGUgSTJSUyBXRyBpbnN0ZWFkIG9mIFJU R1dHLjxicj4NCiZndDsyLiBUaG91Z2ggdGhlIHJvdXRlIHBvbGljeSBoYXMgbXVjaCByZWxhdGlv biB3aXRoIEJHUCwgd2UgdGhpbmsgdGhlPGJyPg0KJmd0O3BvbGljeSBzaG91bGQgYmUgaW5kZXBl bmRlbnQgc2luY2UgaXQgbWF5IGJlIHVzZWQgZm9yIG90aGVyIHByb3RvY29scy48YnI+DQomZ3Q7 Tm93IElQIHByZWZpeCBsaXN0IGlzIGRlZmluZWQgaW4gQkdQIHlhbmcgbW9kZWxzLiBXZSBob3Bl IGl0IHNob3VsZCBiZTxicj4NCiZndDtkZWZpbmVkIGluIHRoZSByb3V0aW5nIHBvbGljeS4gVGhl IGRlY291cGxpbmcgb2YgdGhlIHBvbGljeSBmcm9tIHRoZTxicj4NCiZndDtwcm90b2NvbCBtYXkg YmVuZWZpdCB0aGUgWWFuZyBtb2RlbCBkZWZpbml0aW9uIGZvciB0aGUgcG90b2NvbC48YnI+DQom Z3Q7My4gVGhvdWdoIHdlIGFyZSBkZWZpbmluZyB0aGUgWWFuZyBtb2RlbHMgZm9yIHRoZSByb3V0 ZSBwb2xpY3ksIHdlIGFyZTxicj4NCiZndDthd2FyZSB0aGV5IGFyZSBub3QgZmxleGlibGUgZW5v dWdoIGZvciBzb21lIHNjZW5hcmlvcy4gQ291bGQgd2Ugc3RhcnQgdG88YnI+DQomZ3Q7c3RhbmRh cmRpemUgc29tZSBwb2xpY3kgc3BlY2lmaWMgbGFuZ3VhZ2Ugc3VjaCBhcyBSUFNMIHdoaWxlIGRl ZmluZSB0aGU8YnI+DQomZ3Q7WWFuZyBtb2RlbHMgZm9yIHRoZSByb3V0aW5nIHBvbGljeT88YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtSZWdhcmRzLDxicj4NCiZndDtSb2Jpbjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7PC9zcGFuPuWPkeS7 tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46IFJ0Zy15YW5nLWNvb3JkIFs8YSBocmVmPSJtYWlsdG86 cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy15YW5n LWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPuS7o+ihqDxzcGFuIGxhbmc9IkVO LVVTIj4gU3VzYW4gSGFyZXM8YnI+DQomZ3Q7WzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5j b20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+XTxicj4NCiZndDs8L3NwYW4+ 5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjogMjAxNDwvc3Bhbj7lubQ8c3BhbiBsYW5n PSJFTi1VUyI+MTI8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIwPC9zcGFuPuaXpTxzcGFu IGxhbmc9IkVOLVVTIj4gNzowOTxicj4NCiZndDs8L3NwYW4+5pS25Lu25Lq6PHNwYW4gbGFuZz0i RU4tVVMiPjogJ0plZmYgVGFudHN1cmEnOyAnQWNlZSBMaW5kZW0gKGFjZWUpJzs8YnI+DQomZ3Q7 PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9i bGFuayI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+OyAnUm9iZXJ0IFJhc3p1ayc8 YnI+DQomZ3Q7PC9zcGFuPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46IDxhIGhyZWY9Im1haWx0 bzpydGcteWFuZy1jb29yZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLXlhbmctY29v cmRAaWV0Zi5vcmc8L2E+OyAnRGVhbiBCb2dkYW5vdmljJzsgJ0xhZGlzbGF2IExob3RrYSc8YnI+ DQomZ3Q7PC9zcGFuPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46IFJlOiBbUnRnLXlhbmctY29v cmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnM8YnI+DQomZ3Q7PGJyPg0KJmd0O1N0ZXBoZW46 PGJyPg0KJmd0Ozxicj4NCiZndDtJIGFtIGludGVyZXN0ZWQuJm5ic3A7IFdlIGhhdmluZyByb3V0 aW5nIHBvbGljeSBkaXNjdXNzaW9uIGluIEkyUlMgcmVsYXRpbmcgUEJSPGJyPg0KJmd0O2FuZCBw b2xpY3kuJm5ic3A7IEl0IG5lZWRzIHRvIGxpbmsgdG8gYSBiYXNlIHNwZWNpZmljYXRpb24uPGJy Pg0KJmd0Ozxicj4NCiZndDtTdWU8YnI+DQomZ3Q7PGJyPg0KJmd0Oy0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KJmd0O0Zyb206IFJ0Zy15YW5nLWNvb3JkIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5y dGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mPGJyPg0KJmd0 O0plZmYgVGFudHN1cmE8YnI+DQomZ3Q7U2VudDogRnJpZGF5LCBEZWNlbWJlciAxOSwgMjAxNCA0 OjM2IFBNPGJyPg0KJmd0O1RvOiBBY2VlIExpbmRlbSAoYWNlZSk7IDxhIGhyZWY9Im1haWx0bzpz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0Kc3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb208L2E+OyBSb2JlcnQgUmFzenVrPGJyPg0KJmd0O0NjOiA8YSBo cmVmPSJtYWlsdG86cnRnLXlhbmctY29vcmRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGct eWFuZy1jb29yZEBpZXRmLm9yZzwvYT47IERlYW4gQm9nZGFub3ZpYzsgTGFkaXNsYXYgTGhvdGth PGJyPg0KJmd0O1N1YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIGlzc3VlIDpSMDE6IHJvdXRl IGZpbHRlcnM8YnI+DQomZ3Q7PGJyPg0KJmd0O0nigJlkIGxpa2UgdG8gYmUgaW52b2x2ZWQsIGFz IHdlbGwgYXMgZ2l2aW5nIGl0IGEgaG9tZSBpbiBydGd3Zzxicj4NCiZndDs8YnI+DQomZ3Q7Q2hl ZXJzLDxicj4NCiZndDtKZWZmPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7T24gMTIvMTkvMTQsIDc6MDAgQU0sICZxdW90OzxhIGhyZWY9Im1h aWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZxdW90Ozxicj4NCiZndDsmZ3Q7Jmx0OzxhIGhy ZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDtBbmQgcXVlc3Rpb24gOiBXaG8gaXMgaW50ZXJlc3RlZCB0byBz dGFydCBub3cgdGhlIHdvcmsgb24gc3RhbmRhcmQ8YnI+DQomZ3Q7Jmd0OyZndDtyb3V0aW5nIHBv bGljeSA/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDtGcm9tOiBSdGct eWFuZy1jb29yZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9y ZzwvYT5dIE9uPGJyPg0KJmd0OyZndDsmZ3Q7QmVoYWxmIE9mIDxhIGhyZWY9Im1haWx0bzpzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsmZ3Q7Jmd0O1NlbnQ6IEZyaWRheSwgRGVjZW1i ZXIgMTksIDIwMTQgMTI6NTk8YnI+DQomZ3Q7Jmd0OyZndDtUbzogUm9iZXJ0IFJhc3p1azxicj4N CiZndDsmZ3Q7Jmd0O0NjOiA8YSBocmVmPSJtYWlsdG86cnRnLXlhbmctY29vcmRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5ydGcteWFuZy1jb29yZEBpZXRmLm9yZzwvYT47IEFjZWUgTGluZGVt IChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOyBKZWZmPGJyPg0KJmd0OyZndDsmZ3Q7VGFudHN1cmE7 IExhZGlzbGF2IExob3RrYTxicj4NCiZndDsmZ3Q7Jmd0O1N1YmplY3Q6IFJlOiBbUnRnLXlhbmct Y29vcmRdIGlzc3VlIDpSMDE6IHJvdXRlIGZpbHRlcnM8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDtSb2JlcnQsPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7WW91 IGFyZSB0b3VjaGluZyBhbiBpbnRlcmVzdGluZyBwb2ludCA6KSBJbiBmYWN0IHRoZXJlIGFyZSB0 d28gd2F5cyBvZjxicj4NCiZndDsmZ3Q7Jmd0O3ZpZXdpbmcgdGhpbmtzIDo8YnI+DQomZ3Q7Jmd0 OyZndDstIHNlcnZpY2UgcHJvdmlkZXJzL2N1c3RvbWVycyB3aG8gd291bGQgbGlrZSB0byB1c2Ug b25seSBzdGFuZGFyZDxicj4NCiZndDsmZ3Q7Jmd0O21vZGVscyB0byBmYWNpbGl0YXRlIG5ldHdv cmsgcHJvdmlzaW9uICZhbXA7IG9wZXJhdGlvbjxicj4NCiZndDsmZ3Q7Jmd0Oy0gdmVuZG9ycyB3 aG8gbWF5IG5vdCB3YW50IHRvIG1ha2UgZGV2ZWxvcG1lbnQgdG8gaW1wbGVtZW50IG5ldzxicj4N CiZndDsmZ3Q7Jmd0O2ZlYXR1cmVzIHRvIGJlIGNvbXBsaWFudCB3aXRoIGEgc3RhbmRhcmQgeWFu ZyBtb2RlbCZuYnNwOyAoYXMgZGV2IGNvc3Q8YnI+DQomZ3Q7Jmd0OyZndDttb25leSkuIEFzIHlv dSBtZW50aW9uZWQsIG9wZXJhdGlvbiBvZiBib3hlcyBpcyB0b2RheSBhIGtleTxicj4NCiZndDsm Z3Q7Jmd0O2RpZmZlcmVudGlhdG9yIHdoZW4gY2hvb3NpbmcgYSB2ZW5kb3IuPGJyPg0KJmd0OyZn dDsmZ3Q7V2UgY2xlYXJseSB0aGlzIGRpdmVyZ2VuY2UgdG9kYXkgaW4gcHJvZHVjZWQgWWFuZyBt b2RlbCAob3BlcmF0b3I8YnI+DQomZ3Q7Jmd0OyZndDthdXRob3JzIG1vZGVscyB2cyB2ZW5kb3Ig YXV0aG9ycyBtb2RlbCk8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDtBcyBhIHNl cnZpY2UgcHJvdmlkZXIsIEknbSBjbGVhcmx5IHB1c2hpbmcgdG8gdXNlIG9ubHkgc3RhbmRhcmQg bW9kZWw8YnI+DQomZ3Q7Jmd0OyZndDthdCBsZWFzdCBmb3IgbW9zdCBvZiB0aGUgYmFzZSBzdHJ1 Y3R1cmUgb2Ygc2VydmljZXMgYW5kIEkgd2lsbCBwdXNoIG15PGJyPg0KJmd0OyZndDsmZ3Q7dmVu ZG9ycyB0byBzdXBwb3J0IGl0IGFzIG1vcmUgYXMgcG9zc2libGUuIEkgd291bGQgc2F5IHRoYXQg bW9yZSB0aGFuPGJyPg0KJmd0OyZndDsmZ3Q7OTAlIG9mIHBhcmFtZXRlcnMgb2YgYSBzZXJ2aWNl IGFyZSBjb21tb24gdG8gYWxsIGltcGxlbWVudGF0aW9ucyAoanVzdDxicj4NCiZndDsmZ3Q7Jmd0 O2RldGFpbHMgYXJlIGNoYW5naW5nJm5ic3A7IDogbG9jYWxpemF0aW9uIG9mIHRoZSBjb25maWcg c3RhdGVtZW50IG9yPGJyPg0KJmd0OyZndDsmZ3Q7Z3JhbnVsYXJpdHkgb2YgdGhlIHBhcmFtZXRl cikuIFNvIEkgdGhpbmsgdGhhdCBjcmVhdGluZyB1c2FibGU8YnI+DQomZ3Q7Jmd0OyZndDtzdGFu ZGFyZCBtb2RlbCBjYW4gd29yay4gVGhlIHJlbWFpbmluZyB4JSBjYW4gYmUgYWRkcmVzc2VkIGJ5 IHZlbmRvcjxicj4NCiZndDtleHRlbnNpb25zLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0O0NvbWluZyBiYWNrIHRvIHJvdXRpbmcgcG9saWNpZXMuIEkgZG8gdGhpbmsgdGhhdCBy ZXN0YXJ0aW5nIGEgbmV3PGJyPg0KJmd0OyZndDsmZ3Q7ZnJhbWV3b3JrIGZyb20gc3RyYXRjaCBp cyB0aGUgcmlnaHQgd2F5IHRvIGRvIGl0LiBBbmQgYXMgYW55IHByb3RvY29sPGJyPg0KJmd0OyZn dDsmZ3Q7ZXh0ZW5zaW9uIG9yIGZlYXR1cmUgc3RhbmRhcmRpemVkIGluIElFVEYsIGl0IHdpbGwg YmUgdXAgdG8gY3VzdG9tZXJzPGJyPg0KJmd0OyZndDsmZ3Q7dG8gcmVxdWVzdCB0aGVpciB2ZW5k b3JzIGZvciBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7VG9kYXkgcm91dGluZyBwb2xpY3kgbWFuYWdlbWVudCBiZXR3ZWVuIGRpZmZlcmVudCB2ZW5k b3JzIGlzIGNyYXp5Ljxicj4NCiZndDsmZ3Q7Jmd0O0NvbnNpZGVyIHlvdSBoYXZlIGEgVmVuZG9y IFggbmV0d29yayB3aXRoIHdpZGVseSBkZXBsb3llZCBjb21wbGV4PGJyPg0KJmd0OyZndDsmZ3Q7 cm91dGluZyBwb2xpY2llcywgYW5kIHlvdSB3YW50IHRvIGludHJvZHVjZSB0byB2ZW5kb3IgWSwg dHJhbnNsYXRpb248YnI+DQomZ3Q7Jmd0OyZndDtvZiByb3V0aW5nIHBvbGljaWVzIGZyb20gbGFu Z3VhZ2UgWCB0byBZIGlzIGEgdmVyeSBjb21wbGV4IHdvcmsuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7TW9yZW92ZXIgd2UgY2FuIHNlZSB0aGF0IGZyYW1ld29yayBvZiBwb2xp Y3kgbW9kZWwgaXMgYWxyZWFkeSBleGlzdGluZzxicj4NCiZndDsmZ3Q7Jmd0O2ZvciBpbnRlcm5l dCByZWdpc3RyaWVzIHVzaW5nIFJQU0wuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7SSBkbyBub3Qga25vdyB0b2RheSB3aGVyZSB0aGlzIFlhbmcgaW5pdGlhdGl2ZSB3aWxsIGdv IC4uLiBidXQgSSB3aWxsPGJyPg0KJmd0OyZndDsmZ3Q7cHJvbmUgYSBjb25zZW5zdXMgb24gc3Ry b25nIGFkb3B0aW9uIG9mIHN0YW5kYXJkIFlBTkcgbW9kZWxzIHJhdGhlcjxicj4NCiZndDsmZ3Q7 Jmd0O3RoYW4gdmVuZG9yIHNwZWNpZmljIG9ubHkuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7U3RlcGhhbmU8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0O0Zy b206IDxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJy YXN6dWtAZ21haWwuY29tPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJyYXN6dWtAZ21haWwuY29tPC9hPl0gT24gQmVoYWxmIE9m IFJvYmVydDxicj4NCiZndDsmZ3Q7Jmd0O1Jhc3p1azxicj4NCiZndDsmZ3Q7Jmd0O1NlbnQ6IEZy aWRheSwgRGVjZW1iZXIgMTksIDIwMTQgMTE6MTA8YnI+DQomZ3Q7Jmd0OyZndDtUbzogTElUS09X U0tJIFN0ZXBoYW5lIFNDRS9JQk5GPGJyPg0KJmd0OyZndDsmZ3Q7Q2M6IEplZmYgVGFudHN1cmE7 IEFjZWUgTGluZGVtIChhY2VlKTsgRGVhbiBCb2dkYW5vdmljOzxicj4NCiZndDsmZ3Q7Jmd0Ozxh IGhyZWY9Im1haWx0bzpydGcteWFuZy1jb29yZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0 Zy15YW5nLWNvb3JkQGlldGYub3JnPC9hPjsgTGFkaXNsYXYgTGhvdGthPGJyPg0KJmd0OyZndDsm Z3Q7U3ViamVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVy czxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O0hpIFN0ZXBoYW5lLDxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O1RoYXQgaXMgZ29pbmcgdG8gYmUgdmVyeSBpbnRl cmVzdGluZyBpbmRlZWQuIENvbnNpZGVyaW5nIHRoYXQgbnVtYmVyPGJyPg0KJmd0OyZndDsmZ3Q7 b2YgY3VzdG9tZXJzIGhhdmUgcGFpZCB2ZW5kb3JzIG1pbGxpb25zIGZvciBjdXN0b21pemVkIGV4 dGVuc2lvbnMgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7b25seSBzb21lIG9mIHRoZW0gbWFkZSBpdCB0 byBJRVRGIGRyYWZ0cy9yZmNzLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O1Nv IHdoYXQgd2lsbCBtb3N0IGxpa2VseSBoYXBwZW4gaXMgZ2VuZXJhbCBZQU5HIG1vZGVsIG9mIG5v dCBtdWNoIHVzZTxicj4NCiZndDsmZ3Q7Jmd0O2FuZCB6b28gb2YgcHJvcHJpZXRhcnkgdmVuZG9y IFlBTkcgZXh0ZW5zaW9ucyBub3QgY29tcGF0aWJsZSBiZXR3ZWVuPGJyPg0KJmd0OyZndDsmZ3Q7 aW1wbGVtZW50YXRpb25zLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O0lzIHRo aXMgcmVhbGx5IHdoZXJlIHdlIHdhbnQgdG8gZ28gd2l0aCB0aGlzIGVudGlyZSBlZmZvcnQgPzxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O0Jlc3QsPGJyPg0KJmd0OyZndDsmZ3Q7 ci48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDtP biBGcmksIERlYyAxOSwgMjAxNCBhdCAxMTowMyBBTSwmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDt3cm90ZTo8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhpLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IEkgdGhpbmsgd29ya2luZyBvZiBCR1AgWUFORyBpcyBhIGdvb2Qgb3Bwb3J0dW5p dHkgdG8gc3RhcnQgd29ya2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDtvbiBwb2xpY3kgZnJhbWV3 b3JrLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgV29yayBvbiBwcm90b2NvbHMgWUFORyBpcyBhbHJl YWR5IGhhcmQgZHVlIHRvIHZlbmRvciBjb25maWc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ZGlzcHJl Y2FuY2llcywgSSBleHBlY3QgcG9saWN5IHdvcmsgdG8gYmUgbXVjaCBoYXJkZXIgLi4uPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQnV0IEkgdGhpbmssIHRoZXJl IGlzIGFuIG9wcG9ydHVuaXR5IHRvIHN0YXJ0IHNvbWV0aGluZyBuZXcgZm9yPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0O2V2ZXJ5b25lICh0aGF0IG1heSBjb2V4aXN0IHdpdGggZXhpc3RpbmcgQ0xJIHBv bGljaWVzKSBhbmQgbm90PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0O2xvb2tpbmcgYXQgQ0xJIHRyYW5z bGF0aW9uIChpdCB3aWxsIGJlIGltcG9zc2libGUgd2l0aCBwb2xpY2llcykuPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0O1RoZW4gaXQgd291bGQgYmUgdXAgdG8gc2VydmljZSBwcm92aWRlcnMgdG8gcmVx dWVzdCB0aGUgc3VwcG9ydCBvZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDt0aGlzIGJ5IHRoZWlyIGZh dm9yaXRlIHZlbmRvcnMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgQmVzdCBSZWdhcmRzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IFN0ZXBoYW5lPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWls dG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwv YT5dIE9uIEJlaGFsZiBPZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUm9iZXJ0IFJhc3p1azxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNywgMjAxNCAyMzoy ODxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVG86IEplZmYgVGFudHN1cmE8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IENjOiBBY2VlIExpbmRlbSAoYWNlZSk7IERlYW4gQm9nZGFub3ZpYzsgPGEgaHJlZj0i bWFpbHRvOnJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGcteWFu Zy1jb29yZEBpZXRmLm9yZzwvYT47PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBMSVRLT1dTS0kgU3Rl cGhhbmUgU0NFL0lCTkY7IExhZGlzbGF2IExob3RrYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU3Vi amVjdDogUmU6IFtSdGcteWFuZy1jb29yZF0gaXNzdWUgOlIwMTogcm91dGUgZmlsdGVyczxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNvIGFyZSB5b3Ugc2F5aW5n IHRoYXQgZm9ybWFsIFlBTkcgc3BlY2lmaWNhdGlvbiBzYXkgZm9yIEJHUCBieTxicj4NCiZndDsm Z3Q7Jmd0OyZndDtkZXNpZ24gd2lsbCBub3QgYmUgY29tcGF0aWJsZSB3aXRoIHNvbWUgaW1wbGVt ZW50YXRpb25zID88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBP ciBhcmUgeW91IHNheWluZyB0aGF0IGZvcm1hbCBkZXNpZ24gc2F5IG9mIEJHUCBwcm90b2NvbCB3 aWxsIGhhdmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7dG8gd2FpdCBmZXcgeWVhcnMgdGlsbCBZQU5H IGZvciBwb2xpY3kgc3BlYyBpcyBjb21wbGV0ZSA/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgci48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiBXZWQsIERlYyAxNywgMjAx NCBhdCAxMToxNCBQTSwgSmVmZiBUYW50c3VyYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbHQ7PGEg aHJlZj0ibWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBZZXMsIGV4YWN0bHksIFJvYmVydCAtIHRoZSBiZWhhdmlvciB5b3UgaGF2ZSBk ZXNjcmliZWQgaXMgYW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2ltcGxlbWVudGF0aW9uLCBu b3QgYSBmb3JtYWwgc3BlY2lmaWNhdGlvbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg SmVmZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IE9uIERlYyAxNywgMjAxNCwgYXQgMjoxMiBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpICZsdDs8 YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hY2VlQGNpc2Nv LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7d3JvdGU6PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdoeSBp cyB0aGlzIGEgcHJvYmxlbSBpZiB0aGUgZGVmYXVsdCBpcyB0byBub3QgdG8gcmVkaXN0cmlidXRl PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7cm91dGVzIGJldHdlZW4gUklCcz8gTm90ZSB0 aGF0IGl0IGlzbsK5dCBsaWtlIHdlIGhhdmUgYSBzZXQgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDthcHByb3ZlZCByb3V0aW5nIHByb3RvY29sIG1vZGVscyB0aGF0IGFyZSBkZXBlbmRl bnQgb24gdGhpcyBiZWhhdmlvci48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWNlZTxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgT24gRGVjIDE3LCAyMDE0LCBhdCA1OjA3IFBNLCBEZWFuIEJvZ2Rhbm92aWMgJmx0Ozxh IGhyZWY9Im1haWx0bzpkZWFuYkBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmRlYW5iQGp1 bmlwZXIubmV0PC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7d3JvdGU6 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgUm9iZXJ0LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXIgcHJvcG9zYWwgaXMgdmVyeSBzZW5z aWJsZSBhbmQgSSB0aGluayB0aGlzIGlzIHRoZSBiZXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBvcHRpb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEZWFuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIERlYyAx NywgMjAxNCwgYXQgNDo0OSBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv YmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7d3JvdGU6PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBEZWFuLCBhbGw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSB3YXkgSSByZWFkIGl0IGN1 cnJlbnRseSBpbiBzZWN0aW9uIDUuNSB0aGVyZSBhcmUgb25seSB0d288YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O3JvdXRlIGZpbHRlcnMgcHJvcG9zZWQgKGRlbnktYWxsIG9y IGFsbG93LWFsbCkuIEFzIHdlIGtub3cgc29tZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7cm91dGluZyBwcm90b2NvbHMgcmVxdWlyZSBleHBsaWNpdCBwZXJtaXNzaW9uIHRv IG9wZXJhdGUgKGV4YW1wbGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDtF QkdQKS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB3ZSByZW1vdmUg ZXZlbiB0aG9zZSB0d28gcHJpbWl0aXZlIGZpbHRlcnMgdGhlcmUgY2FuIGJlPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDtpbXBhY3QmbmJzcDsgdG8gb3RoZXIgY29tcG9uZW50 cy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJ1dCBJIGRvIHN1cHBvcnQgYSBzZXBhcmF0ZSB3b3JrIGZv ciBZQU5HIG1vZGVsIGZvciBwb2xpY3kuIEkgZG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBleHBlY3QgdGhpcyB0byBiZSBhIHZlcnkgaW50ZXJlc3RpbmcgYW5kIGludm9s dmVkIHdvcms8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25zaWRlcmlu ZyBzaWduaWZpY2FudCBkaXZlcnNpdHkgb2YgcG9saWN5IGxhbmd1YWdlcyBhY3Jvc3MgYWxsPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW1wbGVtZW50YXRpb25zIHRvZGF5 Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT25jZSB0aGF0IHdvcmsgaXMgZG9uZSB3ZSBjb3VsZCByZXRp cmUgc2VjdGlvbiA1LjUgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAq LW5ldG1vZC1yb3V0aW5nLSo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgci48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFdlZCwgRGVjIDE3LCAyMDE0IGF0 IDEwOjA5IFBNLCBEZWFuIEJvZ2Rhbm92aWM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmRlYW5iQGp1bmlwZXIubmV0IiB0YXJnZXQ9 Il9ibGFuayI+ZGVhbmJAanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSdtIGluIHN1cHBvcnQgb2YgcmVtb3Zpbmcgcm91 dGUgZmlsdGVycyBmcm9tIHRoZSByb3V0aW5nIGNmZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0O21vZGVsLiBSb3V0ZSBmaWx0ZXJzIHNob3VsZCBiZSBJTU8gcGFydCBv ZiB0aGUgcG9saWN5IG1vZGVsLCBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0O3doaWNoIGFsc28gQUNMIG1vZGVsIGJlbG9uZ3MgdG9vLiBBY3R1YWxseSwgSSB3b3Vs ZCBhcmd1ZSB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7dGhl IGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZlcnkgc3VpdGFibGUgZm9yIHJvdXRlIGZpbHRlcnMuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERlYW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5SdGcteWFuZy1jb29yZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRnLXlhbmctY29vcmQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQ8L2E+PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IF9fIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9uczxicj4NCiZndDsmZ3Q7Jmd0OyZndDtjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBk aWZmdXNlcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDtwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaTxicj4NCiZndDsmZ3Q7Jmd0OyZndDtxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXM8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0O2FsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0O3ByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0O2JlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXI8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7aGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRo YW5rIHlvdS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0O19fXzxicj4NCiZndDsmZ3Q7 Jmd0O188YnI+DQomZ3Q7Jmd0OyZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O0NlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u czxicj4NCiZndDsmZ3Q7Jmd0O2NvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLDxicj4NCiZndDsmZ3Q7Jmd0O2V4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2U8YnI+DQomZ3Q7Jmd0OyZndDtwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaTxicj4NCiZndDsmZ3Q7Jmd0O3F1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp Ymxlczxicj4NCiZndDsmZ3Q7Jmd0O2QnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZTxicj4NCiZndDsmZ3Q7Jmd0O2FsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yPGJyPg0KJmd0OyZndDsmZ3Q7cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3Q8YnI+DQomZ3Q7Jmd0OyZn dDtiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxi cj4NCiZndDsmZ3Q7Jmd0O0lmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQ8YnI+DQomZ3Q7Jmd0OyZndDtkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPGJyPg0KJmd0OyZndDsmZ3Q7QXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlPGJyPg0KJmd0OyZndDsmZ3Q7YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu PGJyPg0KJmd0OyZndDsmZ3Q7VGhhbmsgeW91Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsmZ3Q7UnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsm Z3Q7PGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlh bmctY29vcmQ8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmZ3Q7Jmd0O19fXzxicj4NCiZndDsmZ3Q7Jmd0O188YnI+DQomZ3Q7Jmd0 OyZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0O0NlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9uczxicj4NCiZndDsmZ3Q7Jmd0 O2NvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBl dHJlIGRpZmZ1c2VzLDxicj4NCiZndDsmZ3Q7Jmd0O2V4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2U8YnI+DQomZ3Q7Jmd0OyZn dDtwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaTxicj4NCiZndDsmZ3Q7Jmd0O3F1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlczxicj4NCiZndDsmZ3Q7 Jmd0O2QnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZTxicj4NCiZndDsmZ3Q7Jmd0O2FsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7VGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yPGJyPg0K Jmd0OyZndDsmZ3Q7cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3OyB0aGV5IHNob3VsZCBub3Q8YnI+DQomZ3Q7Jmd0OyZndDtiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0O0lm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQ8YnI+DQomZ3Q7Jmd0OyZndDtkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuPGJyPg0KJmd0OyZndDsmZ3Q7QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlPGJyPg0KJmd0OyZndDsm Z3Q7YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPGJyPg0KJmd0OyZndDsmZ3Q7 VGhhbmsgeW91Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDtSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJlZj0ibWFpbHRv OlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmctY29vcmRA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkPC9hPjxicj4NCiZndDs8YnI+ DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7UnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0 bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJ0Zy15YW5nLWNvb3Jk QGlldGYub3JnPC9hPjxicj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZDwvYT48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClJ0Zy15 YW5nLWNvb3JkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpSdGcteWFuZy1jb29y ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlh bmctY29vcmQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Zy15YW5nLWNvb3JkPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABA846987ECnkgeml501mbschi_--