From nobody Thu Mar 9 01:09:52 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2E129438 for ; Thu, 9 Mar 2017 01:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lne9WDwvpciN for ; Thu, 9 Mar 2017 01:09:48 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09951293EE for ; Thu, 9 Mar 2017 01:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5737; q=dns/txt; s=iport; t=1489050587; x=1490260187; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=a2D9iNWkuJrQhpmpozI/8Eo7S/HR+LHiqeUfQ/+k+zU=; b=WvB3pduRwI4G5QkfBYZMrkICH01U77aVPiMkj5j/J75/n03DfSL9Ew5d cWoimX8Q7ZsMg94f2inhQpb2+JFTae5Y+qSEx6oe0UAjCiz4hTket2zdg dWrFgl2kVlvzOenVXA/g9ianyXzFzLXDs0THitEGhuLMDbR8UZZuMMhEg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAQARG8FY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYI1sc5A7H5U4gg0fC4V4AoMIGAECAQEBAQEBAWsohRUBAQE?= =?us-ascii?q?BAwEBNhYgCwwECxEDAQEBAQwbBycKFQkIBgEMBgIBARAHAgSJRgMVDrIrim0BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhk6CBQiBWYEJgTyBFYFfBYYEBZw2hnaDIgy?= =?us-ascii?q?IFIF7U4RQgzGGUYhEgm+ICx84gQMiFQgXFRgnhFkIEIFkPzWHVg8XghcBAQE?= X-IronPort-AV: E=Sophos;i="5.36,268,1486425600"; d="scan'208";a="653132394" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 09:09:42 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2999f2j024299; Thu, 9 Mar 2017 09:09:42 GMT To: Jan Lindblad , adrian@olddog.co.uk References: <066b01d28dbd$d30e22a0$792a67e0$@olddog.co.uk> From: Benoit Claise Message-ID: Date: Thu, 9 Mar 2017 10:09:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: l3sm@ietf.org Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 09:09:51 -0000 Dear all, It seems like Jan discovered a bug. Can the authors confirm? Regards, Benoit > A great achievement that I have long awaited, for sure! > > I have some concerns with the resulting model, however, and I now (obviously) regret not looking at this earlier and taking part in the review process. > > At ietf-l3vpn-svc.yang:2053 I find: > > grouping site-devices { > container devices { > must "/l3vpn-svc/sites/site/management/type = "+ > "'provider-managed' or "+ > "/l3vpn-svc/sites/site/management/type = "+ > "'co-managed'" { > description > "Applicable only for provider-managed or co-managed device."; > } > > To me, it appears that the author intended to say that the "container device" configuration is only applicable when the current site management type is 'provider-managed' or 'co-managed'. That would make sense. > > The use of "must" and the use of the absolute paths above changes the meaning in YANG to "as soon as any l3vpn is configured, there must be at least one l3vpn (not necessarily the current one) that is 'provider-managed' or 'co-managed'." One implication would be that it would not be legal to have a collection of only 'customer-managed' vpns. What would be legal, though, is to have one 'provider-managed' l3vpn with no device configuration and another 'customer-managed' with devices configured. I expect this was not the intention. > > This was something I noticed after spending a few minutes reading the model. Perhaps a YANG doctor review would be appropriate? > > Best Regards, > /jan > > > >> On 23 Feb 2017, at 11:15, Adrian Farrel wrote: >> >> Thanks to all of you for helping to complete this work. >> Special thanks (of course) to the authors and contributors. >> And massive thanks to Stephane who was relentless in making the minor edits for >> the many different phases of "final" review. >> >> Adrian >> >>> -----Original Message----- >>> From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of rfc-editor@rfc- >>> editor.org >>> Sent: 23 February 2017 00:26 >>> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org >>> Cc: l3sm@ietf.org; drafts-update-ref@iana.org; rfc-editor@rfc-editor.org >>> Subject: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery >>> >>> A new Request for Comments is now available in online RFC libraries. >>> >>> >>> RFC 8049 >>> >>> Title: YANG Data Model for L3VPN >>> Service Delivery >>> Author: S. Litkowski, L. Tomotaki, K. Ogaki >>> Status: Standards Track >>> Stream: IETF >>> Date: February 2017 >>> Mailbox: stephane.litkowski@orange.com, >>> luis.tomotaki@verizon.com, >>> ke-oogaki@kddi.com >>> Pages: 157 >>> Characters: 272974 >>> Updates/Obsoletes/SeeAlso: None >>> >>> I-D Tag: draft-ietf-l3sm-l3vpn-service-model-19.txt >>> >>> URL: https://www.rfc-editor.org/info/rfc8049 >>> >>> DOI: 10.17487/RFC8049 >>> >>> This document defines a YANG data model that can be used for >>> communication between customers and network operators and to deliver >>> a Layer 3 provider-provisioned VPN service. This document is limited >>> to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This >>> model is intended to be instantiated at the management system to >>> deliver the overall service. It is not a configuration model to be >>> used directly on network elements. This model provides an abstracted >>> view of the Layer 3 IP VPN service configuration components. It will >>> be up to the management system to take this model as input and use >>> specific configuration models to configure the different network >>> elements to deliver the service. How the configuration of network >>> elements is done is out of scope for this document. >>> >>> This document is a product of the L3VPN Service Model Working Group of the >>> IETF. >>> >>> This is now a Proposed Standard. >>> >>> STANDARDS TRACK: This document specifies an Internet Standards Track >>> protocol for the Internet community, and requests discussion and suggestions >>> for improvements. Please refer to the current edition of the Official >>> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the >>> standardization state and status of this protocol. Distribution of this >>> memo is unlimited. >>> >>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>> To subscribe or unsubscribe, see >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>> >>> For searching the RFC series, see https://www.rfc-editor.org/search >>> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >>> >>> Requests for special distribution should be addressed to either the >>> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >>> specifically noted otherwise on the RFC itself, all RFCs are for >>> unlimited distribution. >>> >>> >>> The RFC Editor Team >>> Association Management Solutions, LLC >>> >>> >>> _______________________________________________ >>> L3sm mailing list >>> L3sm@ietf.org >>> https://www.ietf.org/mailman/listinfo/l3sm >> _______________________________________________ >> L3sm mailing list >> L3sm@ietf.org >> https://www.ietf.org/mailman/listinfo/l3sm >> > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm > . > From nobody Thu Mar 9 01:48:12 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7309C1294F6 for ; Thu, 9 Mar 2017 01:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDNr-9ykr3T4 for ; Thu, 9 Mar 2017 01:48:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C12FA127A90 for ; Thu, 9 Mar 2017 01:48:08 -0800 (PST) Received: from [10.61.255.107] (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E8801AE02A7; Thu, 9 Mar 2017 10:48:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jan Lindblad In-Reply-To: Date: Thu, 9 Mar 2017 20:47:57 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com> References: <066b01d28dbd$d30e22a0$792a67e0$@olddog.co.uk> To: Benoit Claise X-Mailer: Apple Mail (2.3259) Archived-At: Cc: l3sm@ietf.org, adrian@olddog.co.uk Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 09:48:10 -0000 Beno=C3=AEt, all, > On 9 Mar 2017, at 20:09, Benoit Claise wrote: >=20 > Dear all, >=20 > It seems like Jan discovered a bug. > Can the authors confirm? Since the issue I found was in a quick scan, I decided to go through the = entire document in a little more ordered fashion. My findings are below. = Issue #1 is what I reported earlier. I am truly sorry I did not go = through the YANG before the release, but there isn't much to do about = that now. I was interested in the final result, so I took a quick look at the = model. Within a couple of minutes I stumbled upon this, which is almost = certainly not what the author had intended. #1) 1995: grouping site-devices /l3vpn-svc/sites/site container devices { must "/l3vpn-svc/sites/site/management/type =3D "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type =3D"+ "'co-managed'" { To me, it appears that the author intended to say that the "container = device" configuration is only applicable when the current site = management type is 'provider-managed' or 'co-managed'. That would make = sense.=20 The use of "must" and the use of the absolute paths above changes the = meaning in YANG to "as soon as any l3vpn is configured, there must be at = least one l3vpn (not necessarily the current one) that is = 'provider-managed' or 'co-managed'." One implication would be that it = would not be legal to have a collection of only 'customer-managed' vpns. = What would be legal, though, is to have one 'provider-managed' l3vpn = with no device configuration and another 'customer-managed' with devices = configured. I expect this was not the intention. I think an expression that reflects the intent would be container devices { when "../management/type =3D "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type =3D"+ "'co-managed'" { This would make the container only exist when the management type of = this site specifically is 'provider-managed' or 'co-managed'. Now I went through the YANG and discovered a couple more similar things, = as well as a slew of optional leafs where the meaning of a non-existent = leaf is undefined.=20 #2) 2011: grouping site-devices /l3vpn-svc/sites/site/devices/device/=20 leaf location { type leafref { path "/l3vpn-svc/sites/site/locations/"+ "location/location-id"; The location and name of the grouping in which 'leaf location' is = defined makes me believe the intent is to only allow pointers to = locations within the current site. Currently this leafref allows = pointing to any location in any site (as well as no reference at all). = If my assumption about the modeler's intent is right, the path should be path "../../../locations/location/location-id"; #3) On line 2019 there is another must statement which wants to be a when, = and the path is a little too liberal, I'd think. 2019: grouping site-devices /l3vpn-svc/sites/site/devices/device container management { must "/l3vpn-svc/sites/site/management/type"+ "=3D 'co-managed'" { I think the modeler's intent should be must "../../../management/type =3D 'co-managed'" { #4) There's probably nothing wrong with this one, but since my confidence in = guessing the modeler's intent is low here, and there are many previous = leafref mistakes in this module, maybe someone should assert that this = is what's intended 2139: grouping site-vpn-policy /l3vpn-svc/sites/site leaf vpn-id { type leafref { path "/l3vpn-svc/vpn-services/vpn-svc/vpn-id"; } #5) Again, my guess is that the modeler would like to allow references to = site-network-access objects from within the current site rather than in = any site. 2395:/l3vpn-svc/sites/site/site-network-accesses/site-network-access = grouping access-vpn-policy leaf vpn-policy-id { type leafref { path "/l3vpn-svc/sites/site/"+ "vpn-policy-list/vpn-policy/"+ "vpn-policy-id"; } If so, the leafref path should be path "../../../vpn-policy-list/vpn-policy/vpn-policy-id"; #6) Assuming I'm right in my suspicion that the current module has errors as = described above, I'd say they are grave enough to require fixing. On a = far lower severity, there are lot's of leafs and choices which are = optional, but declare nothing about any meaning if absent. Probably many = of them should be made mandatory or have a default. Most of the rest = should probably have a sentence or two added to the description. Below I = have collected the line numbers and optional element names where I = honestly don't know what the system would do if left without a value. It = may be that l3vpn experts would know in some cases, but it wouldn't hurt = to spell out. Not fixing these undefined cases limits the interoperability, IMO. 629: leaf nat-enabled 653: choice group-format 757: leaf rp-address 966: choice target-flavor 1149:leaf svc-input-bandwidth 1156:leaf svc-output-bandwidth 1163:leaf svc-mtu 1177:leaf enabled 1194:leaf signalling-type 1237:choice match-type 1272:choice qos-profile 1362:leaf enabled 1367:leaf layer 1382:choice profile 1504:leaf area-address 1509:leaf metric 1526:leaf metric 1550:leaf autonomous-system 1555:leaf-list address-family 1639:leaf-list address-family 1662:leaf-list address-family 1742:leaf provider-address 1747:leaf customer-address 1752:leaf mask 1803:leaf-list server-ip-address 1821:leaf provider-address 1826:leaf customer-address 1831:leaf mask 1850:leaf bfd-enabled 1856:choice holdtime 1979:leaf type 2052:leaf site-vpn-flavor 2087:choice lan 2280:leaf site1 2285:leaf site2 2311:leaf src-site 2316:leaf dst-site 2349:leaf local-sites-role 2406:leaf vpn-id Best Rergards, /jan From nobody Thu Mar 9 04:55:28 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E183129587 for ; Thu, 9 Mar 2017 04:55:27 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvultyVVRPgi for ; Thu, 9 Mar 2017 04:55:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 461FF1295A8 for ; Thu, 9 Mar 2017 04:55:23 -0800 (PST) Received: from localhost (unknown [50.225.114.198]) by mail.tail-f.com (Postfix) with ESMTPSA id 91E161AE02A7; Thu, 9 Mar 2017 13:55:19 +0100 (CET) Date: Thu, 09 Mar 2017 13:55:18 +0100 (CET) Message-Id: <20170309.135518.1376708618323584683.mbj@tail-f.com> To: janl@tail-f.com From: Martin Bjorklund In-Reply-To: <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com> References: <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: bclaise@cisco.com, l3sm@ietf.org, adrian@olddog.co.uk Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:55:27 -0000 Hi, Jan Lindblad wrote: > Beno=EEt, all, > = > > On 9 Mar 2017, at 20:09, Benoit Claise wrote: > > = > > Dear all, > > = > > It seems like Jan discovered a bug. > > Can the authors confirm? I'm not an author, but I agree with Jan. [...] > #1) > = > 1995: grouping site-devices /l3vpn-svc/sites/site > container devices { > must "/l3vpn-svc/sites/site/management/type =3D "+ > "'provider-managed' or "+ > "/l3vpn-svc/sites/site/management/type =3D"+ > "'co-managed'" { > = > To me, it appears that the author intended to say that the "container= > device" configuration is only applicable when the current site > management type is 'provider-managed' or 'co-managed'. That would mak= e > sense. > = > The use of "must" and the use of the absolute paths above changes the= > meaning in YANG to "as soon as any l3vpn is configured, there must be= > at least one l3vpn (not necessarily the current one) that is > 'provider-managed' or 'co-managed'." One implication would be that it= > would not be legal to have a collection of only 'customer-managed' > vpns. What would be legal, though, is to have one 'provider-managed' > l3vpn with no device configuration and another 'customer-managed' wit= h > devices configured. I expect this was not the intention. > = > I think an expression that reflects the intent would be > = > container devices { > when "../management/type =3D "+ > "'provider-managed' or "+ > "/l3vpn-svc/sites/site/management/type =3D"+ > "'co-managed'" { It needs one more modification: container devices { when "../management/type =3D 'provider-managed' or " + "../management/type =3D 'co-managed'" { > This would make the container only exist when the management type of > this site specifically is 'provider-managed' or 'co-managed'. /martin From nobody Thu Mar 16 02:35:49 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF58127241 for ; Thu, 16 Mar 2017 02:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLDjMRdjazcB for ; Thu, 16 Mar 2017 02:35:44 -0700 (PDT) Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6F87612714F for ; Thu, 16 Mar 2017 02:35:44 -0700 (PDT) Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 6B5EAE00B7; Thu, 16 Mar 2017 18:35:43 +0900 (JST) Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Thu, 16 Mar 2017 18:35:43 +0900 Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 450DF30005D; Thu, 16 Mar 2017 18:35:43 +0900 (JST) Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id 39E36300050; Thu, 16 Mar 2017 18:35:43 +0900 (JST) Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v2G9Zgjv030659; Thu, 16 Mar 2017 18:35:43 +0900 Received: from LTMC2152.kddi.com.mid_16064013 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v2G9PfGL017726; Thu, 16 Mar 2017 18:25:41 +0900 X-SA-MID: 16064013 Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Thu, 16 Mar 2017 18:25:41 +0900 From: "Ogaki, Kenichi" To: "'Jan Lindblad'" , "'Benoit Claise'" Cc: , References: <066b01d28dbd$d30e22a0$792a67e0$@olddog.co.uk> <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com> In-Reply-To: <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com> Date: Thu, 16 Mar 2017 18:25:40 +0900 Message-ID: <00e601d29e37$474accc0$d5e06640$@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGw39OCCWIIZre+1Z/L1DpRkz6jgAHWJocKAgLJ7BEC9thSn6Gj46iQ Content-Language: ja X-TM-AS-MML: disable Archived-At: Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 09:35:47 -0000 Hi Jan, All, See comments inline [KO], please. Stephane, Luis, could you correct me if I misunderstand?=20 Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Jan Lindblad Sent: Thursday, March 09, 2017 6:48 PM To: Benoit Claise Cc: l3sm@ietf.org; adrian@olddog.co.uk Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service = Delivery Beno=C3=AEt, all, > On 9 Mar 2017, at 20:09, Benoit Claise wrote: >=20 > Dear all, >=20 > It seems like Jan discovered a bug. > Can the authors confirm? Since the issue I found was in a quick scan, I decided to go through the = entire document in a little more ordered fashion. My findings are below. = Issue #1 is what I reported earlier. I am truly sorry I did not go = through the YANG before the release, but there isn't much to do about = that now. I was interested in the final result, so I took a quick look at the = model. Within a couple of minutes I stumbled upon this, which is almost = certainly not what the author had intended. #1) 1995: grouping site-devices /l3vpn-svc/sites/site container devices { must "/l3vpn-svc/sites/site/management/type =3D "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type =3D"+ "'co-managed'" { To me, it appears that the author intended to say that the "container = device" configuration is only applicable when the current site = management type is 'provider-managed' or 'co-managed'. That would make = sense.=20 The use of "must" and the use of the absolute paths above changes the = meaning in YANG to "as soon as any l3vpn is configured, there must be at = least one l3vpn (not necessarily the current one) that is = 'provider-managed' or 'co-managed'." One implication would be that it = would not be legal to have a collection of only 'customer-managed' vpns. = What would be legal, though, is to have one 'provider-managed' l3vpn = with no device configuration and another 'customer-managed' with devices = configured. I expect this was not the intention. I think an expression that reflects the intent would be container devices { when "../management/type =3D "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type =3D"+ "'co-managed'" { This would make the container only exist when the management type of = this site specifically is 'provider-managed' or 'co-managed'. [KO] Martin's following modification seems correct. > container devices { > when "../management/type =3D 'provider-managed' or " > + "../management/type =3D 'co-managed'" { Now I went through the YANG and discovered a couple more similar things, = as well as a slew of optional leafs where the meaning of a non-existent = leaf is undefined.=20 #2) 2011: grouping site-devices /l3vpn-svc/sites/site/devices/device/=20 leaf location { type leafref { path "/l3vpn-svc/sites/site/locations/"+ "location/location-id"; The location and name of the grouping in which 'leaf location' is = defined makes me believe the intent is to only allow pointers to = locations within the current site. Currently this leafref allows = pointing to any location in any site (as well as no reference at all). = If my assumption about the modeler's intent is right, the path should be path "../../../locations/location/location-id"; [KO] Basically agree. However, a service provider may allow his/her = customer to use two or more l3vpn-svc instances and refer their = parameters from each other. #3) On line 2019 there is another must statement which wants to be a when, = and the path is a little too liberal, I'd think. 2019: grouping site-devices /l3vpn-svc/sites/site/devices/device container management { must "/l3vpn-svc/sites/site/management/type"+ "=3D 'co-managed'" { I think the modeler's intent should be must "../../../management/type =3D 'co-managed'" { [KO] Agree. #4) There's probably nothing wrong with this one, but since my confidence in = guessing the modeler's intent is low here, and there are many previous = leafref mistakes in this module, maybe someone should assert that this = is what's intended 2139: grouping site-vpn-policy /l3vpn-svc/sites/site leaf vpn-id { type leafref { path "/l3vpn-svc/vpn-services/vpn-svc/vpn-id"; } [OK] The current path is correct. Not "vpn-svc", but "vpn-service". #5) Again, my guess is that the modeler would like to allow references to = site-network-access objects from within the current site rather than in = any site. 2395:/l3vpn-svc/sites/site/site-network-accesses/site-network-access = grouping access-vpn-policy leaf vpn-policy-id { type leafref { path "/l3vpn-svc/sites/site/"+ "vpn-policy-list/vpn-policy/"+ "vpn-policy-id"; } If so, the leafref path should be path "../../../vpn-policy-list/vpn-policy/vpn-policy-id"; [KO] We need one more "../" and s/vpn-policy-list/vpn-policies/ . path "../../../../vpn-policies/vpn-policy/vpn-policy-id"; #6) Assuming I'm right in my suspicion that the current module has errors as = described above, I'd say they are grave enough to require fixing. On a = far lower severity, there are lot's of leafs and choices which are = optional, but declare nothing about any meaning if absent. Probably many = of them should be made mandatory or have a default. Most of the rest = should probably have a sentence or two added to the description. Below I = have collected the line numbers and optional element names where I = honestly don't know what the system would do if left without a value. It = may be that l3vpn experts would know in some cases, but it wouldn't hurt = to spell out. Not fixing these undefined cases limits the interoperability, IMO. 629: leaf nat-enabled 653: choice group-format 757: leaf rp-address 966: choice target-flavor 1149:leaf svc-input-bandwidth 1156:leaf svc-output-bandwidth 1163:leaf svc-mtu 1177:leaf enabled 1194:leaf signalling-type 1237:choice match-type 1272:choice qos-profile 1362:leaf enabled 1367:leaf layer 1382:choice profile 1504:leaf area-address 1509:leaf metric 1526:leaf metric 1550:leaf autonomous-system 1555:leaf-list address-family 1639:leaf-list address-family 1662:leaf-list address-family 1742:leaf provider-address 1747:leaf customer-address 1752:leaf mask 1803:leaf-list server-ip-address 1821:leaf provider-address 1826:leaf customer-address 1831:leaf mask 1850:leaf bfd-enabled 1856:choice holdtime 1979:leaf type 2052:leaf site-vpn-flavor 2087:choice lan 2280:leaf site1 2285:leaf site2 2311:leaf src-site 2316:leaf dst-site 2349:leaf local-sites-role 2406:leaf vpn-id Best Rergards, /jan _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm From nobody Thu Mar 16 03:31:29 2017 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9BC127698 for ; Thu, 16 Mar 2017 03:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_b2mUCKgW6E for ; Thu, 16 Mar 2017 03:31:24 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6732412785F for ; Thu, 16 Mar 2017 03:31:24 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 0EB6920478; Thu, 16 Mar 2017 11:31:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id BD2F11A0076; Thu, 16 Mar 2017 11:31:22 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0319.002; Thu, 16 Mar 2017 11:31:22 +0100 From: To: "Ogaki, Kenichi" , 'Jan Lindblad' , 'Benoit Claise' CC: "l3sm@ietf.org" , "adrian@olddog.co.uk" Thread-Topic: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery Thread-Index: AdKNvXn61ktCgLtlTmqZK3F2acEsSwD6n5oAAcEiG4AAAVYhgAFfQv8AAARIADA= Date: Thu, 16 Mar 2017 10:31:21 +0000 Message-ID: <3764_1489660282_58CA697A_3764_562_1_9E32478DFA9976438E7A22F69B08FF921DD40EF4@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <066b01d28dbd$d30e22a0$792a67e0$@olddog.co.uk> <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com> <00e601d29e37$474accc0$d5e06640$@kddi.com> In-Reply-To: <00e601d29e37$474accc0$d5e06640$@kddi.com> 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 Archived-At: Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:31:27 -0000 SGksDQoNClBscyBmaW5kIGlubGluZSBjb21tZW50cy4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE9nYWtpLCBLZW5pY2hpDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTYsIDIwMTcgMTA6 MjYNClRvOiAnSmFuIExpbmRibGFkJzsgJ0Jlbm9pdCBDbGFpc2UnDQpDYzogbDNzbUBpZXRmLm9y ZzsgYWRyaWFuQG9sZGRvZy5jby51aw0KU3ViamVjdDogUmU6IFtMM3NtXSBSRkMgODA0OSBvbiBZ QU5HIERhdGEgTW9kZWwgZm9yIEwzVlBOIFNlcnZpY2UgRGVsaXZlcnkNCg0KSGkgSmFuLCBBbGws DQoNClNlZSBjb21tZW50cyBpbmxpbmUgW0tPXSwgcGxlYXNlLg0KU3RlcGhhbmUsIEx1aXMsIGNv dWxkIHlvdSBjb3JyZWN0IG1lIGlmIEkgbWlzdW5kZXJzdGFuZD8gDQoNClRoYW5rcywNCktlbmlj aGkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwzc20gW21haWx0bzpsM3Nt LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW4gTGluZGJsYWQNClNlbnQ6IFRodXJz ZGF5LCBNYXJjaCAwOSwgMjAxNyA2OjQ4IFBNDQpUbzogQmVub2l0IENsYWlzZQ0KQ2M6IGwzc21A aWV0Zi5vcmc7IGFkcmlhbkBvbGRkb2cuY28udWsNClN1YmplY3Q6IFJlOiBbTDNzbV0gUkZDIDgw NDkgb24gWUFORyBEYXRhIE1vZGVsIGZvciBMM1ZQTiBTZXJ2aWNlIERlbGl2ZXJ5DQoNCkJlbm/D rnQsIGFsbCwNCg0KPiBPbiA5IE1hciAyMDE3LCBhdCAyMDowOSwgQmVub2l0IENsYWlzZSA8YmNs YWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gRGVhciBhbGwsDQo+IA0KPiBJdCBzZWVtcyBs aWtlIEphbiBkaXNjb3ZlcmVkIGEgYnVnLg0KPiBDYW4gdGhlIGF1dGhvcnMgY29uZmlybT8NCg0K U2luY2UgdGhlIGlzc3VlIEkgZm91bmQgd2FzIGluIGEgcXVpY2sgc2NhbiwgSSBkZWNpZGVkIHRv IGdvIHRocm91Z2ggdGhlIGVudGlyZSBkb2N1bWVudCBpbiBhIGxpdHRsZSBtb3JlIG9yZGVyZWQg ZmFzaGlvbi4gTXkgZmluZGluZ3MgYXJlIGJlbG93LiBJc3N1ZSAjMSBpcyB3aGF0IEkgcmVwb3J0 ZWQgZWFybGllci4gSSBhbSB0cnVseSBzb3JyeSBJIGRpZCBub3QgZ28gdGhyb3VnaCB0aGUgWUFO RyBiZWZvcmUgdGhlIHJlbGVhc2UsIGJ1dCB0aGVyZSBpc24ndCBtdWNoIHRvIGRvIGFib3V0IHRo YXQgbm93Lg0KDQoNCkkgd2FzIGludGVyZXN0ZWQgaW4gdGhlIGZpbmFsIHJlc3VsdCwgc28gSSB0 b29rIGEgcXVpY2sgbG9vayBhdCB0aGUgbW9kZWwuIFdpdGhpbiBhIGNvdXBsZSBvZiBtaW51dGVz IEkgc3R1bWJsZWQgdXBvbiB0aGlzLCB3aGljaCBpcyBhbG1vc3QgY2VydGFpbmx5IG5vdCB3aGF0 IHRoZSBhdXRob3IgaGFkIGludGVuZGVkLg0KDQojMSkNCg0KMTk5NTogZ3JvdXBpbmcgc2l0ZS1k ZXZpY2VzIC9sM3Zwbi1zdmMvc2l0ZXMvc2l0ZQ0KICBjb250YWluZXIgZGV2aWNlcyB7DQogICBt dXN0ICIvbDN2cG4tc3ZjL3NpdGVzL3NpdGUvbWFuYWdlbWVudC90eXBlID0gIisNCiAgICAiJ3By b3ZpZGVyLW1hbmFnZWQnIG9yICIrDQogICAgIi9sM3Zwbi1zdmMvc2l0ZXMvc2l0ZS9tYW5hZ2Vt ZW50L3R5cGUgPSIrDQogICAgIidjby1tYW5hZ2VkJyIgew0KDQpUbyBtZSwgaXQgYXBwZWFycyB0 aGF0IHRoZSBhdXRob3IgaW50ZW5kZWQgdG8gc2F5IHRoYXQgdGhlICJjb250YWluZXIgZGV2aWNl IiBjb25maWd1cmF0aW9uIGlzIG9ubHkgYXBwbGljYWJsZSB3aGVuIHRoZSBjdXJyZW50IHNpdGUg bWFuYWdlbWVudCB0eXBlIGlzICdwcm92aWRlci1tYW5hZ2VkJyBvciAnY28tbWFuYWdlZCcuIFRo YXQgd291bGQgbWFrZSBzZW5zZS4gDQoNClRoZSB1c2Ugb2YgIm11c3QiIGFuZCB0aGUgdXNlIG9m IHRoZSBhYnNvbHV0ZSBwYXRocyBhYm92ZSBjaGFuZ2VzIHRoZSBtZWFuaW5nIGluIFlBTkcgdG8g ImFzIHNvb24gYXMgYW55IGwzdnBuIGlzIGNvbmZpZ3VyZWQsIHRoZXJlIG11c3QgYmUgYXQgbGVh c3Qgb25lIGwzdnBuIChub3QgbmVjZXNzYXJpbHkgdGhlIGN1cnJlbnQgb25lKSB0aGF0IGlzICdw cm92aWRlci1tYW5hZ2VkJyBvciAnY28tbWFuYWdlZCcuIiBPbmUgaW1wbGljYXRpb24gd291bGQg YmUgdGhhdCBpdCB3b3VsZCBub3QgYmUgbGVnYWwgdG8gaGF2ZSBhIGNvbGxlY3Rpb24gb2Ygb25s eSAnY3VzdG9tZXItbWFuYWdlZCcgdnBucy4gV2hhdCB3b3VsZCBiZSBsZWdhbCwgdGhvdWdoLCBp cyB0byBoYXZlIG9uZSAncHJvdmlkZXItbWFuYWdlZCcgbDN2cG4gd2l0aCBubyBkZXZpY2UgY29u ZmlndXJhdGlvbiBhbmQgYW5vdGhlciAnY3VzdG9tZXItbWFuYWdlZCcgd2l0aCBkZXZpY2VzIGNv bmZpZ3VyZWQuIEkgZXhwZWN0IHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50aW9uLg0KDQpJIHRoaW5r IGFuIGV4cHJlc3Npb24gdGhhdCByZWZsZWN0cyB0aGUgaW50ZW50IHdvdWxkIGJlDQoNCiAgY29u dGFpbmVyIGRldmljZXMgew0KICAgd2hlbiAiLi4vbWFuYWdlbWVudC90eXBlID0gIisNCiAgICAi J3Byb3ZpZGVyLW1hbmFnZWQnIG9yICIrDQogICAgIi9sM3Zwbi1zdmMvc2l0ZXMvc2l0ZS9tYW5h Z2VtZW50L3R5cGUgPSIrDQogICAgIidjby1tYW5hZ2VkJyIgew0KDQpUaGlzIHdvdWxkIG1ha2Ug dGhlIGNvbnRhaW5lciBvbmx5IGV4aXN0IHdoZW4gdGhlIG1hbmFnZW1lbnQgdHlwZSBvZiB0aGlz IHNpdGUgc3BlY2lmaWNhbGx5IGlzICdwcm92aWRlci1tYW5hZ2VkJyBvciAnY28tbWFuYWdlZCcu DQoNCltLT10gTWFydGluJ3MgZm9sbG93aW5nIG1vZGlmaWNhdGlvbiBzZWVtcyBjb3JyZWN0Lg0K W1NMSV0gSSBhbHNvIGFncmVlIHdpdGggTWFydGluJ3MgcHJvcG9zYWwuDQoNCj4gICBjb250YWlu ZXIgZGV2aWNlcyB7DQo+ICAgIHdoZW4gIi4uL21hbmFnZW1lbnQvdHlwZSA9ICdwcm92aWRlci1t YW5hZ2VkJyBvciAiDQo+ICAgICAgICsgIi4uL21hbmFnZW1lbnQvdHlwZSA9ICdjby1tYW5hZ2Vk JyIgew0KDQoNCk5vdyBJIHdlbnQgdGhyb3VnaCB0aGUgWUFORyBhbmQgZGlzY292ZXJlZCBhIGNv dXBsZSBtb3JlIHNpbWlsYXIgdGhpbmdzLCBhcyB3ZWxsIGFzIGEgc2xldyBvZiBvcHRpb25hbCBs ZWFmcyB3aGVyZSB0aGUgbWVhbmluZyBvZiBhIG5vbi1leGlzdGVudCBsZWFmIGlzIHVuZGVmaW5l ZC4gDQoNCiMyKQ0KDQoyMDExOiBncm91cGluZyBzaXRlLWRldmljZXMgL2wzdnBuLXN2Yy9zaXRl cy9zaXRlL2RldmljZXMvZGV2aWNlLyANCiAgICBsZWFmIGxvY2F0aW9uIHsNCiAgICAgdHlwZSBs ZWFmcmVmIHsNCiAgICAgIHBhdGggIi9sM3Zwbi1zdmMvc2l0ZXMvc2l0ZS9sb2NhdGlvbnMvIisN CiAgICAgICAibG9jYXRpb24vbG9jYXRpb24taWQiOw0KDQpUaGUgbG9jYXRpb24gYW5kIG5hbWUg b2YgdGhlIGdyb3VwaW5nIGluIHdoaWNoICdsZWFmIGxvY2F0aW9uJyBpcyBkZWZpbmVkIG1ha2Vz IG1lIGJlbGlldmUgdGhlIGludGVudCBpcyB0byBvbmx5IGFsbG93IHBvaW50ZXJzIHRvIGxvY2F0 aW9ucyB3aXRoaW4gdGhlIGN1cnJlbnQgc2l0ZS4gQ3VycmVudGx5IHRoaXMgbGVhZnJlZiBhbGxv d3MgcG9pbnRpbmcgdG8gYW55IGxvY2F0aW9uIGluIGFueSBzaXRlIChhcyB3ZWxsIGFzIG5vIHJl ZmVyZW5jZSBhdCBhbGwpLiBJZiBteSBhc3N1bXB0aW9uIGFib3V0IHRoZSBtb2RlbGVyJ3MgaW50 ZW50IGlzIHJpZ2h0LCB0aGUgcGF0aCBzaG91bGQgYmUNCg0KICAgICAgcGF0aCAiLi4vLi4vLi4v bG9jYXRpb25zL2xvY2F0aW9uL2xvY2F0aW9uLWlkIjsNCg0KW0tPXSBCYXNpY2FsbHkgYWdyZWUu IEhvd2V2ZXIsIGEgc2VydmljZSBwcm92aWRlciBtYXkgYWxsb3cgaGlzL2hlciBjdXN0b21lciB0 byB1c2UgdHdvIG9yIG1vcmUgbDN2cG4tc3ZjIGluc3RhbmNlcyBhbmQgcmVmZXIgdGhlaXIgcGFy YW1ldGVycyBmcm9tIGVhY2ggb3RoZXIuDQoNCltTTEldIEkgd291bGQgdGVuZCB0byBsaW1pdCB0 byB0aGUgb2JqZWN0cyBjcmVhdGVkIGluIHRoZSBjdXJyZW50IHNpdGUuDQoNCg0KIzMpDQoNCk9u IGxpbmUgMjAxOSB0aGVyZSBpcyBhbm90aGVyIG11c3Qgc3RhdGVtZW50IHdoaWNoIHdhbnRzIHRv IGJlIGEgd2hlbiwgYW5kIHRoZSBwYXRoIGlzIGEgbGl0dGxlIHRvbyBsaWJlcmFsLCBJJ2QgdGhp bmsuDQoNCjIwMTk6IGdyb3VwaW5nIHNpdGUtZGV2aWNlcyAvbDN2cG4tc3ZjL3NpdGVzL3NpdGUv ZGV2aWNlcy9kZXZpY2UNCiAgICBjb250YWluZXIgbWFuYWdlbWVudCB7DQogICAgIG11c3QgIi9s M3Zwbi1zdmMvc2l0ZXMvc2l0ZS9tYW5hZ2VtZW50L3R5cGUiKw0KICAgICAgIj0gJ2NvLW1hbmFn ZWQnIiB7DQoNCkkgdGhpbmsgdGhlIG1vZGVsZXIncyBpbnRlbnQgc2hvdWxkIGJlDQoNCiAgICAg bXVzdCAiLi4vLi4vLi4vbWFuYWdlbWVudC90eXBlID0gJ2NvLW1hbmFnZWQnIiB7DQoNCltLT10g QWdyZWUuDQpbU0xJXSBBZ3JlZS4NCg0KDQojNCkNCg0KVGhlcmUncyBwcm9iYWJseSBub3RoaW5n IHdyb25nIHdpdGggdGhpcyBvbmUsIGJ1dCBzaW5jZSBteSBjb25maWRlbmNlIGluIGd1ZXNzaW5n IHRoZSBtb2RlbGVyJ3MgaW50ZW50IGlzIGxvdyBoZXJlLCBhbmQgdGhlcmUgYXJlIG1hbnkgcHJl dmlvdXMgbGVhZnJlZiBtaXN0YWtlcyBpbiB0aGlzIG1vZHVsZSwgbWF5YmUgc29tZW9uZSBzaG91 bGQgYXNzZXJ0IHRoYXQgdGhpcyBpcyB3aGF0J3MgaW50ZW5kZWQNCg0KMjEzOTogZ3JvdXBpbmcg c2l0ZS12cG4tcG9saWN5IC9sM3Zwbi1zdmMvc2l0ZXMvc2l0ZQ0KICAgICAgbGVhZiB2cG4taWQg ew0KICAgICAgIHR5cGUgbGVhZnJlZiB7DQogICAgICAgIHBhdGggIi9sM3Zwbi1zdmMvdnBuLXNl cnZpY2VzL3Zwbi1zdmMvdnBuLWlkIjsNCiAgICAgICB9DQoNCltPS10gVGhlIGN1cnJlbnQgcGF0 aCBpcyBjb3JyZWN0LiBOb3QgInZwbi1zdmMiLCBidXQgInZwbi1zZXJ2aWNlIi4NCg0KIzUpDQoN CkFnYWluLCBteSBndWVzcyBpcyB0aGF0IHRoZSBtb2RlbGVyIHdvdWxkIGxpa2UgdG8gYWxsb3cg cmVmZXJlbmNlcyB0byBzaXRlLW5ldHdvcmstYWNjZXNzIG9iamVjdHMgZnJvbSB3aXRoaW4gdGhl IGN1cnJlbnQgc2l0ZSByYXRoZXIgdGhhbiBpbiBhbnkgc2l0ZS4NCg0KMjM5NTovbDN2cG4tc3Zj L3NpdGVzL3NpdGUvc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzL3NpdGUtbmV0d29yay1hY2Nlc3MgZ3Jv dXBpbmcgYWNjZXNzLXZwbi1wb2xpY3kNCiAgICAgbGVhZiB2cG4tcG9saWN5LWlkIHsNCiAgICAg IHR5cGUgbGVhZnJlZiB7DQogICAgICAgcGF0aCAiL2wzdnBuLXN2Yy9zaXRlcy9zaXRlLyIrDQog ICAgICAgInZwbi1wb2xpY3ktbGlzdC92cG4tcG9saWN5LyIrDQogICAgICAgInZwbi1wb2xpY3kt aWQiOw0KICAgICAgfQ0KDQpJZiBzbywgdGhlIGxlYWZyZWYgcGF0aCBzaG91bGQgYmUNCg0KICAg ICAgIHBhdGggIi4uLy4uLy4uL3Zwbi1wb2xpY3ktbGlzdC92cG4tcG9saWN5L3Zwbi1wb2xpY3kt aWQiOw0KDQpbS09dIFdlIG5lZWQgb25lIG1vcmUgIi4uLyIgYW5kIHMvdnBuLXBvbGljeS1saXN0 L3Zwbi1wb2xpY2llcy8gLg0KICAgICAgIHBhdGggIi4uLy4uLy4uLy4uL3Zwbi1wb2xpY2llcy92 cG4tcG9saWN5L3Zwbi1wb2xpY3ktaWQiOw0KDQoNCiM2KQ0KDQpBc3N1bWluZyBJJ20gcmlnaHQg aW4gbXkgc3VzcGljaW9uIHRoYXQgdGhlIGN1cnJlbnQgbW9kdWxlIGhhcyBlcnJvcnMgYXMgZGVz Y3JpYmVkIGFib3ZlLCBJJ2Qgc2F5IHRoZXkgYXJlIGdyYXZlIGVub3VnaCB0byByZXF1aXJlIGZp eGluZy4gT24gYSBmYXIgbG93ZXIgc2V2ZXJpdHksIHRoZXJlIGFyZSBsb3QncyBvZiBsZWFmcyBh bmQgY2hvaWNlcyB3aGljaCBhcmUgb3B0aW9uYWwsIGJ1dCBkZWNsYXJlIG5vdGhpbmcgYWJvdXQg YW55IG1lYW5pbmcgaWYgYWJzZW50LiBQcm9iYWJseSBtYW55IG9mIHRoZW0gc2hvdWxkIGJlIG1h ZGUgbWFuZGF0b3J5IG9yIGhhdmUgYSBkZWZhdWx0LiBNb3N0IG9mIHRoZSByZXN0IHNob3VsZCBw cm9iYWJseSBoYXZlIGEgc2VudGVuY2Ugb3IgdHdvIGFkZGVkIHRvIHRoZSBkZXNjcmlwdGlvbi4g QmVsb3cgSSBoYXZlIGNvbGxlY3RlZCB0aGUgbGluZSBudW1iZXJzIGFuZCBvcHRpb25hbCBlbGVt ZW50IG5hbWVzIHdoZXJlIEkgaG9uZXN0bHkgZG9uJ3Qga25vdyB3aGF0IHRoZSBzeXN0ZW0gd291 bGQgZG8gaWYgbGVmdCB3aXRob3V0IGEgdmFsdWUuIEl0IG1heSBiZSB0aGF0IGwzdnBuIGV4cGVy dHMgd291bGQga25vdyBpbiBzb21lIGNhc2VzLCBidXQgaXQgd291bGRuJ3QgaHVydCB0byBzcGVs bCBvdXQuDQoNCk5vdCBmaXhpbmcgdGhlc2UgdW5kZWZpbmVkIGNhc2VzIGxpbWl0cyB0aGUgaW50 ZXJvcGVyYWJpbGl0eSwgSU1PLg0KDQo2Mjk6IGxlYWYgbmF0LWVuYWJsZWQNCjY1MzogY2hvaWNl IGdyb3VwLWZvcm1hdA0KNzU3OiBsZWFmIHJwLWFkZHJlc3MNCjk2NjogY2hvaWNlIHRhcmdldC1m bGF2b3INCjExNDk6bGVhZiBzdmMtaW5wdXQtYmFuZHdpZHRoDQoxMTU2OmxlYWYgc3ZjLW91dHB1 dC1iYW5kd2lkdGgNCjExNjM6bGVhZiBzdmMtbXR1DQoxMTc3OmxlYWYgZW5hYmxlZA0KMTE5NDps ZWFmIHNpZ25hbGxpbmctdHlwZQ0KMTIzNzpjaG9pY2UgbWF0Y2gtdHlwZQ0KMTI3MjpjaG9pY2Ug cW9zLXByb2ZpbGUNCjEzNjI6bGVhZiBlbmFibGVkDQoxMzY3OmxlYWYgbGF5ZXINCjEzODI6Y2hv aWNlIHByb2ZpbGUNCjE1MDQ6bGVhZiBhcmVhLWFkZHJlc3MNCjE1MDk6bGVhZiBtZXRyaWMNCjE1 MjY6bGVhZiBtZXRyaWMNCjE1NTA6bGVhZiBhdXRvbm9tb3VzLXN5c3RlbQ0KMTU1NTpsZWFmLWxp c3QgYWRkcmVzcy1mYW1pbHkNCjE2Mzk6bGVhZi1saXN0IGFkZHJlc3MtZmFtaWx5DQoxNjYyOmxl YWYtbGlzdCBhZGRyZXNzLWZhbWlseQ0KMTc0MjpsZWFmIHByb3ZpZGVyLWFkZHJlc3MNCjE3NDc6 bGVhZiBjdXN0b21lci1hZGRyZXNzDQoxNzUyOmxlYWYgbWFzaw0KMTgwMzpsZWFmLWxpc3Qgc2Vy dmVyLWlwLWFkZHJlc3MNCjE4MjE6bGVhZiBwcm92aWRlci1hZGRyZXNzDQoxODI2OmxlYWYgY3Vz dG9tZXItYWRkcmVzcw0KMTgzMTpsZWFmIG1hc2sNCjE4NTA6bGVhZiBiZmQtZW5hYmxlZA0KMTg1 NjpjaG9pY2UgaG9sZHRpbWUNCjE5Nzk6bGVhZiB0eXBlDQoyMDUyOmxlYWYgc2l0ZS12cG4tZmxh dm9yDQoyMDg3OmNob2ljZSBsYW4NCjIyODA6bGVhZiBzaXRlMQ0KMjI4NTpsZWFmIHNpdGUyDQoy MzExOmxlYWYgc3JjLXNpdGUNCjIzMTY6bGVhZiBkc3Qtc2l0ZQ0KMjM0OTpsZWFmIGxvY2FsLXNp dGVzLXJvbGUNCjI0MDY6bGVhZiB2cG4taWQNCg0KDQpCZXN0IFJlcmdhcmRzLA0KL2phbg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDNzbSBtYWls aW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbDNzbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KTDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbDNzbQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK