From nobody Wed Feb 1 10:52:36 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010A5129CF8 for ; Wed, 1 Feb 2017 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFN2pvw5LzYU for ; Wed, 1 Feb 2017 10:52:34 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id E27C81299CF for ; Wed, 1 Feb 2017 10:52:33 -0800 (PST) Received: (qmail 26927 invoked by uid 0); 1 Feb 2017 18:52:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 1 Feb 2017 18:52:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id fWsW1u0022SSUrH01WsZuk; Wed, 01 Feb 2017 11:52:33 -0700 X-Authority-Analysis: v=2.1 cv=Pets2ERd c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=VOGsxCTCnHIYc-wvRSIA:9 a=LhFD-miZbwfbStzQ:21 a=4VONkCWjbhdCttwv:21 a=pILNOxqGKmIA:10 a=iyysGJ9fYZkA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YI6QmJYjBDPATHBIbUzr9YHzBloBEhjw3VaiaahaAeE=; b=xtwOExzzhj+pZXBm4eJDwVgXLh IJfmRLslsrZYqnw7NewtI114y9O+d3AB5ah2awnsHRM85Y/g4CzhVD22ks5oTr0rbpGi+w1FTT2H4 suwlu6ibOHIrhnU9SXxdwmgmF; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:41486 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cZ017-0001M6-Qr; Wed, 01 Feb 2017 11:52:29 -0700 To: Alia Atlas , draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> From: Lou Berger Message-ID: Date: Wed, 1 Feb 2017 13:52:25 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cZ017-0001M6-Qr X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:41486 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 18:52:35 -0000 Juergen, What precludes treating such dependencies in the same way per-provisioning is handled by RFC7223? Lou On 1/25/2017 10:18 AM, Juergen Schoenwaelder wrote: > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote: >> So - if one has models - such as a writable topology - where there >> can be dependencies on dynamic data, then those models can't be in >> the configuration data-store as currently defined. >> > Yes. > > /js > From nobody Wed Feb 1 11:32:43 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF831299B9; Wed, 1 Feb 2017 11:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 JPiffpBmwI1P; Wed, 1 Feb 2017 11:32:38 -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 164681299D3; Wed, 1 Feb 2017 11:32:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6481A6D3; Wed, 1 Feb 2017 20:32:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Og538HjcXe-3; Wed, 1 Feb 2017 20:32:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Feb 2017 20:32:36 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A398200AC; Wed, 1 Feb 2017 20:32:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BA2wDdJqcSSt; Wed, 1 Feb 2017 20:32:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5315200AB; Wed, 1 Feb 2017 20:32:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E41823E62F47; Wed, 1 Feb 2017 20:32:38 +0100 (CET) Date: Wed, 1 Feb 2017 20:32:38 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20170201193238.GA82029@elstar.local> Mail-Followup-To: Lou Berger , Alia Atlas , draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" , Alia Atlas Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 19:32:42 -0000 On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: > Juergen, > > What precludes treating such dependencies in the same way > per-provisioning is handled by RFC7223? > This is fine. But having direct dependencies, e.g., leafrefs from config true leafs to config false leafs, is not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 1 12:57:06 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD21129431 for ; Wed, 1 Feb 2017 12:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSytRGVWD4i0 for ; Wed, 1 Feb 2017 12:57:00 -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 894011299D8 for ; Wed, 1 Feb 2017 12:57:00 -0800 (PST) Received: (qmail 6644 invoked by uid 0); 1 Feb 2017 20:56:58 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 1 Feb 2017 20:56:58 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id fYwu1u00c2SSUrH01Ywx1e; Wed, 01 Feb 2017 13:56:58 -0700 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=c1K9nMj3xSIU8-eVf4cA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=QoSxVNVpRRNeRXzLzuapxKVRw8lQV3awoRQflBdTekQ=; b=TphqvtfdbqaSAaw+NPCcarUKG8 adU4HcF/4BbtbhUooJyfgMrNqwV+3fvJNh34MKSLnxrbQo+IILxtbrq8BYwH3matQ9roU3MlT18k7 Lpy7CAkySVkf1HJ03H5hE18oI; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:43454 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cZ1xW-0002uv-1e; Wed, 01 Feb 2017 13:56:54 -0700 To: Alia Atlas , draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <20170201193238.GA82029@elstar.local> From: Lou Berger Message-ID: <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> Date: Wed, 1 Feb 2017 15:56:49 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170201193238.GA82029@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cZ1xW-0002uv-1e X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:43454 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 20:57:01 -0000 On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote: > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: >> Juergen, >> >> What precludes treating such dependencies in the same way >> per-provisioning is handled by RFC7223? >> > This is fine. But having direct dependencies, e.g., leafrefs from > config true leafs to config false leafs, is not. > > /js > Okay, then we're on the same page -- I think some may have missed the possibility of handling references to dynamic topology information in config using a 'pre-provisioning' approach. Thanks, Lou From nobody Wed Feb 1 13:13:51 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8B912958D; Wed, 1 Feb 2017 13:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL0MTjBDTPUQ; Wed, 1 Feb 2017 13:13:43 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC14F129A16; Wed, 1 Feb 2017 13:13:43 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id u68so75084383ywg.0; Wed, 01 Feb 2017 13:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UMPD0AS2XQFf8wAZKN0b8YIBtdXgsbMrmXxM8QF0K5Q=; b=JNIG4DiFL2VdEoO2Y8nwHpkSYO+A+8COFSldli+Vpa1h8wtyX1lzKOR3VFUcKm51aZ P4MNDpLlfxZE4MeWs92JWgbLmEUmukdtaFx+R/Vphic7lEhFLqoKUwmjNL4nlS5s7Q4s Fc0JQcdRlJ6YRlllEr744TeGT/92EJ/ixHhmwEdXckqPa6nsPyr8eSjx17hx6pQTDI7t inrP26c43XQzNTUNCIzUWZOSDX3OuVTvs6tWblnPXqxhZdEKTSfGoGpFUDniOMZV09wx tDync2b1ay5UK1opWw12t3a2D6OjIc+/rIld1ReCM/To2EckWK+Haki3p1V7A6OeHa/6 PEug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UMPD0AS2XQFf8wAZKN0b8YIBtdXgsbMrmXxM8QF0K5Q=; b=DdeopB8VLUUPRM2mVH/r/DmfyOdSsbFhnUZzAwgR81ELF6W4H8SsxVjL1YFBS5azZO p8lYUd/WsiaQzgv0zmQG/PIU/9Ggqft83v+r6SDiFdfc+TWppKRbliDr7sBvYoanbk3A RxL9uNRE4PbZNMN0XtFkl6wvww74hcV19Qq3Q2mcZUHfNfkJFQkvE0tI3iQF96ejc6+7 IwJH0vJjteMJxiAeI1ezN1DWELIOEBcgyZfXWbrT/m/KA62Utk1L36HH2gEvb7J8i4QO 0W+2vTnBckPxS1/7+ZCwIHMN7jflXLfqCcd6I62HANXvr398hYXwMigK7n6geXHq8ZTR OXrw== X-Gm-Message-State: AIkVDXJjY5/8Ga8oyJyHBa0U/Tt8B2dhAMYDDHT+cxlIlrhLinZQqZ8bV8RCCGwKkirAU0N4gMdinCGb3QP/7A== X-Received: by 10.129.118.4 with SMTP id r4mr3375811ywc.85.1485983622802; Wed, 01 Feb 2017 13:13:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Wed, 1 Feb 2017 13:13:42 -0800 (PST) In-Reply-To: <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <20170201193238.GA82029@elstar.local> <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> From: Alia Atlas Date: Wed, 1 Feb 2017 16:13:42 -0500 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=f403045ef482fab80905477e8517 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, "i2rs@ietf.org" , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:13:45 -0000 --f403045ef482fab80905477e8517 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger wrote: > > > On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote: > > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: > >> Juergen, > >> > >> What precludes treating such dependencies in the same way > >> per-provisioning is handled by RFC7223? > >> > > This is fine. But having direct dependencies, e.g., leafrefs from > > config true leafs to config false leafs, is not. > > > > /js > > > > Okay, then we're on the same page -- I think some may have missed the > possibility of handling references to dynamic topology information in > config using a 'pre-provisioning' approach. > I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this would look like and how it would work for the base topology model, so that the WG can consider all potentially viable options. I'm not certain how it would function for the recursive nature and it does presume the separate /config and /oper-state trees in the data-model that were a concern (though certainly the current recommended approach for YANG models). Regards, Alia --f403045ef482fab80905477e8517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger <lberger@= labn.net> wrote:


On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote:
> On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote:
>> Juergen,
>>
>>=C2=A0 =C2=A0 =C2=A0What precludes treating such dependencies in th= e same way
>> per-provisioning is handled by RFC7223?
>>
> This is fine. But having direct dependencies, e.g., leafrefs from
> config true leafs to config false leafs, is not.
>
> /js
>

Okay, then we're on the same page -- I think some may have misse= d the
possibility of handling references to dynamic topology information in
config using a 'pre-provisioning' approach.
I would be happy to see Alex, Xufeng, Kent & Pavan articul= ate what this would
look like and how it would work for the base = topology model, so that the WG can
consider all potentially viabl= e options.=C2=A0 I'm not certain how it would function for the=C2=A0
recursive nature and it does presume the separate /config and /oper= -state trees in=C2=A0
the data-model that were a concern (though = certainly the current recommended=C2=A0
approach for YANG models)= .

Regards,
Alia=C2=A0
<= /div> --f403045ef482fab80905477e8517-- From nobody Wed Feb 1 14:04:16 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18F12955E; Wed, 1 Feb 2017 14:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.418 X-Spam-Level: X-Spam-Status: No, score=-7.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 nErDRLowNR9Q; Wed, 1 Feb 2017 14:04: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 BCFBC12945C; Wed, 1 Feb 2017 14:04:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFQ14940; Wed, 01 Feb 2017 22:04:09 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 1 Feb 2017 22:04:07 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Wed, 1 Feb 2017 14:04:01 -0800 From: Alexander Clemm To: Alia Atlas , Lou Berger Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/ybSgJ5VGI5EaXm4CY9Zw+S6FJzTqAgAAEUoCAAALgAIALPDiAgAALPACAABeFgIAABLgA//+CeZA= Date: Wed, 1 Feb 2017 22:03:59 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <20170201193238.GA82029@elstar.local> <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.43] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EESJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58925B59.034F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6ff3d7af1302c2899e961bf42b5ae590 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" , "iesg@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:04:15 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EESJCEML703CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgYXJlIHdvcmtpbmcgdGhpcyBzZXBhcmF0ZWx5IGFuZCB3aWxsIGFydGljdWxhdGUgdGhlIGRp ZmZlcmVudCBvcHRpb25zIGFuZCB0aGVpciByZXNwZWN0aXZlIGlzc3Vlcy4NCg0KVGhlIGZ1bmRh bWVudGFsIGlzc3VlIGlzIHN0aWxsIHRoZSBmYWN0IHRoYXQgeW91IG1heSBoYXZlIGRlcGVuZGVu Y2llcyBpbiBvdmVybGF5IHRvcG9sb2dpZXMgb24gdW5kZXJsYXkgdG9wb2xvZ2llcyB0aGF0IGFy ZSBkaXNjb3ZlcmVkIGFuZCByZXByZXNlbnQg4oCcc3RhdGXigJ0sIGFuZCB0aGF0IGluIGZhY3Qg eW91ciB1bmRlcmxheSBtYXkgYmUgZWl0aGVyLg0KDQpSRkMgNzIyMywgYXMgZmFyIGFzIEkgY2Fu IHRlbGwsIHNpZGVzdGVwcyB0aGlzIGlzc3VlLiAgSXQgZG9lcyBkZWZpbmUgYSB0eXBlIOKAnGlu dGVyZmFjZS1yZWbigJ0gd2l0aCBhIHBhdGggdG8gcmVmZXJlbmNlIGEgY29uZmlndXJlZCBpbnRl cmZhY2UsIGFuZCBpdCBkb2VzIGRlZmluZSBhIHR5cGUgIOKAnGludGVyZmFjZS1zdGF0ZS1yZWbi gJ0gdG8gcmVmZXJlbmNlIGFuIG9wZXJhdGlvbmFsbHkgcHJlc2VudCBpbnRlcmZhY2UuICBIb3dl dmVyLCBpbnRlcmZhY2Utc3RhdGUtcmVmIGlzIHVzZWQgb25seSBpbiByZWFkLW9ubHkgb2JqZWN0 cywgd2hlcmVhcyAodG8gcHV0IHRoZSBhbmFsb2d5KSBpdCBpcyBuZWVkZWQgZm9yIGNvbmZpZ3Vy YWJsZSBvYmplY3RzIGFzIHdlbGwuICBMaWtld2lzZSwgdGhlcmUgYXJlIHR3byB0eXBlczsgcmVh bGx5IHdlIG5lZWQgYSB1bmlvbiB3aGljaCB3b3VsZCBhbGxvdyBlaXRoZXIgKG9yIGEgbGVhZnJl ZiB3aXRoIGFsdGVybmF0ZSBwYXRocywgd2hpY2ggaXMgbm90IHN1cHBvcnRlZCkuICBXaGlsZSB0 aGVyZSBhcmUgc29tZSBhbmFsb2dpZXMgd2l0aCBhIHByZXByb3Zpc2lvbmluZyBzY2VuYXJpbywg dGhlcmUgYXJlIGFsc28gZGlmZmVyZW5jZXMuDQoNCkFueXdheSwgWHVmZW5nLCBLZW50LCBQYXZh biBhbmQgSSBhcmUgaGF2aW5nIG9mZmxpbmUgZGlzY3Vzc2lvbnMgYW5kIHdpbGwgY29tZSBiYWNr IHdpdGggZnVydGhlciBlbGFib3JhdGlvbiBvbiB0aGlzLg0KDQotLS0gQWxleA0KDQpGcm9tOiBp MnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxpYSBBdGxh cw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwMSwgMjAxNyAxOjE0IFBNDQpUbzogTG91IEJl cmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCkNjOiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3Bv bG9neUBpZXRmLm9yZzsgaTJyc0BpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtpMnJzXSBLYXRobGVlbiBNb3JpYXJ0eSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWky cnMteWFuZy1sMy10b3BvbG9neS0wODogKHdpdGggQ09NTUVOVCkNCg0KT24gV2VkLCBGZWIgMSwg MjAxNyBhdCAzOjU2IFBNLCBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVy Z2VyQGxhYm4ubmV0Pj4gd3JvdGU6DQoNCg0KT24gMi8xLzIwMTcgMjozMiBQTSwgSnVlcmdlbiBT Y2hvZW53YWVsZGVyIHdyb3RlOg0KPiBPbiBXZWQsIEZlYiAwMSwgMjAxNyBhdCAwMTo1MjoyNVBN IC0wNTAwLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPj4gSnVlcmdlbiwNCj4+DQo+PiAgICAgV2hhdCBw cmVjbHVkZXMgdHJlYXRpbmcgc3VjaCBkZXBlbmRlbmNpZXMgaW4gdGhlIHNhbWUgd2F5DQo+PiBw ZXItcHJvdmlzaW9uaW5nIGlzIGhhbmRsZWQgYnkgUkZDNzIyMz8NCj4+DQo+IFRoaXMgaXMgZmlu ZS4gQnV0IGhhdmluZyBkaXJlY3QgZGVwZW5kZW5jaWVzLCBlLmcuLCBsZWFmcmVmcyBmcm9tDQo+ IGNvbmZpZyB0cnVlIGxlYWZzIHRvIGNvbmZpZyBmYWxzZSBsZWFmcywgaXMgbm90Lg0KPg0KPiAv anMNCj4NCg0KT2theSwgdGhlbiB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlIC0tIEkgdGhpbmsgc29t ZSBtYXkgaGF2ZSBtaXNzZWQgdGhlDQpwb3NzaWJpbGl0eSBvZiBoYW5kbGluZyByZWZlcmVuY2Vz IHRvIGR5bmFtaWMgdG9wb2xvZ3kgaW5mb3JtYXRpb24gaW4NCmNvbmZpZyB1c2luZyBhICdwcmUt cHJvdmlzaW9uaW5nJyBhcHByb2FjaC4NCg0KSSB3b3VsZCBiZSBoYXBweSB0byBzZWUgQWxleCwg WHVmZW5nLCBLZW50ICYgUGF2YW4gYXJ0aWN1bGF0ZSB3aGF0IHRoaXMgd291bGQNCmxvb2sgbGlr ZSBhbmQgaG93IGl0IHdvdWxkIHdvcmsgZm9yIHRoZSBiYXNlIHRvcG9sb2d5IG1vZGVsLCBzbyB0 aGF0IHRoZSBXRyBjYW4NCmNvbnNpZGVyIGFsbCBwb3RlbnRpYWxseSB2aWFibGUgb3B0aW9ucy4g IEknbSBub3QgY2VydGFpbiBob3cgaXQgd291bGQgZnVuY3Rpb24gZm9yIHRoZQ0KcmVjdXJzaXZl IG5hdHVyZSBhbmQgaXQgZG9lcyBwcmVzdW1lIHRoZSBzZXBhcmF0ZSAvY29uZmlnIGFuZCAvb3Bl ci1zdGF0ZSB0cmVlcyBpbg0KdGhlIGRhdGEtbW9kZWwgdGhhdCB3ZXJlIGEgY29uY2VybiAodGhv dWdoIGNlcnRhaW5seSB0aGUgY3VycmVudCByZWNvbW1lbmRlZA0KYXBwcm9hY2ggZm9yIFlBTkcg bW9kZWxzKS4NCg0KUmVnYXJkcywNCkFsaWENCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EESJCEML703CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZSBhcmUgd29ya2luZyB0aGlzIHNlcGFyYXRlbHkgYW5k IHdpbGwgYXJ0aWN1bGF0ZSB0aGUgZGlmZmVyZW50IG9wdGlvbnMgYW5kIHRoZWlyIHJlc3BlY3Rp dmUgaXNzdWVzLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGUgZnVuZGFtZW50YWwgaXNzdWUgaXMgc3RpbGwgdGhlIGZhY3QgdGhhdCB5b3UgbWF5 IGhhdmUgZGVwZW5kZW5jaWVzIGluIG92ZXJsYXkgdG9wb2xvZ2llcyBvbiB1bmRlcmxheSB0b3Bv bG9naWVzIHRoYXQgYXJlIGRpc2NvdmVyZWQgYW5kIHJlcHJlc2VudCDigJxzdGF0ZeKAnSwNCiBh bmQgdGhhdCBpbiBmYWN0IHlvdXIgdW5kZXJsYXkgbWF5IGJlIGVpdGhlci4mbmJzcDsgPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SRkMgNzIyMywgYXMgZmFyIGFz IEkgY2FuIHRlbGwsIHNpZGVzdGVwcyB0aGlzIGlzc3VlLiZuYnNwOyBJdCBkb2VzIGRlZmluZSBh IHR5cGUg4oCcaW50ZXJmYWNlLXJlZuKAnSB3aXRoIGEgcGF0aCB0byByZWZlcmVuY2UgYSBjb25m aWd1cmVkIGludGVyZmFjZSwgYW5kIGl0IGRvZXMgZGVmaW5lDQogYSB0eXBlICZuYnNwO+KAnGlu dGVyZmFjZS1zdGF0ZS1yZWbigJ0gdG8gcmVmZXJlbmNlIGFuIG9wZXJhdGlvbmFsbHkgcHJlc2Vu dCBpbnRlcmZhY2UuJm5ic3A7IEhvd2V2ZXIsIGludGVyZmFjZS1zdGF0ZS1yZWYgaXMgdXNlZCBv bmx5IGluIHJlYWQtb25seSBvYmplY3RzLCB3aGVyZWFzICh0byBwdXQgdGhlIGFuYWxvZ3kpIGl0 IGlzIG5lZWRlZCBmb3IgY29uZmlndXJhYmxlIG9iamVjdHMgYXMgd2VsbC4mbmJzcDsgTGlrZXdp c2UsIHRoZXJlIGFyZSB0d28gdHlwZXM7IHJlYWxseQ0KIHdlIG5lZWQgYSB1bmlvbiB3aGljaCB3 b3VsZCBhbGxvdyBlaXRoZXIgKG9yIGEgbGVhZnJlZiB3aXRoIGFsdGVybmF0ZSBwYXRocywgd2hp Y2ggaXMgbm90IHN1cHBvcnRlZCkuJm5ic3A7IFdoaWxlIHRoZXJlIGFyZSBzb21lIGFuYWxvZ2ll cyB3aXRoIGEgcHJlcHJvdmlzaW9uaW5nIHNjZW5hcmlvLCB0aGVyZSBhcmUgYWxzbyBkaWZmZXJl bmNlcy4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5Bbnl3YXksIFh1ZmVuZywgS2VudCwgUGF2YW4gYW5kIEkgYXJlIGhhdmluZyBvZmZsaW5l IGRpc2N1c3Npb25zIGFuZCB3aWxsIGNvbWUgYmFjayB3aXRoIGZ1cnRoZXIgZWxhYm9yYXRpb24g b24gdGhpcy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxpYSBBdGxhczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEZlYnJ1YXJ5IDAxLCAyMDE3IDE6MTQgUE08YnI+DQo8Yj5Ubzo8L2I+IExvdSBCZXJnZXIg Jmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLWkycnMt eWFuZy1sMy10b3BvbG9neUBpZXRmLm9yZzsgaTJyc0BpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2kycnNdIEthdGhsZWVuIE1vcmlhcnR5J3MgTm8gT2Jq ZWN0aW9uIG9uIGRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LTA4OiAod2l0aCBDT01N RU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IEZlYiAxLCAyMDE3IGF0IDM6NTYgUE0sIExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzps YmVyZ2VyQGxhYm4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiAyLzEvMjAxNyAyOjMyIFBNLCBK dWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6PGJyPg0KJmd0OyBPbiBXZWQsIEZlYiAwMSwgMjAx NyBhdCAwMTo1MjoyNVBNIC0wNTAwLCBMb3UgQmVyZ2VyIHdyb3RlOjxicj4NCiZndDsmZ3Q7IEp1 ZXJnZW4sPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7V2hh dCBwcmVjbHVkZXMgdHJlYXRpbmcgc3VjaCBkZXBlbmRlbmNpZXMgaW4gdGhlIHNhbWUgd2F5PGJy Pg0KJmd0OyZndDsgcGVyLXByb3Zpc2lvbmluZyBpcyBoYW5kbGVkIGJ5IFJGQzcyMjM/PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7IFRoaXMgaXMgZmluZS4gQnV0IGhhdmluZyBkaXJlY3QgZGVwZW5k ZW5jaWVzLCBlLmcuLCBsZWFmcmVmcyBmcm9tPGJyPg0KJmd0OyBjb25maWcgdHJ1ZSBsZWFmcyB0 byBjb25maWcgZmFsc2UgbGVhZnMsIGlzIG5vdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAvanM8YnI+ DQomZ3Q7PGJyPg0KPGJyPg0KT2theSwgdGhlbiB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlIC0tIEkg dGhpbmsgc29tZSBtYXkgaGF2ZSBtaXNzZWQgdGhlPGJyPg0KcG9zc2liaWxpdHkgb2YgaGFuZGxp bmcgcmVmZXJlbmNlcyB0byBkeW5hbWljIHRvcG9sb2d5IGluZm9ybWF0aW9uIGluPGJyPg0KY29u ZmlnIHVzaW5nIGEgJ3ByZS1wcm92aXNpb25pbmcnIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBiZSBo YXBweSB0byBzZWUgQWxleCwgWHVmZW5nLCBLZW50ICZhbXA7IFBhdmFuIGFydGljdWxhdGUgd2hh dCB0aGlzIHdvdWxkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5sb29rIGxpa2UgYW5kIGhvdyBpdCB3b3VsZCB3b3JrIGZvciB0aGUgYmFzZSB0b3Bv bG9neSBtb2RlbCwgc28gdGhhdCB0aGUgV0cgY2FuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb25zaWRlciBhbGwgcG90ZW50aWFsbHkgdmlhYmxl IG9wdGlvbnMuJm5ic3A7IEknbSBub3QgY2VydGFpbiBob3cgaXQgd291bGQgZnVuY3Rpb24gZm9y IHRoZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+cmVjdXJzaXZlIG5hdHVyZSBhbmQgaXQgZG9lcyBwcmVzdW1lIHRoZSBzZXBhcmF0ZSAv Y29uZmlnIGFuZCAvb3Blci1zdGF0ZSB0cmVlcyBpbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGRhdGEtbW9kZWwgdGhhdCB3ZXJl IGEgY29uY2VybiAodGhvdWdoIGNlcnRhaW5seSB0aGUgY3VycmVudCByZWNvbW1lbmRlZCZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXBw cm9hY2ggZm9yIFlBTkcgbW9kZWxzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsaWEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EESJCEML703CHMchi_-- From nobody Wed Feb 1 23:33:36 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF831293F8; Wed, 1 Feb 2017 23:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 5dzEDF1t04JF; Wed, 1 Feb 2017 23:33:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAAE1293DA; Wed, 1 Feb 2017 23:33:32 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 032E71AE01AA; Thu, 2 Feb 2017 08:33:30 +0100 (CET) Date: Thu, 02 Feb 2017 08:33:29 +0100 (CET) Message-Id: <20170202.083329.1828765889486608943.mbj@tail-f.com> To: alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> References: <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, lberger@labn.net, iesg@ietf.org, akatlas@gmail.com Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 07:33:34 -0000 QWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4gd3JvdGU6DQo+IFdl IGFyZSB3b3JraW5nIHRoaXMgc2VwYXJhdGVseSBhbmQgd2lsbCBhcnRpY3VsYXRlIHRoZSBkaWZm ZXJlbnQNCj4gb3B0aW9ucyBhbmQgdGhlaXIgcmVzcGVjdGl2ZSBpc3N1ZXMuDQo+IA0KPiBUaGUg ZnVuZGFtZW50YWwgaXNzdWUgaXMgc3RpbGwgdGhlIGZhY3QgdGhhdCB5b3UgbWF5IGhhdmUgZGVw ZW5kZW5jaWVzDQo+IGluIG92ZXJsYXkgdG9wb2xvZ2llcyBvbiB1bmRlcmxheSB0b3BvbG9naWVz IHRoYXQgYXJlIGRpc2NvdmVyZWQgYW5kDQo+IHJlcHJlc2VudCDigJxzdGF0ZeKAnSwgYW5kIHRo YXQgaW4gZmFjdCB5b3VyIHVuZGVybGF5IG1heSBiZSBlaXRoZXIuDQo+IA0KPiBSRkMgNzIyMywg YXMgZmFyIGFzIEkgY2FuIHRlbGwsIHNpZGVzdGVwcyB0aGlzIGlzc3VlLiAgSXQgZG9lcyBkZWZp bmUNCj4gYSB0eXBlIOKAnGludGVyZmFjZS1yZWbigJ0gd2l0aCBhIHBhdGggdG8gcmVmZXJlbmNl IGEgY29uZmlndXJlZA0KPiBpbnRlcmZhY2UsIGFuZCBpdCBkb2VzIGRlZmluZSBhIHR5cGUg4oCc aW50ZXJmYWNlLXN0YXRlLXJlZuKAnSB0bw0KPiByZWZlcmVuY2UgYW4gb3BlcmF0aW9uYWxseSBw cmVzZW50IGludGVyZmFjZS4gIEhvd2V2ZXIsDQo+IGludGVyZmFjZS1zdGF0ZS1yZWYgaXMgdXNl ZCBvbmx5IGluIHJlYWQtb25seSBvYmplY3RzLCB3aGVyZWFzICh0byBwdXQNCj4gdGhlIGFuYWxv Z3kpIGl0IGlzIG5lZWRlZCBmb3IgY29uZmlndXJhYmxlIG9iamVjdHMgYXMgd2VsbC4gIExpa2V3 aXNlLA0KPiB0aGVyZSBhcmUgdHdvIHR5cGVzOyByZWFsbHkgd2UgbmVlZCBhIHVuaW9uIHdoaWNo IHdvdWxkIGFsbG93IGVpdGhlcg0KPiAob3IgYSBsZWFmcmVmIHdpdGggYWx0ZXJuYXRlIHBhdGhz LCB3aGljaCBpcyBub3Qgc3VwcG9ydGVkKS4gIFdoaWxlDQo+IHRoZXJlIGFyZSBzb21lIGFuYWxv Z2llcyB3aXRoIGEgcHJlcHJvdmlzaW9uaW5nIHNjZW5hcmlvLCB0aGVyZSBhcmUNCj4gYWxzbyBk aWZmZXJlbmNlcy4NCg0KV2hlbiBwZW9wbGUgcmVmZXIgdG8gdGhlICJwcmUtcHJvdmlzaW9uaW5n IGFwcHJvYWNoIiBpbiBSRkMgNzIyMywgaXQNCmlzIG5vdCB0aGUgImludGVyZmFjZS1yZWYiIG9y ICJpbnRlcmZhY2Utc3RhdGUtcmVmIiB0aGV5IHJlZmVyIHRvLg0KDQpUaGUgcHJlLXByb3Zpc2lv bmluZyBtZWNoYW5pc20gaW4gUkZDIDcyMjMgc2F5cyB0aGF0IHdoZW4gdGhlIGRldmljZQ0KaW5p dGlhbGl6ZXMgYSBkZXRlY3RlZCBpbnRlcmZhY2UsIGl0IHdpbGwgY2hlY2sgdGhlIGNvbmZpZ3Vy YXRpb24gdG8NCnNlZSBpZiB0aGVyZSBpcyBjb25maWcgYXZhaWxhYmxlIGZvciBhbiBpbnRlcmZh Y2Ugd2l0aCB0aGUgc2FtZSBuYW1lDQphcyB0aGUgbmV3bHkgZGV0ZWN0ZWQgb25lLiAgSWYgc28s IHRoYXQgY29uZmlnIGlzIHVzZWQuDQoNCkkgdGhpbmsgdGhlIGlkZWEgd2FzIHRvIHVzZSBzb21l dGhpbmcgc2ltaWxhciBoZXJlLiAgRS5nLiwgYWxsb3cgYQ0KY29uZmlndXJlZCBvdmVybGF5IHRv IHJlZmVyIHRvIGEgZGlzY292ZXJlZCB1bmRlcmxheSBieSBuYW1lLiAgSW4gWUFORywNCnRoaXMg Y2FuIGJlIGRvbmUgd2l0aCBhIG5vZGUgd2l0aCB0aGUgc2FtZSB0eXBlOyBvciBwb3NzaWJseSB3 aXRoIGENCmxlYWZyZWYgdG8gdGhlIHN0YXRlIGRhdGEgd2l0aCAicmVxdWlyZS1pbnN0YW5jZSBm YWxzZSIuDQoNClRoaXMgZGVzaWduIGFsbG93cyBhbiBvdmVybGF5IHRvIGJlIGNvbmZpZ3VyZWQg Zm9yIGFuIGV4aXN0aW5nDQpkZXRlY3RlZCB1bmRlcmxheS4gIExldCdzIHNheSB0aGUgZGV2aWNl IHJlYm9vdHMgYW5kIHN0YXJ0cyB0byByZWJ1aWxkDQppdHMgdG9wb2xvZ2llcy4gIER1cmluZyBz b21lIHBlcmlvZCBvZiB0aW1lLCB0aGUgY29uZmlndXJlZCBvdmVybGF5DQpzdGlsbCBleGlzdCBp biB0aGUgY29uZmlnLCBidXQgbm90IGluIHRoZSBzdGF0ZSwgc2luY2UgdGhlIHVuZGVybGF5IGlz DQpub3QgeWV0IGF2YWlsYWJsZS4gIE9uY2UgaXQgYmVjb21lcyBpbnN0YW50aWF0ZWQgaW4gdGhl IHN0YXRlLCB0aGUNCm92ZXJsYXkgaXMgYWxzbyBpbnN0YW50aWF0ZWQgaW4gdGhlIHN0YXRlLiAg KFRoaXMgYXNzdW1lcyB0aGF0IHRoZQ0Kc3lzdGVtLWdlbmVyYXRlZCB0b3BvbG9neSBuYW1lcyBk byBub3QgY2hhbmdlKS4NCg0KDQovbWFydGluDQoNCg0KDQo+IA0KPiBBbnl3YXksIFh1ZmVuZywg S2VudCwgUGF2YW4gYW5kIEkgYXJlIGhhdmluZyBvZmZsaW5lIGRpc2N1c3Npb25zIGFuZA0KPiB3 aWxsIGNvbWUgYmFjayB3aXRoIGZ1cnRoZXIgZWxhYm9yYXRpb24gb24gdGhpcy4NCj4gDQo+IC0t LSBBbGV4DQo+IA0KPiBGcm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQWxpYSBBdGxhcw0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDAxLCAy MDE3IDE6MTQgUE0NCj4gVG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+IENjOiBk cmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neUBpZXRmLm9yZzsgaTJyc0BpZXRmLm9yZzsN Cj4gaWVzZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2kycnNdIEthdGhsZWVuIE1vcmlhcnR5 J3MgTm8gT2JqZWN0aW9uIG9uDQo+IGRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LTA4 OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gT24gV2VkLCBGZWIgMSwgMjAxNyBhdCAzOjU2IFBNLCBM b3UgQmVyZ2VyDQo+IDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4g d3JvdGU6DQo+IA0KPiANCj4gT24gMi8xLzIwMTcgMjozMiBQTSwgSnVlcmdlbiBTY2hvZW53YWVs ZGVyIHdyb3RlOg0KPiA+IE9uIFdlZCwgRmViIDAxLCAyMDE3IGF0IDAxOjUyOjI1UE0gLTA1MDAs IExvdSBCZXJnZXIgd3JvdGU6DQo+ID4+IEp1ZXJnZW4sDQo+ID4+DQo+ID4+ICAgICBXaGF0IHBy ZWNsdWRlcyB0cmVhdGluZyBzdWNoIGRlcGVuZGVuY2llcyBpbiB0aGUgc2FtZSB3YXkNCj4gPj4g cGVyLXByb3Zpc2lvbmluZyBpcyBoYW5kbGVkIGJ5IFJGQzcyMjM/DQo+ID4+DQo+ID4gVGhpcyBp cyBmaW5lLiBCdXQgaGF2aW5nIGRpcmVjdCBkZXBlbmRlbmNpZXMsIGUuZy4sIGxlYWZyZWZzIGZy b20NCj4gPiBjb25maWcgdHJ1ZSBsZWFmcyB0byBjb25maWcgZmFsc2UgbGVhZnMsIGlzIG5vdC4N Cj4gPg0KPiA+IC9qcw0KPiA+DQo+IA0KPiBPa2F5LCB0aGVuIHdlJ3JlIG9uIHRoZSBzYW1lIHBh Z2UgLS0gSSB0aGluayBzb21lIG1heSBoYXZlIG1pc3NlZCB0aGUNCj4gcG9zc2liaWxpdHkgb2Yg aGFuZGxpbmcgcmVmZXJlbmNlcyB0byBkeW5hbWljIHRvcG9sb2d5IGluZm9ybWF0aW9uIGluDQo+ IGNvbmZpZyB1c2luZyBhICdwcmUtcHJvdmlzaW9uaW5nJyBhcHByb2FjaC4NCj4gDQo+IEkgd291 bGQgYmUgaGFwcHkgdG8gc2VlIEFsZXgsIFh1ZmVuZywgS2VudCAmIFBhdmFuIGFydGljdWxhdGUg d2hhdA0KPiB0aGlzIHdvdWxkDQo+IGxvb2sgbGlrZSBhbmQgaG93IGl0IHdvdWxkIHdvcmsgZm9y IHRoZSBiYXNlIHRvcG9sb2d5IG1vZGVsLCBzbyB0aGF0DQo+IHRoZSBXRyBjYW4NCj4gY29uc2lk ZXIgYWxsIHBvdGVudGlhbGx5IHZpYWJsZSBvcHRpb25zLiAgSSdtIG5vdCBjZXJ0YWluIGhvdyBp dCB3b3VsZA0KPiBmdW5jdGlvbiBmb3IgdGhlDQo+IHJlY3Vyc2l2ZSBuYXR1cmUgYW5kIGl0IGRv ZXMgcHJlc3VtZSB0aGUgc2VwYXJhdGUgL2NvbmZpZyBhbmQNCj4gL29wZXItc3RhdGUgdHJlZXMg aW4NCj4gdGhlIGRhdGEtbW9kZWwgdGhhdCB3ZXJlIGEgY29uY2VybiAodGhvdWdoIGNlcnRhaW5s eSB0aGUgY3VycmVudA0KPiByZWNvbW1lbmRlZA0KPiBhcHByb2FjaCBmb3IgWUFORyBtb2RlbHMp Lg0KPiANCj4gUmVnYXJkcywNCj4gQWxpYQ0K From nobody Thu Feb 2 06:03:20 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608B9129454; Thu, 2 Feb 2017 06:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXYx8JMtMSfB; Thu, 2 Feb 2017 06:03:16 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AC9129453; Thu, 2 Feb 2017 06:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lzLmEOWz6G/NPzL7Sv7UTJCPZrCJ/m0SA+uMHR1bok4=; b=jNOnjKYDbG1LSQ1HSi6gaXazwR9bS/GTEzncen2fg/wEl1r1GBOjgGb8v0FAByn9RIrl0Ts/FaTjeD8VSKiWZCLQLfHrHlQdsN3X9M6Q1r7YuyrS1lc9yzrQUm/RIMdFC2i4bJfoyR2ghcVZEBz5pyagG3YKDBKm8mKf/Dl+mls= Received: from BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) by BN3PR02MB1144.namprd02.prod.outlook.com (10.162.168.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 14:03:14 +0000 Received: from BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) by BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 14:03:14 +0000 From: Xufeng Liu To: Martin Bjorklund , "alexander.clemm@huawei.com" Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/y6tc6V0kTeEi7pAhS6Zp8AqFJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAZlpA Date: Thu, 2 Feb 2017 14:03:14 +0000 Message-ID: References: <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> <20170202.083329.1828765889486608943.mbj@tail-f.com> In-Reply-To: <20170202.083329.1828765889486608943.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 0bb6da1c-0c59-4c40-ae0d-08d44b743b02 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR02MB1144; x-microsoft-exchange-diagnostics: 1; BN3PR02MB1144; 7:xGrNLPeaXtXwv2B/9vX/o8wgJKnDX5zHbUjqZ//mos3r+H64jhN+Zku6I/Y0Yso22yQT7pFtwIbZTiAMtH29ssf4BBsZAOppIIO1lZLxaOepgHRbEu93rX0IfUGQkryP/Jtk45eHpDE63nJXNO4Fzd+U9vS4+OvV9ZQXAoDIEGto7fgO5N9icxGKLy0CaIzRjEIxZsgOmcoXoLJTw6j5JAdYkyG16SfS3u141LS5w+BjCvMiAZGtZ4IM2qHZ+AQspSeWyZJIQOhzikPrJf399GmCVs2preXWQhIG8kByePUFLyfej7mmJlIpdSZONBt/GxSBzvHy+2hnBO7sKeQYKamzXUgN4veUldKtKNMDcvemnG1NO2jc3AjEcraXXFTwLg/ezYwSbtjEjNCGKLBm3D7zIHsu8NjRve8FDZuCXEiXDorJ6g3wEIKbDvZ1kagqFIGzAcNHx3iyO7jCoF+t3KKjwOKOxmmwk5x8/ZhcIu0EVIB37+YMPWUl2F60kt8cI2sOde/J2+vTM+Iyx4DnBe8UtzIVJrzvWGKCiyaAfkNlpbW2gVjYGL16kC10KKju x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR02MB1144; BCL:0; PCL:0; RULEID:; SRVR:BN3PR02MB1144; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39860400002)(39850400002)(13464003)(199003)(377454003)(24454002)(189002)(52314003)(54906002)(39060400001)(3280700002)(8676002)(86362001)(305945005)(2900100001)(2501003)(7736002)(97736004)(3660700001)(38730400001)(93886004)(2950100002)(101416001)(25786008)(106356001)(77096006)(105586002)(106116001)(122556002)(4326007)(74316002)(2906002)(92566002)(81166006)(81156014)(102836003)(8936002)(6116002)(3846002)(55016002)(80792005)(229853002)(53936002)(5660300001)(5001770100001)(66066001)(7696004)(6506006)(230783001)(99286003)(189998001)(76176999)(50986999)(9686003)(68736007)(33656002)(54356999)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR02MB1144; H:BN3PR02MB1141.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 14:03:14.1050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR02MB1144 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" , "lberger@labn.net" , "iesg@ietf.org" , "akatlas@gmail.com" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:03:19 -0000 SGkgTWFydGluLA0KDQpJIGtub3cgdGhhdCB0aGlzIGlzIGEgcHJldmlvdXNseSBkaXNjdXNzZWQg c29sdXRpb24sIGJ1dCBJIHN0aWxsIGhhdmUgc29tZSBpc3N1ZXMgd2l0aCBpdDoNCg0KMSkgSW4g dGhlIGNhc2Ugb2YgdGhlIGludGVyZmFjZXMgbW9kZWwsIGZvciBlYWNoIHJlZmVyZW5jZWQgaW50 ZXJmYWNlLXN0YXRlLCB0aGUgb3BlcmF0b3IgbmVlZHMgdG8gY29uZmlndXJlIGFuIGludGVyZmFj ZSBvYmplY3Qgd2l0aCB0aGUgc2FtZSBpbnRlcmZhY2UgbmFtZS4gSG93ZXZlciwgaW4gdGhlIGNh c2Ugb2YgdGhlIHRvcG9sb2d5IG1vZGVsLCBpZiB3ZSBuZWVkIHRvIHJlZmVyZW5jZSBhbiB1bmRl cmxheSBsaW5rLXN0YXRlLCB3ZSB3aWxsIG5lZWQgdG8gY29uZmlndXJlIGEgdG9wb2xvZ3kgKGNh bGxlZCBuZXR3b3JrKSwgYSBzb3VyY2Ugbm9kZSwgYSBkZXN0aW5hdGlvbiBub2RlLCBhIHNvdXJj ZSB0ZXJtaW5hdGlvbi1wb2ludCwgYSBkZXN0aW5hdGlvbiB0ZXJtaW5hdGlvbi1wb2ludCwgd2hp Y2ggYXJlIGZpdmUgb2JqZWN0cyB3aXRob3V0IGluY2x1ZGluZyBvdGhlciBjb25zZXF1ZW50IG1h bmRhdG9yeSBvYmplY3RzLg0KDQoyKSBUaGlzIGFwcHJvYWNoIHN0cmV0Y2hlcyB0aGUgZGVmaW5p dGlvbiBvZiAic3lzdGVtIGdlbmVyYXRlZCIgbm9uLWNvbmZpZ3VyYWJsZSBvYmplY3RzLiBUaGUg c3lzdGVtIGdlbmVyYXRlZCBvYmplY3RzIG1lbnRpb25lZCBpbiAxKSBhcmUgZGVzaWduZWQgdG8g YmUgbm90IGNvbmZpZ3VyYWJsZS4gQ29uZmlndXJpbmcgdGhlbSBtYXkgcmVzdWx0IHVuLWRlc2ly YWJsZSBjb25zZXF1ZW5jZXMuDQoNCjMpIEluIGdlbmVyYWwsIHRoaXMgYXBwcm9hY2ggd2lsbCBu b3Qgd29yayBpZiB0aGUgcmVmZXJlbmNlZCBzY2hlbWEgbGVhZiBpcyBtYXJrZWQgYXMgImNvbmZp ZyBmYWxzZSIuIEluIHN1Y2ggYSBjYXNlLCB3ZSBjYW5ub3QgY29uZmlndXJlIHN1Y2ggYSByZWZl cmVuY2VkIGxlYWYgc2luY2UgaXQgaXMgbm90IGNvbmZpZ3VyYWJsZS4NCg0KVGhhbmtzLA0KDQot IFh1ZmVuZw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRpbiBC am9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDIsIDIwMTcgMjozMyBBTQ0KPiBUbzogYWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20NCj4g Q2M6IGFrYXRsYXNAZ21haWwuY29tOyBsYmVyZ2VyQGxhYm4ubmV0OyBkcmFmdC1pZXRmLWkycnMt eWFuZy1sMy0NCj4gdG9wb2xvZ3lAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7IGllc2dAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtpMnJzXSBLYXRobGVlbiBNb3JpYXJ0eSdzIE5vIE9iamVjdGlv biBvbiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy0NCj4gdG9wb2xvZ3ktMDg6ICh3aXRoIENPTU1F TlQpDQo+IA0KPiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPiB3 cm90ZToNCj4gPiBXZSBhcmUgd29ya2luZyB0aGlzIHNlcGFyYXRlbHkgYW5kIHdpbGwgYXJ0aWN1 bGF0ZSB0aGUgZGlmZmVyZW50DQo+ID4gb3B0aW9ucyBhbmQgdGhlaXIgcmVzcGVjdGl2ZSBpc3N1 ZXMuDQo+ID4NCj4gPiBUaGUgZnVuZGFtZW50YWwgaXNzdWUgaXMgc3RpbGwgdGhlIGZhY3QgdGhh dCB5b3UgbWF5IGhhdmUgZGVwZW5kZW5jaWVzDQo+ID4gaW4gb3ZlcmxheSB0b3BvbG9naWVzIG9u IHVuZGVybGF5IHRvcG9sb2dpZXMgdGhhdCBhcmUgZGlzY292ZXJlZCBhbmQNCj4gPiByZXByZXNl bnQg4oCcc3RhdGXigJ0sIGFuZCB0aGF0IGluIGZhY3QgeW91ciB1bmRlcmxheSBtYXkgYmUgZWl0 aGVyLg0KPiA+DQo+ID4gUkZDIDcyMjMsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLCBzaWRlc3RlcHMg dGhpcyBpc3N1ZS4gIEl0IGRvZXMgZGVmaW5lDQo+ID4gYSB0eXBlIOKAnGludGVyZmFjZS1yZWbi gJ0gd2l0aCBhIHBhdGggdG8gcmVmZXJlbmNlIGEgY29uZmlndXJlZA0KPiA+IGludGVyZmFjZSwg YW5kIGl0IGRvZXMgZGVmaW5lIGEgdHlwZSDigJxpbnRlcmZhY2Utc3RhdGUtcmVm4oCdIHRvDQo+ ID4gcmVmZXJlbmNlIGFuIG9wZXJhdGlvbmFsbHkgcHJlc2VudCBpbnRlcmZhY2UuICBIb3dldmVy LA0KPiA+IGludGVyZmFjZS1zdGF0ZS1yZWYgaXMgdXNlZCBvbmx5IGluIHJlYWQtb25seSBvYmpl Y3RzLCB3aGVyZWFzICh0byBwdXQNCj4gPiB0aGUgYW5hbG9neSkgaXQgaXMgbmVlZGVkIGZvciBj b25maWd1cmFibGUgb2JqZWN0cyBhcyB3ZWxsLiAgTGlrZXdpc2UsDQo+ID4gdGhlcmUgYXJlIHR3 byB0eXBlczsgcmVhbGx5IHdlIG5lZWQgYSB1bmlvbiB3aGljaCB3b3VsZCBhbGxvdyBlaXRoZXIN Cj4gPiAob3IgYSBsZWFmcmVmIHdpdGggYWx0ZXJuYXRlIHBhdGhzLCB3aGljaCBpcyBub3Qgc3Vw cG9ydGVkKS4gIFdoaWxlDQo+ID4gdGhlcmUgYXJlIHNvbWUgYW5hbG9naWVzIHdpdGggYSBwcmVw cm92aXNpb25pbmcgc2NlbmFyaW8sIHRoZXJlIGFyZQ0KPiA+IGFsc28gZGlmZmVyZW5jZXMuDQo+ IA0KPiBXaGVuIHBlb3BsZSByZWZlciB0byB0aGUgInByZS1wcm92aXNpb25pbmcgYXBwcm9hY2gi IGluIFJGQyA3MjIzLCBpdCBpcyBub3QgdGhlDQo+ICJpbnRlcmZhY2UtcmVmIiBvciAiaW50ZXJm YWNlLXN0YXRlLXJlZiIgdGhleSByZWZlciB0by4NCj4gDQo+IFRoZSBwcmUtcHJvdmlzaW9uaW5n IG1lY2hhbmlzbSBpbiBSRkMgNzIyMyBzYXlzIHRoYXQgd2hlbiB0aGUgZGV2aWNlDQo+IGluaXRp YWxpemVzIGEgZGV0ZWN0ZWQgaW50ZXJmYWNlLCBpdCB3aWxsIGNoZWNrIHRoZSBjb25maWd1cmF0 aW9uIHRvIHNlZSBpZiB0aGVyZSBpcw0KPiBjb25maWcgYXZhaWxhYmxlIGZvciBhbiBpbnRlcmZh Y2Ugd2l0aCB0aGUgc2FtZSBuYW1lIGFzIHRoZSBuZXdseSBkZXRlY3RlZCBvbmUuDQo+IElmIHNv LCB0aGF0IGNvbmZpZyBpcyB1c2VkLg0KPiANCj4gSSB0aGluayB0aGUgaWRlYSB3YXMgdG8gdXNl IHNvbWV0aGluZyBzaW1pbGFyIGhlcmUuICBFLmcuLCBhbGxvdyBhIGNvbmZpZ3VyZWQNCj4gb3Zl cmxheSB0byByZWZlciB0byBhIGRpc2NvdmVyZWQgdW5kZXJsYXkgYnkgbmFtZS4gIEluIFlBTkcs IHRoaXMgY2FuIGJlIGRvbmUNCj4gd2l0aCBhIG5vZGUgd2l0aCB0aGUgc2FtZSB0eXBlOyBvciBw b3NzaWJseSB3aXRoIGEgbGVhZnJlZiB0byB0aGUgc3RhdGUgZGF0YSB3aXRoDQo+ICJyZXF1aXJl LWluc3RhbmNlIGZhbHNlIi4NCj4gDQo+IFRoaXMgZGVzaWduIGFsbG93cyBhbiBvdmVybGF5IHRv IGJlIGNvbmZpZ3VyZWQgZm9yIGFuIGV4aXN0aW5nIGRldGVjdGVkIHVuZGVybGF5Lg0KPiBMZXQn cyBzYXkgdGhlIGRldmljZSByZWJvb3RzIGFuZCBzdGFydHMgdG8gcmVidWlsZCBpdHMgdG9wb2xv Z2llcy4gIER1cmluZyBzb21lDQo+IHBlcmlvZCBvZiB0aW1lLCB0aGUgY29uZmlndXJlZCBvdmVy bGF5IHN0aWxsIGV4aXN0IGluIHRoZSBjb25maWcsIGJ1dCBub3QgaW4gdGhlIHN0YXRlLA0KPiBz aW5jZSB0aGUgdW5kZXJsYXkgaXMgbm90IHlldCBhdmFpbGFibGUuICBPbmNlIGl0IGJlY29tZXMg aW5zdGFudGlhdGVkIGluIHRoZSBzdGF0ZSwNCj4gdGhlIG92ZXJsYXkgaXMgYWxzbyBpbnN0YW50 aWF0ZWQgaW4gdGhlIHN0YXRlLiAgKFRoaXMgYXNzdW1lcyB0aGF0IHRoZSBzeXN0ZW0tDQo+IGdl bmVyYXRlZCB0b3BvbG9neSBuYW1lcyBkbyBub3QgY2hhbmdlKS4NCj4gDQo+IA0KPiAvbWFydGlu DQo+IA0KPiANCj4gDQo+ID4NCj4gPiBBbnl3YXksIFh1ZmVuZywgS2VudCwgUGF2YW4gYW5kIEkg YXJlIGhhdmluZyBvZmZsaW5lIGRpc2N1c3Npb25zIGFuZA0KPiA+IHdpbGwgY29tZSBiYWNrIHdp dGggZnVydGhlciBlbGFib3JhdGlvbiBvbiB0aGlzLg0KPiA+DQo+ID4gLS0tIEFsZXgNCj4gPg0K PiA+IEZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBBbGlhIEF0bGFzDQo+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwMSwgMjAxNyAxOjE0 IFBNDQo+ID4gVG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+ID4gQ2M6IGRyYWZ0 LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5QGlldGYub3JnOyBpMnJzQGlldGYub3JnOw0KPiA+ IGllc2dAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW2kycnNdIEthdGhsZWVuIE1vcmlhcnR5 J3MgTm8gT2JqZWN0aW9uIG9uDQo+ID4gZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3kt MDg6ICh3aXRoIENPTU1FTlQpDQo+ID4NCj4gPiBPbiBXZWQsIEZlYiAxLCAyMDE3IGF0IDM6NTYg UE0sIExvdSBCZXJnZXINCj4gPiA8bGJlcmdlckBsYWJuLm5ldDxtYWlsdG86bGJlcmdlckBsYWJu Lm5ldD4+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBPbiAyLzEvMjAxNyAyOjMyIFBNLCBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+ID4gPiBPbiBXZWQsIEZlYiAwMSwgMjAxNyBhdCAwMTo1 MjoyNVBNIC0wNTAwLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPiA+ID4+IEp1ZXJnZW4sDQo+ID4gPj4N Cj4gPiA+PiAgICAgV2hhdCBwcmVjbHVkZXMgdHJlYXRpbmcgc3VjaCBkZXBlbmRlbmNpZXMgaW4g dGhlIHNhbWUgd2F5DQo+ID4gPj4gcGVyLXByb3Zpc2lvbmluZyBpcyBoYW5kbGVkIGJ5IFJGQzcy MjM/DQo+ID4gPj4NCj4gPiA+IFRoaXMgaXMgZmluZS4gQnV0IGhhdmluZyBkaXJlY3QgZGVwZW5k ZW5jaWVzLCBlLmcuLCBsZWFmcmVmcyBmcm9tDQo+ID4gPiBjb25maWcgdHJ1ZSBsZWFmcyB0byBj b25maWcgZmFsc2UgbGVhZnMsIGlzIG5vdC4NCj4gPiA+DQo+ID4gPiAvanMNCj4gPiA+DQo+ID4N Cj4gPiBPa2F5LCB0aGVuIHdlJ3JlIG9uIHRoZSBzYW1lIHBhZ2UgLS0gSSB0aGluayBzb21lIG1h eSBoYXZlIG1pc3NlZCB0aGUNCj4gPiBwb3NzaWJpbGl0eSBvZiBoYW5kbGluZyByZWZlcmVuY2Vz IHRvIGR5bmFtaWMgdG9wb2xvZ3kgaW5mb3JtYXRpb24gaW4NCj4gPiBjb25maWcgdXNpbmcgYSAn cHJlLXByb3Zpc2lvbmluZycgYXBwcm9hY2guDQo+ID4NCj4gPiBJIHdvdWxkIGJlIGhhcHB5IHRv IHNlZSBBbGV4LCBYdWZlbmcsIEtlbnQgJiBQYXZhbiBhcnRpY3VsYXRlIHdoYXQNCj4gPiB0aGlz IHdvdWxkIGxvb2sgbGlrZSBhbmQgaG93IGl0IHdvdWxkIHdvcmsgZm9yIHRoZSBiYXNlIHRvcG9s b2d5DQo+ID4gbW9kZWwsIHNvIHRoYXQgdGhlIFdHIGNhbiBjb25zaWRlciBhbGwgcG90ZW50aWFs bHkgdmlhYmxlIG9wdGlvbnMuDQo+ID4gSSdtIG5vdCBjZXJ0YWluIGhvdyBpdCB3b3VsZCBmdW5j dGlvbiBmb3IgdGhlIHJlY3Vyc2l2ZSBuYXR1cmUgYW5kIGl0DQo+ID4gZG9lcyBwcmVzdW1lIHRo ZSBzZXBhcmF0ZSAvY29uZmlnIGFuZCAvb3Blci1zdGF0ZSB0cmVlcyBpbiB0aGUNCj4gPiBkYXRh LW1vZGVsIHRoYXQgd2VyZSBhIGNvbmNlcm4gKHRob3VnaCBjZXJ0YWlubHkgdGhlIGN1cnJlbnQN Cj4gPiByZWNvbW1lbmRlZCBhcHByb2FjaCBmb3IgWUFORyBtb2RlbHMpLg0KPiA+DQo+ID4gUmVn YXJkcywNCj4gPiBBbGlhDQo= From nobody Thu Feb 2 06:52:56 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E953129426; Thu, 2 Feb 2017 06:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHwOKT0NUD1x; Thu, 2 Feb 2017 06:52:54 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BC21293E9; Thu, 2 Feb 2017 06:52:53 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.2.125; From: "Susan Hares" To: "'Alia Atlas'" , "'Lou Berger'" References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <20170201193238.GA82029@elstar.local> <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> In-Reply-To: Date: Thu, 2 Feb 2017 09:48:26 -0500 Message-ID: <010701d27d63$69d05160$3d70f420$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0108_01D27D39.80FC4530" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDMDDOlqUr6NUq+FONL11ADZxeNCgGvnhE+AZ//NCkDIpJlDQK/OpHKAu3qOW4BzTABPAH9Q1ojouNfiZA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:52:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0108_01D27D39.80FC4530 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Lou and Juergen:=20 =20 Just to make sure I understand the pre-provisioning comment. What you = are referring to is the =E2=80=9Cwhen=E2=80=9D statements in the clause = below.=20 =20 augment "/if:interfaces/if:interface" { when "if:type =3D 'ianaift:ethernetCsmacd'"; =20 // operational state parameters for Ethernet interfaces augment "/if:interfaces-state/if:interface" { when "if:type =3D 'ianaift:ethernetCsmacd'"; =20 =20 Thank you,=20 Sue Hares=20 =20 =20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Wednesday, February 1, 2017 4:14 PM To: Lou Berger Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; = iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) =20 On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger wrote: On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote: > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: >> Juergen, >> >> What precludes treating such dependencies in the same way >> per-provisioning is handled by RFC7223? >> > This is fine. But having direct dependencies, e.g., leafrefs from > config true leafs to config false leafs, is not. > > /js > Okay, then we're on the same page -- I think some may have missed the possibility of handling references to dynamic topology information in config using a 'pre-provisioning' approach. =20 I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this = would look like and how it would work for the base topology model, so that the = WG can consider all potentially viable options. I'm not certain how it would = function for the=20 recursive nature and it does presume the separate /config and = /oper-state trees in=20 the data-model that were a concern (though certainly the current = recommended=20 approach for YANG models). =20 Regards, Alia=20 ------=_NextPart_000_0108_01D27D39.80FC4530 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Lou and Juergen:

 

Just to make sure I understand the pre-provisioning comment.=C2=A0 = What you are referring to is the =E2=80=9Cwhen=E2=80=9D statements in = the clause below.

 

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when = "if:type =3D = 'ianaift:ethernetCsmacd'";

 

=C2=A0=C2=A0 // operational state parameters for =
Ethernet interfaces
=C2=A0=C2=A0=C2=A0=C2=A0 augment =
"/if:interfaces-state/if:interface" =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when =
"if:type =3D =
'ianaift:ethernetCsmacd'";

 

 

Thank you,

Sue Hares

 

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia = Atlas
Sent: Wednesday, February 1, 2017 4:14 PM
To: = Lou Berger
Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; = i2rs@ietf.org; iesg@ietf.org
Subject: Re: [i2rs] Kathleen = Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with = COMMENT)

 

On = Wed, Feb 1, 2017 at 3:56 PM, Lou Berger <lberger@labn.net> = wrote:



On 2/1/2017 2:32 PM, Juergen Schoenwaelder = wrote:
> On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger = wrote:
>> Juergen,
>>
>>    =  What precludes treating such dependencies in the same = way
>> per-provisioning is handled by = RFC7223?
>>
> This is fine. But having direct = dependencies, e.g., leafrefs from
> config true leafs to config = false leafs, is not.
>
> /js
>

Okay, then we're = on the same page -- I think some may have missed the
possibility of = handling references to dynamic topology information in
config using a = 'pre-provisioning' approach.

 

I = would be happy to see Alex, Xufeng, Kent & Pavan articulate what = this would

look like and = how it would work for the base topology model, so that the WG = can

consider all = potentially viable options.  I'm not certain how it would function = for the 

recursive = nature and it does presume the separate /config and /oper-state trees = in 

the data-model = that were a concern (though certainly the current = recommended 

approach = for YANG models).

 

Regards,

Alia 

= ------=_NextPart_000_0108_01D27D39.80FC4530-- From nobody Thu Feb 2 07:14:57 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AAF12946B; Thu, 2 Feb 2017 07:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atPt1k9XYuBl; Thu, 2 Feb 2017 07:14:53 -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 948DB129462; Thu, 2 Feb 2017 07:14:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6C90F6D4; Thu, 2 Feb 2017 16:14:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WTDWyZYPj9YE; Thu, 2 Feb 2017 16:14: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; Thu, 2 Feb 2017 16:14:51 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4269200AB; Thu, 2 Feb 2017 16:14:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z-sfe3QFr-j3; Thu, 2 Feb 2017 16:14:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C751200AD; Thu, 2 Feb 2017 16:14:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 09C063E64676; Thu, 2 Feb 2017 16:14:55 +0100 (CET) Date: Thu, 2 Feb 2017 16:14:54 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20170202151454.GA84423@elstar.local> Mail-Followup-To: Susan Hares , 'Alia Atlas' , 'Lou Berger' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <20170201193238.GA82029@elstar.local> <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> <010701d27d63$69d05160$3d70f420$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <010701d27d63$69d05160$3d70f420$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, 'Lou Berger' , 'Alia Atlas' Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:14:55 -0000 I do not understand your question, but the answer is likely 'no'. See Martin's email, perhaps that one helps. In RFC 7223, you can configure an interface that is not currently present. An interface is identified by a name and the interface configuration sits in the configuration datastore. When an interface starts to exist (e.g., a line card is inserted) that has a matching name, then the interface configuration with the same name is applied to it. This is RFC 7223 style pre-provisioning. /js On Thu, Feb 02, 2017 at 09:48:26AM -0500, Susan Hares wrote: > Lou and Juergen: > > > > Just to make sure I understand the pre-provisioning comment. What you are referring to is the “when†statements in the clause below. > > > > augment "/if:interfaces/if:interface" { > > when "if:type = 'ianaift:ethernetCsmacd'"; > > > > // operational state parameters for Ethernet interfaces > augment "/if:interfaces-state/if:interface" { > when "if:type = 'ianaift:ethernetCsmacd'"; > > > > > > Thank you, > > Sue Hares > > > > > > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Wednesday, February 1, 2017 4:14 PM > To: Lou Berger > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; iesg@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger wrote: > > > > On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote: > > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: > >> Juergen, > >> > >> What precludes treating such dependencies in the same way > >> per-provisioning is handled by RFC7223? > >> > > This is fine. But having direct dependencies, e.g., leafrefs from > > config true leafs to config false leafs, is not. > > > > /js > > > > Okay, then we're on the same page -- I think some may have missed the > possibility of handling references to dynamic topology information in > config using a 'pre-provisioning' approach. > > > > I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this would > > look like and how it would work for the base topology model, so that the WG can > > consider all potentially viable options. I'm not certain how it would function for the > > recursive nature and it does presume the separate /config and /oper-state trees in > > the data-model that were a concern (though certainly the current recommended > > approach for YANG models). > > > > Regards, > > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- 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 Feb 2 08:17:38 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9AB129712; Thu, 2 Feb 2017 08:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 YXRPYmzSRt7W; Thu, 2 Feb 2017 08:17:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22D129706; Thu, 2 Feb 2017 08:17:34 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 2FA151AE0444; Thu, 2 Feb 2017 17:17:33 +0100 (CET) Date: Thu, 02 Feb 2017 17:17:32 +0100 (CET) Message-Id: <20170202.171732.487428777571541086.mbj@tail-f.com> To: Xufeng_Liu@jabil.com From: Martin Bjorklund In-Reply-To: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> <20170202.083329.1828765889486608943.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, akatlas@gmail.com, alexander.clemm@huawei.com, iesg@ietf.org, lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:17:37 -0000 SGksDQoNClh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwuY29tPiB3cm90ZToNCj4gSGkgTWFy dGluLA0KPiANCj4gSSBrbm93IHRoYXQgdGhpcyBpcyBhIHByZXZpb3VzbHkgZGlzY3Vzc2VkIHNv bHV0aW9uLCBidXQgSSBzdGlsbCBoYXZlDQo+IHNvbWUgaXNzdWVzIHdpdGggaXQ6DQo+IA0KPiAx KSBJbiB0aGUgY2FzZSBvZiB0aGUgaW50ZXJmYWNlcyBtb2RlbCwgZm9yIGVhY2ggcmVmZXJlbmNl ZA0KPiBpbnRlcmZhY2Utc3RhdGUsIHRoZSBvcGVyYXRvciBuZWVkcyB0byBjb25maWd1cmUgYW4g aW50ZXJmYWNlIG9iamVjdA0KPiB3aXRoIHRoZSBzYW1lIGludGVyZmFjZSBuYW1lLiBIb3dldmVy LCBpbiB0aGUgY2FzZSBvZiB0aGUgdG9wb2xvZ3kNCj4gbW9kZWwsIGlmIHdlIG5lZWQgdG8gcmVm ZXJlbmNlIGFuIHVuZGVybGF5IGxpbmstc3RhdGUsIHdlIHdpbGwgbmVlZCB0bw0KPiBjb25maWd1 cmUgYSB0b3BvbG9neSAoY2FsbGVkIG5ldHdvcmspLCBhIHNvdXJjZSBub2RlLCBhIGRlc3RpbmF0 aW9uDQo+IG5vZGUsIGEgc291cmNlIHRlcm1pbmF0aW9uLXBvaW50LCBhIGRlc3RpbmF0aW9uIHRl cm1pbmF0aW9uLXBvaW50LA0KPiB3aGljaCBhcmUgZml2ZSBvYmplY3RzIHdpdGhvdXQgaW5jbHVk aW5nIG90aGVyIGNvbnNlcXVlbnQgbWFuZGF0b3J5DQo+IG9iamVjdHMuDQoNCllvdSBkb24ndCBo YXZlIHRvIGNvbmZpZ3VyZSBhICJkdW1teSIgb2JqZWN0IGlmIHlvdSBhcmUgbm90IHVzaW5nDQps ZWFmcmVmcyB0byBjb25maWcuICBBbmQgdGhlIG51bWJlciBvZiBub2RlcyB0aGF0IHlvdSBuZWVk IGZvciB1bmlxdWUNCmlkZW50aWZpY2F0aW9uIHNob3VsZCBiZSB0b3RhbGx5IGluZGVwZW5kZW50 Lg0KDQo+IDIpIFRoaXMgYXBwcm9hY2ggc3RyZXRjaGVzIHRoZSBkZWZpbml0aW9uIG9mICJzeXN0 ZW0gZ2VuZXJhdGVkIg0KPiBub24tY29uZmlndXJhYmxlIG9iamVjdHMuIFRoZSBzeXN0ZW0gZ2Vu ZXJhdGVkIG9iamVjdHMgbWVudGlvbmVkIGluIDEpDQo+IGFyZSBkZXNpZ25lZCB0byBiZSBub3Qg Y29uZmlndXJhYmxlLiBDb25maWd1cmluZyB0aGVtIG1heSByZXN1bHQNCj4gdW4tZGVzaXJhYmxl IGNvbnNlcXVlbmNlcy4NCg0KU2VlIGFib3ZlLg0KDQo+IDMpIEluIGdlbmVyYWwsIHRoaXMgYXBw cm9hY2ggd2lsbCBub3Qgd29yayBpZiB0aGUgcmVmZXJlbmNlZCBzY2hlbWENCj4gbGVhZiBpcyBt YXJrZWQgYXMgImNvbmZpZyBmYWxzZSIuIEluIHN1Y2ggYSBjYXNlLCB3ZSBjYW5ub3QgY29uZmln dXJlDQo+IHN1Y2ggYSByZWZlcmVuY2VkIGxlYWYgc2luY2UgaXQgaXMgbm90IGNvbmZpZ3VyYWJs ZS4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgY29tbWVudC4NCg0KQlRXLCBtYXliZSBmdXJ0 aGVyIGRpc2N1c3Npb24gYWJvdXQgYSBuZXcgc29sdXRpb24gc2hvdWxkIGJlIG9uIHRoZQ0KaTJy cyBNTCBvbmx5Pw0KDQoNCi9tYXJ0aW4NCg0KDQo+IA0KPiBUaGFua3MsDQo+IA0KPiAtIFh1ZmVu Zw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hcnRpbiBC am9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMiwgMjAxNyAyOjMzIEFNDQo+ID4gVG86IGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29t DQo+ID4gQ2M6IGFrYXRsYXNAZ21haWwuY29tOyBsYmVyZ2VyQGxhYm4ubmV0OyBkcmFmdC1pZXRm LWkycnMteWFuZy1sMy0NCj4gPiB0b3BvbG9neUBpZXRmLm9yZzsgaTJyc0BpZXRmLm9yZzsgaWVz Z0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbaTJyc10gS2F0aGxlZW4gTW9yaWFydHkncyBO byBPYmplY3Rpb24gb24NCj4gPiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy0NCj4gPiB0b3BvbG9n eS0wODogKHdpdGggQ09NTUVOVCkNCj4gPiANCj4gPiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRl ci5jbGVtbUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+IFdlIGFyZSB3b3JraW5nIHRoaXMgc2Vw YXJhdGVseSBhbmQgd2lsbCBhcnRpY3VsYXRlIHRoZSBkaWZmZXJlbnQNCj4gPiA+IG9wdGlvbnMg YW5kIHRoZWlyIHJlc3BlY3RpdmUgaXNzdWVzLg0KPiA+ID4NCj4gPiA+IFRoZSBmdW5kYW1lbnRh bCBpc3N1ZSBpcyBzdGlsbCB0aGUgZmFjdCB0aGF0IHlvdSBtYXkgaGF2ZSBkZXBlbmRlbmNpZXMN Cj4gPiA+IGluIG92ZXJsYXkgdG9wb2xvZ2llcyBvbiB1bmRlcmxheSB0b3BvbG9naWVzIHRoYXQg YXJlIGRpc2NvdmVyZWQgYW5kDQo+ID4gPiByZXByZXNlbnQg4oCcc3RhdGXigJ0sIGFuZCB0aGF0 IGluIGZhY3QgeW91ciB1bmRlcmxheSBtYXkgYmUgZWl0aGVyLg0KPiA+ID4NCj4gPiA+IFJGQyA3 MjIzLCBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgc2lkZXN0ZXBzIHRoaXMgaXNzdWUuICBJdCBkb2Vz IGRlZmluZQ0KPiA+ID4gYSB0eXBlIOKAnGludGVyZmFjZS1yZWbigJ0gd2l0aCBhIHBhdGggdG8g cmVmZXJlbmNlIGEgY29uZmlndXJlZA0KPiA+ID4gaW50ZXJmYWNlLCBhbmQgaXQgZG9lcyBkZWZp bmUgYSB0eXBlIOKAnGludGVyZmFjZS1zdGF0ZS1yZWbigJ0gdG8NCj4gPiA+IHJlZmVyZW5jZSBh biBvcGVyYXRpb25hbGx5IHByZXNlbnQgaW50ZXJmYWNlLiAgSG93ZXZlciwNCj4gPiA+IGludGVy ZmFjZS1zdGF0ZS1yZWYgaXMgdXNlZCBvbmx5IGluIHJlYWQtb25seSBvYmplY3RzLCB3aGVyZWFz ICh0byBwdXQNCj4gPiA+IHRoZSBhbmFsb2d5KSBpdCBpcyBuZWVkZWQgZm9yIGNvbmZpZ3VyYWJs ZSBvYmplY3RzIGFzIHdlbGwuICBMaWtld2lzZSwNCj4gPiA+IHRoZXJlIGFyZSB0d28gdHlwZXM7 IHJlYWxseSB3ZSBuZWVkIGEgdW5pb24gd2hpY2ggd291bGQgYWxsb3cgZWl0aGVyDQo+ID4gPiAo b3IgYSBsZWFmcmVmIHdpdGggYWx0ZXJuYXRlIHBhdGhzLCB3aGljaCBpcyBub3Qgc3VwcG9ydGVk KS4gIFdoaWxlDQo+ID4gPiB0aGVyZSBhcmUgc29tZSBhbmFsb2dpZXMgd2l0aCBhIHByZXByb3Zp c2lvbmluZyBzY2VuYXJpbywgdGhlcmUgYXJlDQo+ID4gPiBhbHNvIGRpZmZlcmVuY2VzLg0KPiA+ IA0KPiA+IFdoZW4gcGVvcGxlIHJlZmVyIHRvIHRoZSAicHJlLXByb3Zpc2lvbmluZyBhcHByb2Fj aCIgaW4gUkZDIDcyMjMsIGl0DQo+ID4gaXMgbm90IHRoZQ0KPiA+ICJpbnRlcmZhY2UtcmVmIiBv ciAiaW50ZXJmYWNlLXN0YXRlLXJlZiIgdGhleSByZWZlciB0by4NCj4gPiANCj4gPiBUaGUgcHJl LXByb3Zpc2lvbmluZyBtZWNoYW5pc20gaW4gUkZDIDcyMjMgc2F5cyB0aGF0IHdoZW4gdGhlIGRl dmljZQ0KPiA+IGluaXRpYWxpemVzIGEgZGV0ZWN0ZWQgaW50ZXJmYWNlLCBpdCB3aWxsIGNoZWNr IHRoZSBjb25maWd1cmF0aW9uIHRvDQo+ID4gc2VlIGlmIHRoZXJlIGlzDQo+ID4gY29uZmlnIGF2 YWlsYWJsZSBmb3IgYW4gaW50ZXJmYWNlIHdpdGggdGhlIHNhbWUgbmFtZSBhcyB0aGUgbmV3bHkN Cj4gPiBkZXRlY3RlZCBvbmUuDQo+ID4gSWYgc28sIHRoYXQgY29uZmlnIGlzIHVzZWQuDQo+ID4g DQo+ID4gSSB0aGluayB0aGUgaWRlYSB3YXMgdG8gdXNlIHNvbWV0aGluZyBzaW1pbGFyIGhlcmUu ICBFLmcuLCBhbGxvdyBhDQo+ID4gY29uZmlndXJlZA0KPiA+IG92ZXJsYXkgdG8gcmVmZXIgdG8g YSBkaXNjb3ZlcmVkIHVuZGVybGF5IGJ5IG5hbWUuICBJbiBZQU5HLCB0aGlzIGNhbg0KPiA+IGJl IGRvbmUNCj4gPiB3aXRoIGEgbm9kZSB3aXRoIHRoZSBzYW1lIHR5cGU7IG9yIHBvc3NpYmx5IHdp dGggYSBsZWFmcmVmIHRvIHRoZQ0KPiA+IHN0YXRlIGRhdGEgd2l0aA0KPiA+ICJyZXF1aXJlLWlu c3RhbmNlIGZhbHNlIi4NCj4gPiANCj4gPiBUaGlzIGRlc2lnbiBhbGxvd3MgYW4gb3ZlcmxheSB0 byBiZSBjb25maWd1cmVkIGZvciBhbiBleGlzdGluZw0KPiA+IGRldGVjdGVkIHVuZGVybGF5Lg0K PiA+IExldCdzIHNheSB0aGUgZGV2aWNlIHJlYm9vdHMgYW5kIHN0YXJ0cyB0byByZWJ1aWxkIGl0 cyB0b3BvbG9naWVzLg0KPiA+IER1cmluZyBzb21lDQo+ID4gcGVyaW9kIG9mIHRpbWUsIHRoZSBj b25maWd1cmVkIG92ZXJsYXkgc3RpbGwgZXhpc3QgaW4gdGhlIGNvbmZpZywgYnV0DQo+ID4gbm90 IGluIHRoZSBzdGF0ZSwNCj4gPiBzaW5jZSB0aGUgdW5kZXJsYXkgaXMgbm90IHlldCBhdmFpbGFi bGUuICBPbmNlIGl0IGJlY29tZXMgaW5zdGFudGlhdGVkDQo+ID4gaW4gdGhlIHN0YXRlLA0KPiA+ IHRoZSBvdmVybGF5IGlzIGFsc28gaW5zdGFudGlhdGVkIGluIHRoZSBzdGF0ZS4gIChUaGlzIGFz c3VtZXMgdGhhdCB0aGUNCj4gPiBzeXN0ZW0tDQo+ID4gZ2VuZXJhdGVkIHRvcG9sb2d5IG5hbWVz IGRvIG5vdCBjaGFuZ2UpLg0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4gPiANCj4g PiANCj4gPiA+DQo+ID4gPiBBbnl3YXksIFh1ZmVuZywgS2VudCwgUGF2YW4gYW5kIEkgYXJlIGhh dmluZyBvZmZsaW5lIGRpc2N1c3Npb25zIGFuZA0KPiA+ID4gd2lsbCBjb21lIGJhY2sgd2l0aCBm dXJ0aGVyIGVsYWJvcmF0aW9uIG9uIHRoaXMuDQo+ID4gPg0KPiA+ID4gLS0tIEFsZXgNCj4gPiA+ DQo+ID4gPiBGcm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWxpYSBBdGxhcw0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwMSwgMjAx NyAxOjE0IFBNDQo+ID4gPiBUbzogTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCj4gPiA+ IENjOiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neUBpZXRmLm9yZzsgaTJyc0BpZXRm Lm9yZzsNCj4gPiA+IGllc2dAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbaTJyc10gS2F0 aGxlZW4gTW9yaWFydHkncyBObyBPYmplY3Rpb24gb24NCj4gPiA+IGRyYWZ0LWlldGYtaTJycy15 YW5nLWwzLXRvcG9sb2d5LTA4OiAod2l0aCBDT01NRU5UKQ0KPiA+ID4NCj4gPiA+IE9uIFdlZCwg RmViIDEsIDIwMTcgYXQgMzo1NiBQTSwgTG91IEJlcmdlcg0KPiA+ID4gPGxiZXJnZXJAbGFibi5u ZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCj4gPiA+DQo+ID4gPg0KPiA+ID4g T24gMi8xLzIwMTcgMjozMiBQTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOg0KPiA+ID4g PiBPbiBXZWQsIEZlYiAwMSwgMjAxNyBhdCAwMTo1MjoyNVBNIC0wNTAwLCBMb3UgQmVyZ2VyIHdy b3RlOg0KPiA+ID4gPj4gSnVlcmdlbiwNCj4gPiA+ID4+DQo+ID4gPiA+PiAgICAgV2hhdCBwcmVj bHVkZXMgdHJlYXRpbmcgc3VjaCBkZXBlbmRlbmNpZXMgaW4gdGhlIHNhbWUgd2F5DQo+ID4gPiA+ PiBwZXItcHJvdmlzaW9uaW5nIGlzIGhhbmRsZWQgYnkgUkZDNzIyMz8NCj4gPiA+ID4+DQo+ID4g PiA+IFRoaXMgaXMgZmluZS4gQnV0IGhhdmluZyBkaXJlY3QgZGVwZW5kZW5jaWVzLCBlLmcuLCBs ZWFmcmVmcyBmcm9tDQo+ID4gPiA+IGNvbmZpZyB0cnVlIGxlYWZzIHRvIGNvbmZpZyBmYWxzZSBs ZWFmcywgaXMgbm90Lg0KPiA+ID4gPg0KPiA+ID4gPiAvanMNCj4gPiA+ID4NCj4gPiA+DQo+ID4g PiBPa2F5LCB0aGVuIHdlJ3JlIG9uIHRoZSBzYW1lIHBhZ2UgLS0gSSB0aGluayBzb21lIG1heSBo YXZlIG1pc3NlZCB0aGUNCj4gPiA+IHBvc3NpYmlsaXR5IG9mIGhhbmRsaW5nIHJlZmVyZW5jZXMg dG8gZHluYW1pYyB0b3BvbG9neSBpbmZvcm1hdGlvbiBpbg0KPiA+ID4gY29uZmlnIHVzaW5nIGEg J3ByZS1wcm92aXNpb25pbmcnIGFwcHJvYWNoLg0KPiA+ID4NCj4gPiA+IEkgd291bGQgYmUgaGFw cHkgdG8gc2VlIEFsZXgsIFh1ZmVuZywgS2VudCAmIFBhdmFuIGFydGljdWxhdGUgd2hhdA0KPiA+ ID4gdGhpcyB3b3VsZCBsb29rIGxpa2UgYW5kIGhvdyBpdCB3b3VsZCB3b3JrIGZvciB0aGUgYmFz ZSB0b3BvbG9neQ0KPiA+ID4gbW9kZWwsIHNvIHRoYXQgdGhlIFdHIGNhbiBjb25zaWRlciBhbGwg cG90ZW50aWFsbHkgdmlhYmxlIG9wdGlvbnMuDQo+ID4gPiBJJ20gbm90IGNlcnRhaW4gaG93IGl0 IHdvdWxkIGZ1bmN0aW9uIGZvciB0aGUgcmVjdXJzaXZlIG5hdHVyZSBhbmQgaXQNCj4gPiA+IGRv ZXMgcHJlc3VtZSB0aGUgc2VwYXJhdGUgL2NvbmZpZyBhbmQgL29wZXItc3RhdGUgdHJlZXMgaW4g dGhlDQo+ID4gPiBkYXRhLW1vZGVsIHRoYXQgd2VyZSBhIGNvbmNlcm4gKHRob3VnaCBjZXJ0YWlu bHkgdGhlIGN1cnJlbnQNCj4gPiA+IHJlY29tbWVuZGVkIGFwcHJvYWNoIGZvciBZQU5HIG1vZGVs cykuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IEFsaWENCg== From nobody Thu Feb 2 08:54:11 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391191294C7 for ; Thu, 2 Feb 2017 08:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdPvF4og9MiL for ; Thu, 2 Feb 2017 08:54:08 -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 3044C129869 for ; Thu, 2 Feb 2017 08:53:59 -0800 (PST) Received: (qmail 1839 invoked by uid 0); 2 Feb 2017 16:53:56 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 2 Feb 2017 16:53:56 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id fsts1u00R2SSUrH01stvjL; Thu, 02 Feb 2017 09:53:56 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=2XbGCzA2LjAMp276pSUA:9 a=CmV9u7yBzzFC8lVp:21 a=5aEmpKRBaGZLqFRh:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=co5mOGPliIGlnD224AKWjfTkzM3kTRCStGBT+g95uGY=; b=noXYsFX02o9Gv8AzOYjVY2Fyu2 qPVFpx6QwodSB6SHkJL92lpuuD8IEhOFtLmtIeutWpy+0MKdNsqs7mx6wb2FWqKCBrzF+2lC69g6L H8b1TQemePkMRKP6IsunVI+/L; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:58524 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cZKds-0000rm-7V; Thu, 02 Feb 2017 09:53:52 -0700 To: Susan Hares , 'Alia Atlas' , draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <20170201193238.GA82029@elstar.local> <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> <010701d27d63$69d05160$3d70f420$@ndzh.com> <20170202151454.GA84423@elstar.local> From: Lou Berger Message-ID: <9fb055da-b280-27fa-62a8-92be6cd48a6a@labn.net> Date: Thu, 2 Feb 2017 11:53:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170202151454.GA84423@elstar.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cZKds-0000rm-7V X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:58524 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [i2rs] What is RFC 7223 style pre-provisioning (was Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:54:10 -0000 Hi Sue, I think Juergen's comment covers what I was referring to. Does this answer your question / make sense? Cheers, Lou On 2/2/2017 10:14 AM, Juergen Schoenwaelder wrote: > I do not understand your question, but the answer is likely 'no'. > > See Martin's email, perhaps that one helps. > > In RFC 7223, you can configure an interface that is not currently > present. An interface is identified by a name and the interface > configuration sits in the configuration datastore. When an interface > starts to exist (e.g., a line card is inserted) that has a matching > name, then the interface configuration with the same name is applied > to it. This is RFC 7223 style pre-provisioning. > > /js > > On Thu, Feb 02, 2017 at 09:48:26AM -0500, Susan Hares wrote: >> Lou and Juergen: >> >> >> >> Just to make sure I understand the pre-provisioning comment. What you are referring to is the “when†statements in the clause below. >> >> >> >> augment "/if:interfaces/if:interface" { >> >> when "if:type = 'ianaift:ethernetCsmacd'"; >> >> >> >> // operational state parameters for Ethernet interfaces >> augment "/if:interfaces-state/if:interface" { >> when "if:type = 'ianaift:ethernetCsmacd'"; >> >> >> >> >> >> Thank you, >> >> Sue Hares >> >> >> >> >> >> >> >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, February 1, 2017 4:14 PM >> To: Lou Berger >> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; iesg@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> >> >> On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger wrote: >> >> >> >> On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote: >>> On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: >>>> Juergen, >>>> >>>> What precludes treating such dependencies in the same way >>>> per-provisioning is handled by RFC7223? >>>> >>> This is fine. But having direct dependencies, e.g., leafrefs from >>> config true leafs to config false leafs, is not. >>> >>> /js >>> >> Okay, then we're on the same page -- I think some may have missed the >> possibility of handling references to dynamic topology information in >> config using a 'pre-provisioning' approach. >> >> >> >> I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this would >> >> look like and how it would work for the base topology model, so that the WG can >> >> consider all potentially viable options. I'm not certain how it would function for the >> >> recursive nature and it does presume the separate /config and /oper-state trees in >> >> the data-model that were a concern (though certainly the current recommended >> >> approach for YANG models). >> >> >> >> Regards, >> >> Alia >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Feb 2 08:59:05 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936E12944B; Thu, 2 Feb 2017 08:59:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148605474403.13829.2497219921855870137.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 08:59:04 -0800 Archived-At: Cc: i2rs@ietf.org, skh@ndzh.com, i2rs-chairs@ietf.org, akatlas@gmail.com Subject: [i2rs] i2rs - New Meeting Session Request for IETF 98 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:59:04 -0000 A new meeting session request has just been submitted by Susan Hares, a Chair of the i2rs working group. --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: idr i2nsf netconf netmod rtgwg rtgarea trill babel Second Priority: bess sidrops dots opsawg sfc Third Priority: anima cbor People who must be present: Susan Hares Russ White Alia Atlas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Feb 2 09:13:49 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F851294BA; Thu, 2 Feb 2017 09:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M53AkJ_JIqy8; Thu, 2 Feb 2017 09:13:39 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91523129722; Thu, 2 Feb 2017 09:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3MqLMSPxcv+lv/66jKjujFkCIx1HI+vsg2HHr/H/KII=; b=cRrBuJ5MVYZTvFwiQu43pSIcfI3HKQrAoOA+oSGb91mUaXNfJ7fJkqjkFo0/2HEJ2ha/c8+IYIcl/qI79GJbaZfbs4bcv6yMIQCo/3ZkMkXPS6mmTTklPXWXkpWEmld7T3Q+LFusH181l752vWy+0+kve9nKlomGi8Vq8Ty+Yq8= Received: from BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) by BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 17:13:36 +0000 Received: from BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) by BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 17:13:36 +0000 From: Xufeng Liu To: Martin Bjorklund Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/y6tc6V0kTeEi7pAhS6Zp8AqFJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAZlpAgAAsEQCAAAgoYA== Date: Thu, 2 Feb 2017 17:13:36 +0000 Message-ID: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> <20170202.083329.1828765889486608943.mbj@tail-f.com> <20170202.171732.487428777571541086.mbj@tail-f.com> In-Reply-To: <20170202.171732.487428777571541086.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 05a62782-5601-48e9-6bd1-08d44b8ed329 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR02MB1141; x-microsoft-exchange-diagnostics: 1; BN3PR02MB1141; 7:SWT4sWky0VXJQOKxV2PYYcnfXw15U/1N0cGOWGgMsuU3UcEmdx9lFYziFpoycSzJ4kUCjljXd9YP/WxS1N8s6EdHYaMk7MxqDfdEaZcTGGATCSgpTkl/6l4XAxBBQTiqbQJOTz2a4Zp9v1rr1sJWJUCo/IkvxUKv6ugNKlCUtdYUxbeqAUzfdO9xpj8g4I+Hqfn64sJdjTU8ArcGZDG2l6IMWvP5BD6SwZO5yxOreB98yZ+LDliitNvAKflA/u51t5BvmLAjJLL9HSRbN8kMHUUo8TzD89Tm+F5rZImPUPqwN+LCFtUnwZ+yXTqjAM0TqPCB6J9Cs5fIhH8Hp1ObpHdy5gLvSDwr5nzAXw5klID0chnIKZSxl0GUyPzqlZQS1VuGXH0qxuj1TGP0UhtcHv+fKGPusd7+eBzArn9YOFOElnHNMzyskPjZiH2oMVmeC81x4fFkLzI1m+gRNRGXUiq76ZPc9t0AH9LHL6sThK7bmCt9/kfQYuwhiGdiiMzvdwDneKX2RXH7tLRQ5kSZIM5T8JT3vSpgMXEg9Q5uLq293W7oZC7G18945dQ6Szzn x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR02MB1141; BCL:0; PCL:0; RULEID:; SRVR:BN3PR02MB1141; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39850400002)(39860400002)(39410400002)(377454003)(189002)(24454002)(199003)(52314003)(13464003)(2900100001)(92566002)(38730400001)(39060400001)(2906002)(99286003)(74316002)(55016002)(8936002)(86362001)(3280700002)(68736007)(77096006)(25786008)(6506006)(97736004)(5660300001)(229853002)(54906002)(6436002)(9686003)(230783001)(4326007)(110136003)(105586002)(81166006)(81156014)(33656002)(3846002)(80792005)(101416001)(54356999)(50986999)(76176999)(93886004)(6916009)(122556002)(2950100002)(7736002)(6116002)(189998001)(7696004)(53936002)(102836003)(66066001)(106116001)(8676002)(3660700001)(305945005)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR02MB1141; H:BN3PR02MB1141.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 17:13:36.4577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR02MB1141 Archived-At: Cc: "i2rs@ietf.org" , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "akatlas@gmail.com" , "alexander.clemm@huawei.com" , "iesg@ietf.org" , "lberger@labn.net" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:13:42 -0000 SGkgTWFydGluLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRp biBCam9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDIsIDIwMTcgMTE6MTggQU0NCj4gVG86IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFi aWwuY29tPg0KPiBDYzogYWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb207IGFrYXRsYXNAZ21haWwu Y29tOyBsYmVyZ2VyQGxhYm4ubmV0Ow0KPiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9n eUBpZXRmLm9yZzsgaTJyc0BpZXRmLm9yZzsgaWVzZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W2kycnNdIEthdGhsZWVuIE1vcmlhcnR5J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaTJy cy15YW5nLWwzLQ0KPiB0b3BvbG9neS0wODogKHdpdGggQ09NTUVOVCkNCj4gDQo+IEhpLA0KPiAN Cj4gWHVmZW5nIExpdSA8WHVmZW5nX0xpdUBqYWJpbC5jb20+IHdyb3RlOg0KPiA+IEhpIE1hcnRp biwNCj4gPg0KPiA+IEkga25vdyB0aGF0IHRoaXMgaXMgYSBwcmV2aW91c2x5IGRpc2N1c3NlZCBz b2x1dGlvbiwgYnV0IEkgc3RpbGwgaGF2ZQ0KPiA+IHNvbWUgaXNzdWVzIHdpdGggaXQ6DQo+ID4N Cj4gPiAxKSBJbiB0aGUgY2FzZSBvZiB0aGUgaW50ZXJmYWNlcyBtb2RlbCwgZm9yIGVhY2ggcmVm ZXJlbmNlZA0KPiA+IGludGVyZmFjZS1zdGF0ZSwgdGhlIG9wZXJhdG9yIG5lZWRzIHRvIGNvbmZp Z3VyZSBhbiBpbnRlcmZhY2Ugb2JqZWN0DQo+ID4gd2l0aCB0aGUgc2FtZSBpbnRlcmZhY2UgbmFt ZS4gSG93ZXZlciwgaW4gdGhlIGNhc2Ugb2YgdGhlIHRvcG9sb2d5DQo+ID4gbW9kZWwsIGlmIHdl IG5lZWQgdG8gcmVmZXJlbmNlIGFuIHVuZGVybGF5IGxpbmstc3RhdGUsIHdlIHdpbGwgbmVlZCB0 bw0KPiA+IGNvbmZpZ3VyZSBhIHRvcG9sb2d5IChjYWxsZWQgbmV0d29yayksIGEgc291cmNlIG5v ZGUsIGEgZGVzdGluYXRpb24NCj4gPiBub2RlLCBhIHNvdXJjZSB0ZXJtaW5hdGlvbi1wb2ludCwg YSBkZXN0aW5hdGlvbiB0ZXJtaW5hdGlvbi1wb2ludCwNCj4gPiB3aGljaCBhcmUgZml2ZSBvYmpl Y3RzIHdpdGhvdXQgaW5jbHVkaW5nIG90aGVyIGNvbnNlcXVlbnQgbWFuZGF0b3J5DQo+ID4gb2Jq ZWN0cy4NCj4gDQo+IFlvdSBkb24ndCBoYXZlIHRvIGNvbmZpZ3VyZSBhICJkdW1teSIgb2JqZWN0 IGlmIHlvdSBhcmUgbm90IHVzaW5nIGxlYWZyZWZzIHRvDQo+IGNvbmZpZy4gIEFuZCB0aGUgbnVt YmVyIG9mIG5vZGVzIHRoYXQgeW91IG5lZWQgZm9yIHVuaXF1ZSBpZGVudGlmaWNhdGlvbiBzaG91 bGQNCj4gYmUgdG90YWxseSBpbmRlcGVuZGVudC4NCg0KW1h1ZmVuZ10gV2UgaGF2ZSB0byBkbyB0 aGVtIGluIHRoaXMgY2FzZSwgYmVjYXVzZSBhIGxpbmsgY29ubmVjdHMgdHdvIHRlcm1pbmF0aW9u LXBvaW50cywgd2l0aCBlYWNoIG9mIHRoZW0gYXJlIGluIGEgbm9kZSwgd2hpY2ggY2FuIG9ubHkg ZXhpc3RzIHdpdGhpbiB0aGUgY29udGV4dCBvZiBhIHRvcG9sb2d5LiBXaXRob3V0IGRlZmluaW5n IHRoZXNlIG9iamVjdHMsIEkgY2Fubm90IGNvbmZpZ3VyZSBhIHZhbGlkIGxpbmsuDQogDQo+IA0K PiA+IDIpIFRoaXMgYXBwcm9hY2ggc3RyZXRjaGVzIHRoZSBkZWZpbml0aW9uIG9mICJzeXN0ZW0g Z2VuZXJhdGVkIg0KPiA+IG5vbi1jb25maWd1cmFibGUgb2JqZWN0cy4gVGhlIHN5c3RlbSBnZW5l cmF0ZWQgb2JqZWN0cyBtZW50aW9uZWQgaW4gMSkNCj4gPiBhcmUgZGVzaWduZWQgdG8gYmUgbm90 IGNvbmZpZ3VyYWJsZS4gQ29uZmlndXJpbmcgdGhlbSBtYXkgcmVzdWx0DQo+ID4gdW4tZGVzaXJh YmxlIGNvbnNlcXVlbmNlcy4NCj4gDQo+IFNlZSBhYm92ZS4NCltYdWZlbmddIFdlIGRvbid0IHdh bnQgdG8gY29uZmlndXJlIGEgbm9kZSBvciBsaW5rIGp1c3QgYmVjYXVzZSB3ZSBuZWVkIHRvIHJl ZmVyZW5jZSBpdC4gQ29uZmlndXJpbmcgYSBub2RlIG1lYW5zIHRoYXQgdGhlIHN5c3RlbSB3aWxs IG5lZWQgdG8gcGVyZm9ybSBhIHNlcmllcyBvZiB0YXNrcyBhbmQgbWF5IGNoYW5nZSB0aGUgbm9k ZSB0byBoYXZlIGRpZmZlcmVudCBiZWhhdmlvcnMgZnJvbSBwcmV2aW91cyAic3lzdGVtIGdlbmVy YXRlZCIgbm9uLWNvbmZpZ3VyYWJsZSBub2RlLg0KDQo+IA0KPiA+IDMpIEluIGdlbmVyYWwsIHRo aXMgYXBwcm9hY2ggd2lsbCBub3Qgd29yayBpZiB0aGUgcmVmZXJlbmNlZCBzY2hlbWENCj4gPiBs ZWFmIGlzIG1hcmtlZCBhcyAiY29uZmlnIGZhbHNlIi4gSW4gc3VjaCBhIGNhc2UsIHdlIGNhbm5v dCBjb25maWd1cmUNCj4gPiBzdWNoIGEgcmVmZXJlbmNlZCBsZWFmIHNpbmNlIGl0IGlzIG5vdCBj b25maWd1cmFibGUuDQo+IA0KPiBJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50Lg0KW1h1 ZmVuZ10gQXNzdW1lIHRoZSBmb2xsb3dpbmcgbW9kZWw6DQoNCistLXJ3IG5vZGVzDQogICArLS1y dyBub2RlIFtpZF0NCiAgICAgICstLXJ3IGlkICAgc3RyaW5nDQogICAgICArLS1ydyB1bmRlci1s YXktYXR0cmlidXRlLWEgPz8/DQorLS0tcm8gbm9kZXMtc3RhdGUNCiAgICstLXJvIG5vZGUgW2lk XQ0KICAgICAgKy0tcm8gaWQgICBzdHJpbmcNCiAgICAgICstLXJvIGF0dHJpYnV0ZS1hIHN0cmlu Zw0KDQpJIGNhbm5vdCBkZWZpbmUgdGhlIHVuZGVyLWxheS1hdHRyaWJ1dGUtYSB0byByZWZlcmVu Y2UgYXR0cmlidXRlLWEgYXM6DQogICAgICAgICAgICAgICB0eXBlIGxlYWZyZWYgew0KICAgICAg ICAgICAgICAgICBwYXRoICIuLi9ub2RlL2F0dHJpYnV0ZS1hIicNCiAgICAgICAgICAgICAgIH0N Cg0KPiANCj4gQlRXLCBtYXliZSBmdXJ0aGVyIGRpc2N1c3Npb24gYWJvdXQgYSBuZXcgc29sdXRp b24gc2hvdWxkIGJlIG9uIHRoZSBpMnJzIE1MDQo+IG9ubHk/DQo+IA0KPiANCj4gL21hcnRpbg0K PiANCj4gDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiAtIFh1ZmVuZw0KPiA+DQo+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBb bWFpbHRvOm1iakB0YWlsLWYuY29tXQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIs IDIwMTcgMjozMyBBTQ0KPiA+ID4gVG86IGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tDQo+ID4g PiBDYzogYWthdGxhc0BnbWFpbC5jb207IGxiZXJnZXJAbGFibi5uZXQ7IGRyYWZ0LWlldGYtaTJy cy15YW5nLWwzLQ0KPiA+ID4gdG9wb2xvZ3lAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7IGllc2dA aWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbaTJyc10gS2F0aGxlZW4gTW9yaWFydHkncyBO byBPYmplY3Rpb24gb24NCj4gPiA+IGRyYWZ0LWlldGYtaTJycy15YW5nLWwzLQ0KPiA+ID4gdG9w b2xvZ3ktMDg6ICh3aXRoIENPTU1FTlQpDQo+ID4gPg0KPiA+ID4gQWxleGFuZGVyIENsZW1tIDxh bGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPiA+IFdlIGFyZSB3b3JraW5n IHRoaXMgc2VwYXJhdGVseSBhbmQgd2lsbCBhcnRpY3VsYXRlIHRoZSBkaWZmZXJlbnQNCj4gPiA+ ID4gb3B0aW9ucyBhbmQgdGhlaXIgcmVzcGVjdGl2ZSBpc3N1ZXMuDQo+ID4gPiA+DQo+ID4gPiA+ IFRoZSBmdW5kYW1lbnRhbCBpc3N1ZSBpcyBzdGlsbCB0aGUgZmFjdCB0aGF0IHlvdSBtYXkgaGF2 ZQ0KPiA+ID4gPiBkZXBlbmRlbmNpZXMgaW4gb3ZlcmxheSB0b3BvbG9naWVzIG9uIHVuZGVybGF5 IHRvcG9sb2dpZXMgdGhhdCBhcmUNCj4gPiA+ID4gZGlzY292ZXJlZCBhbmQgcmVwcmVzZW50IOKA nHN0YXRl4oCdLCBhbmQgdGhhdCBpbiBmYWN0IHlvdXIgdW5kZXJsYXkgbWF5IGJlDQo+IGVpdGhl ci4NCj4gPiA+ID4NCj4gPiA+ID4gUkZDIDcyMjMsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLCBzaWRl c3RlcHMgdGhpcyBpc3N1ZS4gIEl0IGRvZXMNCj4gPiA+ID4gZGVmaW5lIGEgdHlwZSDigJxpbnRl cmZhY2UtcmVm4oCdIHdpdGggYSBwYXRoIHRvIHJlZmVyZW5jZSBhDQo+ID4gPiA+IGNvbmZpZ3Vy ZWQgaW50ZXJmYWNlLCBhbmQgaXQgZG9lcyBkZWZpbmUgYSB0eXBlDQo+ID4gPiA+IOKAnGludGVy ZmFjZS1zdGF0ZS1yZWbigJ0gdG8gcmVmZXJlbmNlIGFuIG9wZXJhdGlvbmFsbHkgcHJlc2VudA0K PiA+ID4gPiBpbnRlcmZhY2UuICBIb3dldmVyLCBpbnRlcmZhY2Utc3RhdGUtcmVmIGlzIHVzZWQg b25seSBpbiByZWFkLW9ubHkNCj4gPiA+ID4gb2JqZWN0cywgd2hlcmVhcyAodG8gcHV0IHRoZSBh bmFsb2d5KSBpdCBpcyBuZWVkZWQgZm9yDQo+ID4gPiA+IGNvbmZpZ3VyYWJsZSBvYmplY3RzIGFz IHdlbGwuICBMaWtld2lzZSwgdGhlcmUgYXJlIHR3byB0eXBlczsNCj4gPiA+ID4gcmVhbGx5IHdl IG5lZWQgYSB1bmlvbiB3aGljaCB3b3VsZCBhbGxvdyBlaXRoZXIgKG9yIGEgbGVhZnJlZiB3aXRo DQo+ID4gPiA+IGFsdGVybmF0ZSBwYXRocywgd2hpY2ggaXMgbm90IHN1cHBvcnRlZCkuICBXaGls ZSB0aGVyZSBhcmUgc29tZQ0KPiA+ID4gPiBhbmFsb2dpZXMgd2l0aCBhIHByZXByb3Zpc2lvbmlu ZyBzY2VuYXJpbywgdGhlcmUgYXJlIGFsc28gZGlmZmVyZW5jZXMuDQo+ID4gPg0KPiA+ID4gV2hl biBwZW9wbGUgcmVmZXIgdG8gdGhlICJwcmUtcHJvdmlzaW9uaW5nIGFwcHJvYWNoIiBpbiBSRkMg NzIyMywgaXQNCj4gPiA+IGlzIG5vdCB0aGUgImludGVyZmFjZS1yZWYiIG9yICJpbnRlcmZhY2Ut c3RhdGUtcmVmIiB0aGV5IHJlZmVyIHRvLg0KPiA+ID4NCj4gPiA+IFRoZSBwcmUtcHJvdmlzaW9u aW5nIG1lY2hhbmlzbSBpbiBSRkMgNzIyMyBzYXlzIHRoYXQgd2hlbiB0aGUgZGV2aWNlDQo+ID4g PiBpbml0aWFsaXplcyBhIGRldGVjdGVkIGludGVyZmFjZSwgaXQgd2lsbCBjaGVjayB0aGUgY29u ZmlndXJhdGlvbiB0bw0KPiA+ID4gc2VlIGlmIHRoZXJlIGlzIGNvbmZpZyBhdmFpbGFibGUgZm9y IGFuIGludGVyZmFjZSB3aXRoIHRoZSBzYW1lIG5hbWUNCj4gPiA+IGFzIHRoZSBuZXdseSBkZXRl Y3RlZCBvbmUuDQo+ID4gPiBJZiBzbywgdGhhdCBjb25maWcgaXMgdXNlZC4NCj4gPiA+DQo+ID4g PiBJIHRoaW5rIHRoZSBpZGVhIHdhcyB0byB1c2Ugc29tZXRoaW5nIHNpbWlsYXIgaGVyZS4gIEUu Zy4sIGFsbG93IGENCj4gPiA+IGNvbmZpZ3VyZWQgb3ZlcmxheSB0byByZWZlciB0byBhIGRpc2Nv dmVyZWQgdW5kZXJsYXkgYnkgbmFtZS4gIEluDQo+ID4gPiBZQU5HLCB0aGlzIGNhbiBiZSBkb25l IHdpdGggYSBub2RlIHdpdGggdGhlIHNhbWUgdHlwZTsgb3IgcG9zc2libHkNCj4gPiA+IHdpdGgg YSBsZWFmcmVmIHRvIHRoZSBzdGF0ZSBkYXRhIHdpdGggInJlcXVpcmUtaW5zdGFuY2UgZmFsc2Ui Lg0KPiA+ID4NCj4gPiA+IFRoaXMgZGVzaWduIGFsbG93cyBhbiBvdmVybGF5IHRvIGJlIGNvbmZp Z3VyZWQgZm9yIGFuIGV4aXN0aW5nDQo+ID4gPiBkZXRlY3RlZCB1bmRlcmxheS4NCj4gPiA+IExl dCdzIHNheSB0aGUgZGV2aWNlIHJlYm9vdHMgYW5kIHN0YXJ0cyB0byByZWJ1aWxkIGl0cyB0b3Bv bG9naWVzLg0KPiA+ID4gRHVyaW5nIHNvbWUNCj4gPiA+IHBlcmlvZCBvZiB0aW1lLCB0aGUgY29u ZmlndXJlZCBvdmVybGF5IHN0aWxsIGV4aXN0IGluIHRoZSBjb25maWcsDQo+ID4gPiBidXQgbm90 IGluIHRoZSBzdGF0ZSwgc2luY2UgdGhlIHVuZGVybGF5IGlzIG5vdCB5ZXQgYXZhaWxhYmxlLiAg T25jZQ0KPiA+ID4gaXQgYmVjb21lcyBpbnN0YW50aWF0ZWQgaW4gdGhlIHN0YXRlLCB0aGUgb3Zl cmxheSBpcyBhbHNvDQo+ID4gPiBpbnN0YW50aWF0ZWQgaW4gdGhlIHN0YXRlLiAgKFRoaXMgYXNz dW1lcyB0aGF0IHRoZQ0KPiA+ID4gc3lzdGVtLQ0KPiA+ID4gZ2VuZXJhdGVkIHRvcG9sb2d5IG5h bWVzIGRvIG5vdCBjaGFuZ2UpLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAvbWFydGluDQo+ID4gPg0K PiA+ID4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEFueXdheSwgWHVmZW5nLCBLZW50LCBQYXZh biBhbmQgSSBhcmUgaGF2aW5nIG9mZmxpbmUgZGlzY3Vzc2lvbnMNCj4gPiA+ID4gYW5kIHdpbGwg Y29tZSBiYWNrIHdpdGggZnVydGhlciBlbGFib3JhdGlvbiBvbiB0aGlzLg0KPiA+ID4gPg0KPiA+ ID4gPiAtLS0gQWxleA0KPiA+ID4gPg0KPiA+ID4gPiBGcm9tOiBpMnJzIFttYWlsdG86aTJycy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxpYSBBdGxhcw0KPiA+ID4gPiBTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDAxLCAyMDE3IDE6MTQgUE0NCj4gPiA+ID4gVG86IExvdSBCZXJn ZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+ID4gPiA+IENjOiBkcmFmdC1pZXRmLWkycnMteWFuZy1s My10b3BvbG9neUBpZXRmLm9yZzsgaTJyc0BpZXRmLm9yZzsNCj4gPiA+ID4gaWVzZ0BpZXRmLm9y Zw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW2kycnNdIEthdGhsZWVuIE1vcmlhcnR5J3MgTm8gT2Jq ZWN0aW9uIG9uDQo+ID4gPiA+IGRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LTA4OiAo d2l0aCBDT01NRU5UKQ0KPiA+ID4gPg0KPiA+ID4gPiBPbiBXZWQsIEZlYiAxLCAyMDE3IGF0IDM6 NTYgUE0sIExvdSBCZXJnZXINCj4gPiA+ID4gPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJn ZXJAbGFibi5uZXQ+PiB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT24gMi8xLzIw MTcgMjozMiBQTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOg0KPiA+ID4gPiA+IE9uIFdl ZCwgRmViIDAxLCAyMDE3IGF0IDAxOjUyOjI1UE0gLTA1MDAsIExvdSBCZXJnZXIgd3JvdGU6DQo+ ID4gPiA+ID4+IEp1ZXJnZW4sDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ICAgICBXaGF0IHByZWNs dWRlcyB0cmVhdGluZyBzdWNoIGRlcGVuZGVuY2llcyBpbiB0aGUgc2FtZSB3YXkNCj4gPiA+ID4g Pj4gcGVyLXByb3Zpc2lvbmluZyBpcyBoYW5kbGVkIGJ5IFJGQzcyMjM/DQo+ID4gPiA+ID4+DQo+ ID4gPiA+ID4gVGhpcyBpcyBmaW5lLiBCdXQgaGF2aW5nIGRpcmVjdCBkZXBlbmRlbmNpZXMsIGUu Zy4sIGxlYWZyZWZzDQo+ID4gPiA+ID4gZnJvbSBjb25maWcgdHJ1ZSBsZWFmcyB0byBjb25maWcg ZmFsc2UgbGVhZnMsIGlzIG5vdC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC9qcw0KPiA+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+IE9rYXksIHRoZW4gd2UncmUgb24gdGhlIHNhbWUgcGFnZSAtLSBJ IHRoaW5rIHNvbWUgbWF5IGhhdmUgbWlzc2VkDQo+ID4gPiA+IHRoZSBwb3NzaWJpbGl0eSBvZiBo YW5kbGluZyByZWZlcmVuY2VzIHRvIGR5bmFtaWMgdG9wb2xvZ3kNCj4gPiA+ID4gaW5mb3JtYXRp b24gaW4gY29uZmlnIHVzaW5nIGEgJ3ByZS1wcm92aXNpb25pbmcnIGFwcHJvYWNoLg0KPiA+ID4g Pg0KPiA+ID4gPiBJIHdvdWxkIGJlIGhhcHB5IHRvIHNlZSBBbGV4LCBYdWZlbmcsIEtlbnQgJiBQ YXZhbiBhcnRpY3VsYXRlIHdoYXQNCj4gPiA+ID4gdGhpcyB3b3VsZCBsb29rIGxpa2UgYW5kIGhv dyBpdCB3b3VsZCB3b3JrIGZvciB0aGUgYmFzZSB0b3BvbG9neQ0KPiA+ID4gPiBtb2RlbCwgc28g dGhhdCB0aGUgV0cgY2FuIGNvbnNpZGVyIGFsbCBwb3RlbnRpYWxseSB2aWFibGUgb3B0aW9ucy4N Cj4gPiA+ID4gSSdtIG5vdCBjZXJ0YWluIGhvdyBpdCB3b3VsZCBmdW5jdGlvbiBmb3IgdGhlIHJl Y3Vyc2l2ZSBuYXR1cmUgYW5kDQo+ID4gPiA+IGl0IGRvZXMgcHJlc3VtZSB0aGUgc2VwYXJhdGUg L2NvbmZpZyBhbmQgL29wZXItc3RhdGUgdHJlZXMgaW4gdGhlDQo+ID4gPiA+IGRhdGEtbW9kZWwg dGhhdCB3ZXJlIGEgY29uY2VybiAodGhvdWdoIGNlcnRhaW5seSB0aGUgY3VycmVudA0KPiA+ID4g PiByZWNvbW1lbmRlZCBhcHByb2FjaCBmb3IgWUFORyBtb2RlbHMpLg0KPiA+ID4gPg0KPiA+ID4g PiBSZWdhcmRzLA0KPiA+ID4gPiBBbGlhDQo= From nobody Thu Feb 2 10:05:48 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4291D1294EE; Thu, 2 Feb 2017 10:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spFvq4R_f78f; Thu, 2 Feb 2017 10:05:38 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5281294EA; Thu, 2 Feb 2017 10:05:38 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.2.125; From: "Susan Hares" To: "'Martin Bjorklund'" , References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> <20170202.083329.1828765889486608943.mbj@tail-f.com> <20170202.171732.487428777571541086.mbj@tail-f.com> In-Reply-To: <20170202.171732.487428777571541086.mbj@tail-f.com> Date: Thu, 2 Feb 2017 13:00:59 -0500 Message-ID: <018e01d27d7e$4ff2cff0$efd86fd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtdlEAW7xDd50uAVB/3rKn3JG26AJM+ZDPAkl3AhYB4vJ3zKDsRDYQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, lberger@labn.net, alexander.clemm@huawei.com, akatlas@gmail.com Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:05:40 -0000 Martin is right. It should take off IESG and just be I2RS. The = document has been sent back to WG by Alia.=20 Sue=20 =20 Can add TEAS if Lou or Xufeng desires...=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Thursday, February 2, 2017 11:18 AM To: Xufeng_Liu@jabil.com Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; = akatlas@gmail.com; alexander.clemm@huawei.com; iesg@ietf.org; = lberger@labn.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on = draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Hi, Xufeng Liu wrote: > Hi Martin, >=20 > I know that this is a previously discussed solution, but I still have=20 > some issues with it: >=20 > 1) In the case of the interfaces model, for each referenced=20 > interface-state, the operator needs to configure an interface object=20 > with the same interface name. However, in the case of the topology=20 > model, if we need to reference an underlay link-state, we will need to = > configure a topology (called network), a source node, a destination=20 > node, a source termination-point, a destination termination-point,=20 > which are five objects without including other consequent mandatory=20 > objects. You don't have to configure a "dummy" object if you are not using = leafrefs to config. And the number of nodes that you need for unique = identification should be totally independent. > 2) This approach stretches the definition of "system generated" > non-configurable objects. The system generated objects mentioned in 1) = > are designed to be not configurable. Configuring them may result=20 > un-desirable consequences. See above. > 3) In general, this approach will not work if the referenced schema=20 > leaf is marked as "config false". In such a case, we cannot configure=20 > such a referenced leaf since it is not configurable. I don't understand this comment. BTW, maybe further discussion about a new solution should be on the i2rs = ML only? /martin >=20 > Thanks, >=20 > - Xufeng >=20 > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Thursday, February 2, 2017 2:33 AM > > To: alexander.clemm@huawei.com > > Cc: akatlas@gmail.com; lberger@labn.net; draft-ietf-i2rs-yang-l3-=20 > > topology@ietf.org; i2rs@ietf.org; iesg@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3- > > topology-08: (with COMMENT) > >=20 > > Alexander Clemm wrote: > > > We are working this separately and will articulate the different=20 > > > options and their respective issues. > > > > > > The fundamental issue is still the fact that you may have=20 > > > dependencies in overlay topologies on underlay topologies that are = > > > discovered and represent =E2=80=9Cstate=E2=80=9D, and that in fact = your underlay may be either. > > > > > > RFC 7223, as far as I can tell, sidesteps this issue. It does=20 > > > define a type =E2=80=9Cinterface-ref=E2=80=9D with a path to = reference a=20 > > > configured interface, and it does define a type=20 > > > =E2=80=9Cinterface-state-ref=E2=80=9D to reference an = operationally present=20 > > > interface. However, interface-state-ref is used only in read-only = > > > objects, whereas (to put the analogy) it is needed for=20 > > > configurable objects as well. Likewise, there are two types;=20 > > > really we need a union which would allow either (or a leafref with = > > > alternate paths, which is not supported). While there are some=20 > > > analogies with a preprovisioning scenario, there are also = differences. > >=20 > > When people refer to the "pre-provisioning approach" in RFC 7223, it = > > is not the "interface-ref" or "interface-state-ref" they refer to. > >=20 > > The pre-provisioning mechanism in RFC 7223 says that when the device = > > initializes a detected interface, it will check the configuration to = > > see if there is config available for an interface with the same name = > > as the newly detected one. > > If so, that config is used. > >=20 > > I think the idea was to use something similar here. E.g., allow a=20 > > configured overlay to refer to a discovered underlay by name. In=20 > > YANG, this can be done with a node with the same type; or possibly=20 > > with a leafref to the state data with "require-instance false". > >=20 > > This design allows an overlay to be configured for an existing=20 > > detected underlay. > > Let's say the device reboots and starts to rebuild its topologies. > > During some > > period of time, the configured overlay still exist in the config,=20 > > but not in the state, since the underlay is not yet available. Once = > > it becomes instantiated in the state, the overlay is also=20 > > instantiated in the state. (This assumes that the > > system- > > generated topology names do not change). > >=20 > >=20 > > /martin > >=20 > >=20 > >=20 > > > > > > Anyway, Xufeng, Kent, Pavan and I are having offline discussions=20 > > > and will come back with further elaboration on this. > > > > > > --- Alex > > > > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas > > > Sent: Wednesday, February 01, 2017 1:14 PM > > > To: Lou Berger > > > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org;=20 > > > iesg@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger=20 > > > > wrote: > > > > > > > > > On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote: > > > > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: > > > >> Juergen, > > > >> > > > >> What precludes treating such dependencies in the same way=20 > > > >> per-provisioning is handled by RFC7223? > > > >> > > > > This is fine. But having direct dependencies, e.g., leafrefs=20 > > > > from config true leafs to config false leafs, is not. > > > > > > > > /js > > > > > > > > > > Okay, then we're on the same page -- I think some may have missed=20 > > > the possibility of handling references to dynamic topology=20 > > > information in config using a 'pre-provisioning' approach. > > > > > > I would be happy to see Alex, Xufeng, Kent & Pavan articulate what = > > > this would look like and how it would work for the base topology=20 > > > model, so that the WG can consider all potentially viable options. > > > I'm not certain how it would function for the recursive nature and = > > > it does presume the separate /config and /oper-state trees in the=20 > > > data-model that were a concern (though certainly the current=20 > > > recommended approach for YANG models). > > > > > > Regards, > > > Alia _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 2 10:11:00 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49B91294EA; Thu, 2 Feb 2017 10:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2hPcZhw93jR; Thu, 2 Feb 2017 10:10:57 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEB812947C; Thu, 2 Feb 2017 10:10:57 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.2.125; From: "Susan Hares" To: "'Lou Berger'" , "'Alia Atlas'" , , References: <20170125145217.GF41033@elstar.jacobs.jacobs-university.de> <20170125151802.GA41293@elstar.jacobs.jacobs-university.de> <20170201193238.GA82029@elstar.local> <5204157b-1379-e217-5bcd-576ffeed6a91@labn.net> <010701d27d63$69d05160$3d70f420$@ndzh.com> <20170202151454.GA84423@elstar.local> <9fb055da-b280-27fa-62a8-92be6cd48a6a@labn.net> In-Reply-To: <9fb055da-b280-27fa-62a8-92be6cd48a6a@labn.net> Date: Thu, 2 Feb 2017 13:06:28 -0500 Message-ID: <019001d27d7f$13ce4710$3b6ad530$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDMDDOlqUr6NUq+FONL11ADZxeNCgGvnhE+AZ//NCkDIpJlDQK/OpHKAu3qOW4BzTABPAH9Q1ojAZIxugYBvnoFxgN1SmIToq1mVuA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] What is RFC 7223 style pre-provisioning (was Re: Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:10:59 -0000 Lou:=20 In concept Martin's answer makes sense, but I would just like to see an = example. I could not find an example of the YANG to go with the = NETCONF. If you could either point me to a section in RFC7223 or = provide an example - it would be helpful. What I think I understand = from Martin's message is that the YANG configuration does not have any = "must" or "when" statements in the leaf clause. Is this true? Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Lou Berger Sent: Thursday, February 2, 2017 11:54 AM To: Susan Hares; 'Alia Atlas'; = draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org Subject: [i2rs] What is RFC 7223 style pre-provisioning (was Re: = Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: = (with COMMENT)) Hi Sue, I think Juergen's comment covers what I was referring to. Does this = answer your question / make sense? Cheers, Lou On 2/2/2017 10:14 AM, Juergen Schoenwaelder wrote: > I do not understand your question, but the answer is likely 'no'. > > See Martin's email, perhaps that one helps. > > In RFC 7223, you can configure an interface that is not currently=20 > present. An interface is identified by a name and the interface=20 > configuration sits in the configuration datastore. When an interface=20 > starts to exist (e.g., a line card is inserted) that has a matching=20 > name, then the interface configuration with the same name is applied=20 > to it. This is RFC 7223 style pre-provisioning. > > /js > > On Thu, Feb 02, 2017 at 09:48:26AM -0500, Susan Hares wrote: >> Lou and Juergen:=20 >> >> =20 >> >> Just to make sure I understand the pre-provisioning comment. What = you are referring to is the =E2=80=9Cwhen=E2=80=9D statements in the = clause below.=20 >> >> =20 >> >> augment "/if:interfaces/if:interface" { >> >> when "if:type =3D 'ianaift:ethernetCsmacd'"; >> >> =20 >> >> // operational state parameters for Ethernet interfaces >> augment "/if:interfaces-state/if:interface" { >> when "if:type =3D 'ianaift:ethernetCsmacd'"; >> >> =20 >> >> =20 >> >> Thank you, >> >> Sue Hares >> >> =20 >> >> =20 >> >> =20 >> >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas >> Sent: Wednesday, February 1, 2017 4:14 PM >> To: Lou Berger >> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org;=20 >> iesg@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on=20 >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> =20 >> >> On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger wrote: >> >> >> >> On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote: >>> On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote: >>>> Juergen, >>>> >>>> What precludes treating such dependencies in the same way=20 >>>> per-provisioning is handled by RFC7223? >>>> >>> This is fine. But having direct dependencies, e.g., leafrefs from=20 >>> config true leafs to config false leafs, is not. >>> >>> /js >>> >> Okay, then we're on the same page -- I think some may have missed the = >> possibility of handling references to dynamic topology information in = >> config using a 'pre-provisioning' approach. >> >> =20 >> >> I would be happy to see Alex, Xufeng, Kent & Pavan articulate what=20 >> this would >> >> look like and how it would work for the base topology model, so that=20 >> the WG can >> >> consider all potentially viable options. I'm not certain how it=20 >> would function for the >> >> recursive nature and it does presume the separate /config and=20 >> /oper-state trees in >> >> the data-model that were a concern (though certainly the current=20 >> recommended >> >> approach for YANG models). >> >> =20 >> >> Regards, >> >> Alia >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 2 10:11:18 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC71294C8 for ; Thu, 2 Feb 2017 10:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwCQ7t_4YRvH for ; Thu, 2 Feb 2017 10:11:15 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 3D0611294EE for ; Thu, 2 Feb 2017 10:11:14 -0800 (PST) Received: (qmail 23907 invoked by uid 0); 2 Feb 2017 18:11:09 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 2 Feb 2017 18:11:09 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id fuA61u01a2SSUrH01uA9Ej; Thu, 02 Feb 2017 11:10:10 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=HTX6eUE6J1YLdOzZO40A:9 a=QEXdDO2ut3YA:10 a=QpSsFCxfR6UA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0QUny2JnmMfkCpejpw/vAGelL7AoSjZS6y/zeydfiyI=; b=k1WQL6eacyBCDdcklCyf0B3A4D 1t/Bvz0kh/FPLXc+T5rz5/VVx4CHkaxAO0PpyecSzY+k/4fKAcuWe08iHRWvKLDUvMLIndx171h9D 29LEIuqveWhU8ZUsKNUWL+hxX; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:60142 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cZLpe-0004fe-59; Thu, 02 Feb 2017 11:10:06 -0700 To: Susan Hares , 'Martin Bjorklund' , Xufeng_Liu@jabil.com References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> <20170202.083329.1828765889486608943.mbj@tail-f.com> <20170202.171732.487428777571541086.mbj@tail-f.com> <018e01d27d7e$4ff2cff0$efd86fd0$@ndzh.com> From: Lou Berger Message-ID: Date: Thu, 2 Feb 2017 13:09:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <018e01d27d7e$4ff2cff0$efd86fd0$@ndzh.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cZLpe-0004fe-59 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:60142 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, alexander.clemm@huawei.com, akatlas@gmail.com Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:11:16 -0000 Sue, I think the discussion can take place on one list for now, i.e, I2Rs, and then the results can be brought back to TEAS. I of course defer to my co-chair if he disagrees... Lou As TEAS co-chair. On 2/2/2017 1:00 PM, Susan Hares wrote: > Can add TEAS if Lou or Xufeng desires... From nobody Thu Feb 2 17:38:42 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CCD129612; Thu, 2 Feb 2017 17:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv9vIn6XNxaB; Thu, 2 Feb 2017 17:38:35 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0110.outbound.protection.outlook.com [104.47.37.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C169129A68; Thu, 2 Feb 2017 17:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VMAU0SIpBuTOaZ80E0Uo9KoSaBzaUWk3Cf8Pk++YFd4=; b=IODo+CXSWMv2qLtGGkgcObnhv/d6MbXxnTZea5X81r8oznlQeoPTkNIaX3S095gXF2rNRUXUZXCHDeff/46MrUji95qRBFca0CPXFMUdSh6/lsTvCrcYquFyk6OFHE6kMRPeDwO2izHjvCr4sj0gbd678dr8UAdg9E299vsS5GA= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 3 Feb 2017 01:38:33 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0888.018; Fri, 3 Feb 2017 01:38:33 +0000 From: Kent Watsen To: Xufeng Liu Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/yqRSiXVe4g0u0BDQlaxXyX6FJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAbOUAgAAlhgCAAA+qAIAAOUOA Date: Fri, 3 Feb 2017 01:38:33 +0000 Message-ID: <0D6214AD-503C-4570-BB5E-F0042ABC6641@juniper.net> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> <20170202.083329.1828765889486608943.mbj@tail-f.com> <20170202.171732.487428777571541086.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: b4bb7544-661a-417f-1ee3-08d44bd55da6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:4hZcYY8lf5cvbW2Io4b3OPlOIqGyfKOqAd4sPLzXmwZ0vOjANpS8DjfXBnNgcC4DfazRxfh4X1iGRqWj6GxS2rZ/g1I6g//Az2yVA2H5SvnEikx8pMbyXjfs9cM1X3eiCeKo6/SD4A/JrKb2ia1cwaK9qrbKW3dhoQpm2WK14sOm+osgAkn83m64FCLShGRztbGr2RjnoJ5XyUKnc4az3DD/sUEYLNEt7T6gODznxZ6Aqenfpem9MZiazmPKbE9uxgsD/XGES1pGhU2nK5BT4BG5KnokEqTSWYAajpiXsVUqhKVItaxTv7ulHQZjL4Gf5kJUE4Zfc/kAPz/es65S4/xFnxpMTTvEmm2m1KpeY0gbs8z9gYWUpfeI/LsIG7HLb5jwFPC5qnfjD1sNgXKz8OyWtkcwxxFxT1wz7VFBLXfXHGTlH+Hsn+TjHsVhefjJjRPZaPwWxEwHsVADqs4k+2GK1jT9Wbik4o9F2nPbrYSPDdyM0cKgDhTJEh0pptmUB6kCWqe0ZXopBGobswQlWw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39860400002)(39840400002)(39850400002)(39450400003)(199003)(189002)(3660700001)(86362001)(54356999)(36756003)(50986999)(101416001)(92566002)(122556002)(2900100001)(66066001)(81166006)(6246003)(305945005)(93886004)(7736002)(76176999)(8676002)(106356001)(105586002)(106116001)(33656002)(81156014)(97736004)(230783001)(2906002)(4326007)(82746002)(53936002)(83506001)(189998001)(102836003)(83716003)(4001350100001)(6116002)(8936002)(6486002)(25786008)(6512007)(77096006)(38730400001)(3846002)(6436002)(6916009)(229853002)(6506006)(99286003)(54906002)(68736007)(2950100002)(3280700002)(110136003)(5660300001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 01:38:33.5536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 01:38:40 -0000 W3JlZHVjaW5nIGRpc3RyaWJ1dGlvbl0NCg0KDQpIaSBYdWZlbmcsDQoNCj4gQXNzdW1lIHRoZSBm b2xsb3dpbmcgbW9kZWw6DQo+DQo+ICstLXJ3IG5vZGVzDQo+ICAgKy0tcncgbm9kZSBbaWRdDQo+ ICAgICAgKy0tcncgaWQgICBzdHJpbmcNCj4gICAgICArLS1ydyB1bmRlci1sYXktYXR0cmlidXRl LWEgPz8/DQo+ICstLS1ybyBub2Rlcy1zdGF0ZQ0KPiAgICstLXJvIG5vZGUgW2lkXQ0KPiAgICAg ICstLXJvIGlkICAgc3RyaW5nDQo+ICAgICAgKy0tcm8gYXR0cmlidXRlLWEgc3RyaW5nDQo+DQo+ IEkgY2Fubm90IGRlZmluZSB0aGUgdW5kZXItbGF5LWF0dHJpYnV0ZS1hIHRvIHJlZmVyZW5jZSBh dHRyaWJ1dGUtYSBhczoNCj4gICAgICAgICAgICAgICB0eXBlIGxlYWZyZWYgew0KPiAgICAgICAg ICAgICAgICAgcGF0aCAiLi4vbm9kZS9hdHRyaWJ1dGUtYSInDQo+ICAgICAgICAgICAgICAgfQ0K DQoNClRydWUsIGJ1dCBtYXliZSBpdCBjb3VsZCBiZToNCg0KICAgdHlwZSBsZWFmcmVmIHsNCiAg ICAgIHBhdGggIi4uL25vZGUvYXR0cmlidXRlLWEiDQogICAgICByZXF1aXJlLWluc3RhbmNlIGZh bHNlOw0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIkluIHRoZSBjYXNlIHdoZW4gdGhlIHJl ZmVyZW5jZWQgaW5zdGFuY2UgaXMgbm90IGEgY29uZmlndXJlZA0KICAgICAgICAgb2JqZWN0LCB0 aGUgc3lzdGVtIG1heSByZXNvbHZlIGl0IGJ5IGxvb2tpbmcgZm9yIGl0IHVuZGVyIHRoZQ0KICAg ICAgICAgL25vZGVzLXN0YXRlIG5vZGUuICBBcyB0aGUgcmVmZXJlbmNlZCBvcGVyYXRpb25hbCBz dGF0ZSBkYXRhDQogICAgICAgICBtYXkgaGF2ZSBhIGxpZmVjeWNsZSBpbmRlcGVuZGVudCBvZiBj b25maWd1cmF0aW9uLCB0aGlzIHJlc3VsdHMNCiAgICAgICAgIGluIGFuIGVmZmVjdCBtdWNoIGxp a2UgcHJlLXByb3Zpc2lvbmluZyBpbnRlcmZhY2VzIGluIFJGQyA3MjIzLiI7DQogICB9DQoNClRo aXMgd291bGQgYmUgY2xlYW5lciBpbiBhIHJldmlzZWQtZGF0YXN0b3JlcyBvcmllbnRlZCBtb2Rl bCwgYXMgdGhlbg0KaXQgd291bGQgYmUgb2J2aW91cyB0aGF0IHRoZSBsaXN0J3Mga2V5IHNwYWNl IHNwYW5uZWQgYWNyb3NzIGJvdGgNCmRhdGFzdG9yZXMuDQoNCg0KS2VudA0KDQoNCg== From nobody Fri Feb 3 06:28:35 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D85129648; Fri, 3 Feb 2017 06:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2VG9whm-ZZB; Fri, 3 Feb 2017 06:28:31 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0122.outbound.protection.outlook.com [104.47.40.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6751B129417; Fri, 3 Feb 2017 06:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t1p4Y0oqHCASVF8FnjW3vcl9TdguRtUTKuuOIgNLCWI=; b=LjjrfDhnnD2E3Oakd92Of+ILHHFEn/VyBWt8MIa0Z0MKvPv9SHkhzBNzeP0irUmqCa/qomu0qEY8aByyZUMS3wCmF6X4uRCKJrXHtjMBQ8BdW9P3EQexekqtSSstz8RmC3ErxmWJ0IhCcK/Wu5D8ia811QQcOt01z1a1F9kjZzs= Received: from BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) by BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 14:28:29 +0000 Received: from BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) by BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) with mapi id 15.01.0874.025; Fri, 3 Feb 2017 14:28:29 +0000 From: Xufeng Liu To: Kent Watsen Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/y6tc6V0kTeEi7pAhS6Zp8AqFJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAZlpAgAAsEQCAAAgoYIAAlJeAgADPNaA= Date: Fri, 3 Feb 2017 14:28:28 +0000 Message-ID: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D7EE@SJCEML703-CHM.china.huawei.com> <20170202.083329.1828765889486608943.mbj@tail-f.com> <20170202.171732.487428777571541086.mbj@tail-f.com> <0D6214AD-503C-4570-BB5E-F0042ABC6641@juniper.net> In-Reply-To: <0D6214AD-503C-4570-BB5E-F0042ABC6641@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 6257475c-2388-4168-872c-08d44c40ec4f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR02MB1141; x-microsoft-exchange-diagnostics: 1; BN3PR02MB1141; 7:YpgJ+D8ZDijmVOdwmum0OA4Uh1qfOwxukSalNMJsYWqZxY96Y9XWEwbw4qppbx+uHOz0kOH05d5e3MZYe+832fhu6iZOqXAp7SmKoeTvTjc1NVgLGASOaQyo/gxpiu97CvwblGYWy96oS8CEmDdpCxb7AAzGH6vO9rp4ksPL+/kDTnvFFcQiRgCOrOUzfH2umUe9DaH2CUZoLa8jiE0HmJuwW+Z5RDLfBOlh95Z7sS27zg4HbGpdHoEzItR8PE/4DDbY3YOW7vBjchEazuSMwU3vA/AZcws7parkQosftn10mt7PF1Qsaen0ubhUxq0MZs8cM4LaS7L6RxpiSnsSiCgaiG0akZS9CMA30Twc/AfJ5ITuqGCbopNwkmxKTVFpu3MZyubtO+lWKw+R+QkRXOkT33E7g/bNUSqn8OxuQar+0GSeCZLnY373CPEeE35hcYsVmWOT3DcRQ4Btg/AGLI42W5BcNTXRVYDD8xKNyLm7bApGAs6ls3Xkc3T7EKczWlBfCswAmaV6VNbH55/N5A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR02MB1141; BCL:0; PCL:0; RULEID:; SRVR:BN3PR02MB1141; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(199003)(189002)(51444003)(377454003)(13464003)(25786008)(305945005)(6436002)(99286003)(55016002)(230783001)(54906002)(6506006)(8666007)(38730400001)(2900100001)(2950100002)(77096006)(2906002)(33656002)(93886004)(1941001)(101416001)(74316002)(122556002)(53936002)(9686003)(189998001)(102836003)(3846002)(54356999)(76176999)(50986999)(229853002)(6116002)(8936002)(6246003)(110136003)(3660700001)(97736004)(81156014)(7736002)(80792005)(3280700002)(8676002)(81166006)(106116001)(4326007)(105586002)(106356001)(5660300001)(66066001)(6916009)(86362001)(92566002)(7696004)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR02MB1141; H:BN3PR02MB1141.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 14:28:29.0443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR02MB1141 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:28:34 -0000 SGkgS2VudCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLZW50IFdh dHNlbiBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRdDQo+IFNlbnQ6IFRodXJzZGF5LCBGZWJy dWFyeSAyLCAyMDE3IDg6MzkgUE0NCj4gVG86IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwu Y29tPg0KPiBDYzogaTJyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xv Z3lAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtpMnJzXSBLYXRobGVlbiBNb3JpYXJ0eSdzIE5v IE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy0NCj4gdG9wb2xvZ3ktMDg6ICh3 aXRoIENPTU1FTlQpDQo+IA0KPiBbcmVkdWNpbmcgZGlzdHJpYnV0aW9uXQ0KPiANCj4gDQo+IEhp IFh1ZmVuZywNCj4gDQo+ID4gQXNzdW1lIHRoZSBmb2xsb3dpbmcgbW9kZWw6DQo+ID4NCj4gPiAr LS1ydyBub2Rlcw0KPiA+ICAgKy0tcncgbm9kZSBbaWRdDQo+ID4gICAgICArLS1ydyBpZCAgIHN0 cmluZw0KPiA+ICAgICAgKy0tcncgdW5kZXItbGF5LWF0dHJpYnV0ZS1hID8/Pw0KPiA+ICstLS1y byBub2Rlcy1zdGF0ZQ0KPiA+ICAgKy0tcm8gbm9kZSBbaWRdDQo+ID4gICAgICArLS1ybyBpZCAg IHN0cmluZw0KPiA+ICAgICAgKy0tcm8gYXR0cmlidXRlLWEgc3RyaW5nDQo+ID4NCj4gPiBJIGNh bm5vdCBkZWZpbmUgdGhlIHVuZGVyLWxheS1hdHRyaWJ1dGUtYSB0byByZWZlcmVuY2UgYXR0cmli dXRlLWEgYXM6DQo+ID4gICAgICAgICAgICAgICB0eXBlIGxlYWZyZWYgew0KPiA+ICAgICAgICAg ICAgICAgICBwYXRoICIuLi9ub2RlL2F0dHJpYnV0ZS1hIicNCj4gPiAgICAgICAgICAgICAgIH0N Cj4gDQo+IA0KPiBUcnVlLCBidXQgbWF5YmUgaXQgY291bGQgYmU6DQo+IA0KPiAgICB0eXBlIGxl YWZyZWYgew0KPiAgICAgICBwYXRoICIuLi9ub2RlL2F0dHJpYnV0ZS1hIg0KPiAgICAgICByZXF1 aXJlLWluc3RhbmNlIGZhbHNlOw0KPiAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICJJbiB0 aGUgY2FzZSB3aGVuIHRoZSByZWZlcmVuY2VkIGluc3RhbmNlIGlzIG5vdCBhIGNvbmZpZ3VyZWQN Cj4gICAgICAgICAgb2JqZWN0LCB0aGUgc3lzdGVtIG1heSByZXNvbHZlIGl0IGJ5IGxvb2tpbmcg Zm9yIGl0IHVuZGVyIHRoZQ0KPiAgICAgICAgICAvbm9kZXMtc3RhdGUgbm9kZS4gIEFzIHRoZSBy ZWZlcmVuY2VkIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGENCj4gICAgICAgICAgbWF5IGhhdmUgYSBs aWZlY3ljbGUgaW5kZXBlbmRlbnQgb2YgY29uZmlndXJhdGlvbiwgdGhpcyByZXN1bHRzDQo+ICAg ICAgICAgIGluIGFuIGVmZmVjdCBtdWNoIGxpa2UgcHJlLXByb3Zpc2lvbmluZyBpbnRlcmZhY2Vz IGluIFJGQyA3MjIzLiI7DQo+ICAgIH0NCltYdWZlbmddIEkgdGhpbmsgdGhhdCAicmVxdWlyZS1p bnN0YW5jZSBmYWxzZSIgZG9lcyBub3QgaGVscCBoZXJlLiBUaGUgdmFsaWRhdGlvbiBmb3IgcGF0 aCAiLi4vbm9kZS9hdHRyaWJ1dGUtYSIgc3RpbGwgZmFpbHMgYmVjYXVzZSAiYXR0cmlidXRlLWEi IGRvZXMgbm90IGV4aXN0IHVuZGVyIC9ub2Rlcy9ub2RlLy4gDQoNCj4gDQo+IFRoaXMgd291bGQg YmUgY2xlYW5lciBpbiBhIHJldmlzZWQtZGF0YXN0b3JlcyBvcmllbnRlZCBtb2RlbCwgYXMgdGhl biBpdCB3b3VsZA0KPiBiZSBvYnZpb3VzIHRoYXQgdGhlIGxpc3QncyBrZXkgc3BhY2Ugc3Bhbm5l ZCBhY3Jvc3MgYm90aCBkYXRhc3RvcmVzLg0KPiANCj4gDQo+IEtlbnQNCj4gDQoNCg== From nobody Fri Feb 3 07:32:26 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E67129C0E; Fri, 3 Feb 2017 07:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 Y5vg6hs_a4UN; Fri, 3 Feb 2017 07:32:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD91C129BC9; Fri, 3 Feb 2017 07:32:22 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id B92711AE012C; Fri, 3 Feb 2017 16:32:16 +0100 (CET) Date: Fri, 03 Feb 2017 16:32:16 +0100 (CET) Message-Id: <20170203.163216.1400419881696462638.mbj@tail-f.com> To: Xufeng_Liu@jabil.com From: Martin Bjorklund In-Reply-To: References: <0D6214AD-503C-4570-BB5E-F0042ABC6641@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 15:32:24 -0000 Hi, Xufeng Liu wrote: > Hi Kent, > > > -----Original Message----- > > From: Kent Watsen [mailto:kwatsen@juniper.net] > > Sent: Thursday, February 2, 2017 8:39 PM > > To: Xufeng Liu > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3- > > topology-08: (with COMMENT) > > > > [reducing distribution] > > > > > > Hi Xufeng, > > > > > Assume the following model: > > > > > > +--rw nodes > > > +--rw node [id] > > > +--rw id string > > > +--rw under-lay-attribute-a ??? > > > +---ro nodes-state > > > +--ro node [id] > > > +--ro id string > > > +--ro attribute-a string > > > > > > I cannot define the under-lay-attribute-a to reference attribute-a as: > > > type leafref { > > > path "../node/attribute-a"' > > > } > > > > > > True, but maybe it could be: > > > > type leafref { > > path "../node/attribute-a" > > require-instance false; > > description > > "In the case when the referenced instance is not a configured > > object, the system may resolve it by looking for it under the > > /nodes-state node. As the referenced operational state data > > may have a lifecycle independent of configuration, this results > > in an effect much like pre-provisioning interfaces in RFC 7223."; > > } > [Xufeng] I think that "require-instance false" does not help here. The > validation for path "../node/attribute-a" still fails because > "attribute-a" does not exist under /nodes/node/. No, "require-instance false" essentially turns off validation. Section 9.9.3 in RFC 7950 says: If "require-instance" is "false", it means that the instance being referred to MAY exist in valid data. /martin From nobody Fri Feb 3 07:51:07 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14C1129C3A; Fri, 3 Feb 2017 07:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihf7ZWYvpxZx; Fri, 3 Feb 2017 07:50:59 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA63129C73; Fri, 3 Feb 2017 07:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NWj7u4hvoLIVizrhBIDx6XX3LpmSOX6h4EJvVhMvTg4=; b=lyLEkqPNzckYgYZg13i+O8rX2tq1xNJNnW23J7EUIVCuae6vMb/fOEnklM/C+bKoDmj8pFBakeR19VamKT11aqsHQpXd7Uf33hsKKJZXAcTdGgr7gJ8qO18D99mZdJ81UbMphhtaQT8bSt7a1umenmvhee41orW4a1W/odwzfzE= Received: from BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) by BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 15:50:57 +0000 Received: from BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) by BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) with mapi id 15.01.0874.025; Fri, 3 Feb 2017 15:50:57 +0000 From: Xufeng Liu To: Martin Bjorklund Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/y6tc6V0kTeEi7pAhS6Zp8AqFJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAZlpAgAAsEQCAAAgoYIAAlJeAgADPNaCAABm7AIAAAqRg Date: Fri, 3 Feb 2017 15:50:57 +0000 Message-ID: References: <0D6214AD-503C-4570-BB5E-F0042ABC6641@juniper.net> <20170203.163216.1400419881696462638.mbj@tail-f.com> In-Reply-To: <20170203.163216.1400419881696462638.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 3e776300-14a4-4d68-ac5b-08d44c4c71b1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR02MB1141; x-microsoft-exchange-diagnostics: 1; BN3PR02MB1141; 7:whVKmblj3uHqWSrG/lgQdBBb43ZkkBHCU0UbdxhYPsfAxof9AtOWqvBR/a0/tKOpeeTbhqUhd3a4Fc8jneUv7MF0c4ygSWwjdUkW6xBFKkvcKWAMt51DpLjoe2ph5J7YWlRipfKznzo4hi4EanMxlO2oRpWIBj94Wcsl4kHR25BnGTr4rUn4Fv636ME3r025IHYfZUxQkXWxxSpWjPi0Cvz/kdIh8/Zof/KYof3ZeX0ps9Ta42P2J1O0j/fAk93RGt50fQx1NYsJmtjpyr/z5t4H9u3+IY4m9u1WlxSYXEp2CzDNinnhps94Cq+Oe8fUPYZPNKQoc3DMbbj7S7pkS7PNL84H2JcRllMBoNiuDJTrcG57h23hMKnkKWHAWueBEn7ZVJRdg23iZJtRaPFL6zEn88P/AHYHQkFV0LIANX57yYC53D7X/0cgWDRx77+AGUEiAJu0AvetRd1ptlu9uSHWFKqceTr0hwkuUlqm6hgG6U+NeOUWbdK/7CEWxI6lh1LgyPF/OZrZI3oxkLYR1w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR02MB1141; BCL:0; PCL:0; RULEID:; SRVR:BN3PR02MB1141; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39850400002)(39860400002)(39840400002)(199003)(189002)(51444003)(377454003)(13464003)(24454002)(25786008)(6436002)(305945005)(99286003)(55016002)(230783001)(54906002)(6506006)(8666007)(38730400001)(2900100001)(2950100002)(77096006)(33656002)(2906002)(93886004)(101416001)(74316002)(122556002)(53936002)(9686003)(189998001)(102836003)(3846002)(76176999)(54356999)(50986999)(229853002)(6116002)(6246003)(8936002)(110136003)(3660700001)(97736004)(81156014)(3280700002)(7736002)(80792005)(8676002)(81166006)(106116001)(4326007)(105586002)(106356001)(5660300001)(66066001)(6916009)(92566002)(86362001)(7696004)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR02MB1141; H:BN3PR02MB1141.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 15:50:57.2325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR02MB1141 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" , "kwatsen@juniper.net" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 15:51:02 -0000 Hi, > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Friday, February 3, 2017 10:32 AM > To: Xufeng Liu > Cc: kwatsen@juniper.net; draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-y= ang-l3- > topology-08: (with COMMENT) >=20 > Hi, >=20 >=20 > Xufeng Liu wrote: > > Hi Kent, > > > > > -----Original Message----- > > > From: Kent Watsen [mailto:kwatsen@juniper.net] > > > Sent: Thursday, February 2, 2017 8:39 PM > > > To: Xufeng Liu > > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3- > > > topology-08: (with COMMENT) > > > > > > [reducing distribution] > > > > > > > > > Hi Xufeng, > > > > > > > Assume the following model: > > > > > > > > +--rw nodes > > > > +--rw node [id] > > > > +--rw id string > > > > +--rw under-lay-attribute-a ??? > > > > +---ro nodes-state > > > > +--ro node [id] > > > > +--ro id string > > > > +--ro attribute-a string > > > > > > > > I cannot define the under-lay-attribute-a to reference attribute-a = as: > > > > type leafref { > > > > path "../node/attribute-a"' > > > > } > > > > > > > > > True, but maybe it could be: > > > > > > type leafref { > > > path "../node/attribute-a" > > > require-instance false; > > > description > > > "In the case when the referenced instance is not a configured > > > object, the system may resolve it by looking for it under th= e > > > /nodes-state node. As the referenced operational state data > > > may have a lifecycle independent of configuration, this resu= lts > > > in an effect much like pre-provisioning interfaces in RFC 72= 23."; > > > } > > [Xufeng] I think that "require-instance false" does not help here. The > > validation for path "../node/attribute-a" still fails because > > "attribute-a" does not exist under /nodes/node/. >=20 > No, "require-instance false" essentially turns off validation. Section > 9.9.3 in RFC 7950 says: >=20 > If "require-instance" is "false", it means that the instance being > referred to MAY exist in valid data. >=20 [Xufeng] My understanding is that this section talks about instance "data" = validation, but I was talking about schema validation. The path statement i= s pointing to a non-existing schema node. At least, pyang, yangdump, and ya= ngvalidator all fail on this currently. >=20 > /martin From nobody Fri Feb 3 08:08:07 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EE812965D; Fri, 3 Feb 2017 08:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 6obArafjy_b1; Fri, 3 Feb 2017 08:08:03 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4178012966E; Fri, 3 Feb 2017 08:08:02 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 9416D1AE012C; Fri, 3 Feb 2017 17:08:00 +0100 (CET) Date: Fri, 03 Feb 2017 17:08:00 +0100 (CET) Message-Id: <20170203.170800.1259525494650193374.mbj@tail-f.com> To: Xufeng_Liu@jabil.com From: Martin Bjorklund In-Reply-To: References: <20170203.163216.1400419881696462638.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:08:07 -0000 Xufeng Liu wrote: > Hi, > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Friday, February 3, 2017 10:32 AM > > To: Xufeng Liu > > Cc: kwatsen@juniper.net; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > i2rs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3- > > topology-08: (with COMMENT) > > > > Hi, > > > > > > Xufeng Liu wrote: > > > Hi Kent, > > > > > > > -----Original Message----- > > > > From: Kent Watsen [mailto:kwatsen@juniper.net] > > > > Sent: Thursday, February 2, 2017 8:39 PM > > > > To: Xufeng Liu > > > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3- > > > > topology-08: (with COMMENT) > > > > > > > > [reducing distribution] > > > > > > > > > > > > Hi Xufeng, > > > > > > > > > Assume the following model: > > > > > > > > > > +--rw nodes > > > > > +--rw node [id] > > > > > +--rw id string > > > > > +--rw under-lay-attribute-a ??? > > > > > +---ro nodes-state > > > > > +--ro node [id] > > > > > +--ro id string > > > > > +--ro attribute-a string > > > > > > > > > > I cannot define the under-lay-attribute-a to reference attribute-a as: > > > > > type leafref { > > > > > path "../node/attribute-a"' > > > > > } > > > > > > > > > > > > True, but maybe it could be: > > > > > > > > type leafref { > > > > path "../node/attribute-a" > > > > require-instance false; > > > > description > > > > "In the case when the referenced instance is not a configured > > > > object, the system may resolve it by looking for it under the > > > > /nodes-state node. As the referenced operational state data > > > > may have a lifecycle independent of configuration, this results > > > > in an effect much like pre-provisioning interfaces in RFC > > > > 7223."; > > > > } > > > [Xufeng] I think that "require-instance false" does not help here. The > > > validation for path "../node/attribute-a" still fails because > > > "attribute-a" does not exist under /nodes/node/. > > > > No, "require-instance false" essentially turns off validation. > > Section > > 9.9.3 in RFC 7950 says: > > > > If "require-instance" is "false", it means that the instance being > > referred to MAY exist in valid data. > > > [Xufeng] My understanding is that this section talks about instance > "data" validation, but I was talking about schema validation. The path > statement is pointing to a non-existing schema node. Aha, ok. Yes, the path needs to refer to a valid schema node. So the path would be /nodes-state/node/attribute-a. > At least, pyang, > yangdump, and yangvalidator all fail on this currently. /martin From nobody Fri Feb 3 08:11:05 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC19A129662; Fri, 3 Feb 2017 08:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 Ztjk6pYSoSYS; Fri, 3 Feb 2017 08:11:01 -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 E6A3F12946B; Fri, 3 Feb 2017 08:11:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C02A7782; Fri, 3 Feb 2017 17:10:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nJkR9tLoTUJj; Fri, 3 Feb 2017 17:10:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 3 Feb 2017 17:10:59 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EF92200AD; Fri, 3 Feb 2017 17:10:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IVjY3dcvMBzh; Fri, 3 Feb 2017 17:10:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35862200AB; Fri, 3 Feb 2017 17:10:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 54B6A3E66242; Fri, 3 Feb 2017 17:11:01 +0100 (CET) Date: Fri, 3 Feb 2017 17:11:00 +0100 From: Juergen Schoenwaelder To: Xufeng Liu Message-ID: <20170203161100.GA87190@elstar.local> Mail-Followup-To: Xufeng Liu , Martin Bjorklund , "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" , "kwatsen@juniper.net" References: <0D6214AD-503C-4570-BB5E-F0042ABC6641@juniper.net> <20170203.163216.1400419881696462638.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" , Martin Bjorklund , "kwatsen@juniper.net" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:11:03 -0000 On Fri, Feb 03, 2017 at 03:50:57PM +0000, Xufeng Liu wrote: > Hi, > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Friday, February 3, 2017 10:32 AM > > To: Xufeng Liu > > Cc: kwatsen@juniper.net; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > i2rs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3- > > topology-08: (with COMMENT) > > > > Hi, > > > > > > Xufeng Liu wrote: > > > Hi Kent, > > > > > > > -----Original Message----- > > > > From: Kent Watsen [mailto:kwatsen@juniper.net] > > > > Sent: Thursday, February 2, 2017 8:39 PM > > > > To: Xufeng Liu > > > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3- > > > > topology-08: (with COMMENT) > > > > > > > > [reducing distribution] > > > > > > > > > > > > Hi Xufeng, > > > > > > > > > Assume the following model: > > > > > > > > > > +--rw nodes > > > > > +--rw node [id] > > > > > +--rw id string > > > > > +--rw under-lay-attribute-a ??? > > > > > +---ro nodes-state > > > > > +--ro node [id] > > > > > +--ro id string > > > > > +--ro attribute-a string > > > > > > > > > > I cannot define the under-lay-attribute-a to reference attribute-a as: > > > > > type leafref { > > > > > path "../node/attribute-a"' > > > > > } > > > > > > > > > > > > True, but maybe it could be: > > > > > > > > type leafref { > > > > path "../node/attribute-a" > > > > require-instance false; > > > > description > > > > "In the case when the referenced instance is not a configured > > > > object, the system may resolve it by looking for it under the > > > > /nodes-state node. As the referenced operational state data > > > > may have a lifecycle independent of configuration, this results > > > > in an effect much like pre-provisioning interfaces in RFC 7223."; > > > > } > > > [Xufeng] I think that "require-instance false" does not help here. The > > > validation for path "../node/attribute-a" still fails because > > > "attribute-a" does not exist under /nodes/node/. > > > > No, "require-instance false" essentially turns off validation. Section > > 9.9.3 in RFC 7950 says: > > > > If "require-instance" is "false", it means that the instance being > > referred to MAY exist in valid data. > > > [Xufeng] My understanding is that this section talks about instance "data" validation, but I was talking about schema validation. The path statement is pointing to a non-existing schema node. At least, pyang, yangdump, and yangvalidator all fail on this currently. Yes, the example is confusing. If the idea was that the path would be ../node/under-lay-attribute-a then I find the description questionable since the leafref is restricted to ../node/under-lay-attribute-a but the description says go look elsewhere. Perhaps I need an even simpler example. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 3 08:16:56 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51F112966F; Fri, 3 Feb 2017 08:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAc7yj7swR8D; Fri, 3 Feb 2017 08:16:45 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0122.outbound.protection.outlook.com [104.47.42.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9BC1295DC; Fri, 3 Feb 2017 08:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b3SMtLz9wR+9GD3VlbO4/7qO5azhwZKlQuau5qdr4Gk=; b=qCG88PBAIbgMGr6vCDKHHxulPjnjGc7Yf6ATFPpgvY0JrPuBuB2nONDy17un/vv9IB8LPQ3EX52cDvWeDF8+pMvO5xF+2NxqmE2PggCZZ53yEgqMju43zX83x9HRvzipwlvhcf1n1YqGJk1Zw/f+Vi71qzT/eySCecTUACKiOag= Received: from BN3PR02MB1141.namprd02.prod.outlook.com (10.162.168.147) by BN3PR02MB1143.namprd02.prod.outlook.com (10.162.168.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Fri, 3 Feb 2017 16:16:43 +0000 Received: from BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) by BN3PR02MB1141.namprd02.prod.outlook.com ([10.162.168.147]) with mapi id 15.01.0874.025; Fri, 3 Feb 2017 16:16:43 +0000 From: Xufeng Liu To: Martin Bjorklund Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/y6tc6V0kTeEi7pAhS6Zp8AqFJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAZlpAgAAsEQCAAAgoYIAAlJeAgADPNaCAABm7AIAAAqRggAAHWACAAAFgcA== Date: Fri, 3 Feb 2017 16:16:43 +0000 Message-ID: References: <20170203.163216.1400419881696462638.mbj@tail-f.com> <20170203.170800.1259525494650193374.mbj@tail-f.com> In-Reply-To: <20170203.170800.1259525494650193374.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: c7913fac-e7ba-4bf1-1a9d-08d44c500b22 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR02MB1143; x-microsoft-exchange-diagnostics: 1; BN3PR02MB1143; 7:fyLspdynyDdiprtrJCucIE8OTfSu3UiknNQugdgBI/wSArygEuRxE5ZILbwM5nE52HKEMx7aA/EOLqLDAZbIdr+hUYeB0orJCxF8b8Jmth7Kkb3XePswUuhbjt6hf/rwH/i0qU6J3xW4B3owudG8Ak51Q0TFSDQK1YChu7/oisGP/QVcwgenj3e2bYoiAJ1LjSF6pFbOP6AQHuLN8mC2MlEuK54l5tfDdzb84jwSBIsCdl0B1k3iuYhEwmKHcWNxqbjF89KcZFRcTA5hjlHYhZhVTCmkcIZZ8v/dFM2FeUfV5+TYR7C7+Ssy552EHVq18iTV45JYRzf9PUdr6GCWBX1hL8FpS/TEc8GSINsD5OJ6HNtGW7yB8d8f0h7Hedxg2J5HsroSyfD0+OCeGsU3v2RA/rPYE+hVd9ivqvgNLv+z2iFy45CXmw0yVul9Ao9IpZcR3qWJEo/0yXnea6dhZofLGJ6ghI2p3goEY7nCb2YYMgthiq0Znf3x8g+wfQy7xNEbLt02jKlEL3n0srCArw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR02MB1143; BCL:0; PCL:0; RULEID:; SRVR:BN3PR02MB1143; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39410400002)(39840400002)(39450400003)(51444003)(13464003)(377454003)(199003)(24454002)(189002)(66066001)(6116002)(3846002)(102836003)(2900100001)(4326007)(305945005)(6506006)(8936002)(7736002)(53936002)(92566002)(8666007)(8676002)(77096006)(9686003)(6436002)(86362001)(229853002)(25786008)(81156014)(99286003)(55016002)(81166006)(54906002)(74316002)(68736007)(3660700001)(76176999)(2906002)(33656002)(106116001)(2950100002)(6916009)(110136003)(54356999)(50986999)(7696004)(3280700002)(38730400001)(101416001)(5660300001)(122556002)(106356001)(105586002)(93886004)(97736004)(189998001)(230783001)(6246003)(80792005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR02MB1143; H:BN3PR02MB1141.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 16:16:43.2470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR02MB1143 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" , "kwatsen@juniper.net" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:16:55 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Friday, February 3, 2017 11:08 AM > To: Xufeng Liu > Cc: kwatsen@juniper.net; draft-ietf-i2rs-yang-l3-topology@ietf.org; > i2rs@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-y= ang-l3- > topology-08: (with COMMENT) >=20 > Xufeng Liu wrote: > > Hi, > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Friday, February 3, 2017 10:32 AM > > > To: Xufeng Liu > > > Cc: kwatsen@juniper.net; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > i2rs@ietf.org > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3- > > > topology-08: (with COMMENT) > > > > > > Hi, > > > > > > > > > Xufeng Liu wrote: > > > > Hi Kent, > > > > > > > > > -----Original Message----- > > > > > From: Kent Watsen [mailto:kwatsen@juniper.net] > > > > > Sent: Thursday, February 2, 2017 8:39 PM > > > > > To: Xufeng Liu > > > > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > draft-ietf-i2rs-yang-l3- > > > > > topology-08: (with COMMENT) > > > > > > > > > > [reducing distribution] > > > > > > > > > > > > > > > Hi Xufeng, > > > > > > > > > > > Assume the following model: > > > > > > > > > > > > +--rw nodes > > > > > > +--rw node [id] > > > > > > +--rw id string > > > > > > +--rw under-lay-attribute-a ??? > > > > > > +---ro nodes-state > > > > > > +--ro node [id] > > > > > > +--ro id string > > > > > > +--ro attribute-a string > > > > > > > > > > > > I cannot define the under-lay-attribute-a to reference attribut= e-a as: > > > > > > type leafref { > > > > > > path "../node/attribute-a"' > > > > > > } > > > > > > > > > > > > > > > True, but maybe it could be: > > > > > > > > > > type leafref { > > > > > path "../node/attribute-a" > > > > > require-instance false; > > > > > description > > > > > "In the case when the referenced instance is not a config= ured > > > > > object, the system may resolve it by looking for it unde= r the > > > > > /nodes-state node. As the referenced operational state = data > > > > > may have a lifecycle independent of configuration, this = results > > > > > in an effect much like pre-provisioning interfaces in RF= C > > > > > 7223."; > > > > > } > > > > [Xufeng] I think that "require-instance false" does not help here. > > > > The validation for path "../node/attribute-a" still fails because > > > > "attribute-a" does not exist under /nodes/node/. > > > > > > No, "require-instance false" essentially turns off validation. > > > Section > > > 9.9.3 in RFC 7950 says: > > > > > > If "require-instance" is "false", it means that the instance being > > > referred to MAY exist in valid data. > > > > > [Xufeng] My understanding is that this section talks about instance > > "data" validation, but I was talking about schema validation. The path > > statement is pointing to a non-existing schema node. >=20 > Aha, ok. Yes, the path needs to refer to a valid schema node. So the pa= th would > be /nodes-state/node/attribute-a. >=20 [Xufeng] Right. If we do so, the approach will be different from RFC7223, a= nd requires the capability that a "config true" leafref references a "confi= g false" leaf. > > At least, pyang, > > yangdump, and yangvalidator all fail on this currently. >=20 >=20 > /martin From nobody Fri Feb 3 09:43:47 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F71294A6; Fri, 3 Feb 2017 09:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 gfi5pk44FREd; Fri, 3 Feb 2017 09:43:45 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id ED62312944B; Fri, 3 Feb 2017 09:43:44 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id F15871AE012C; Fri, 3 Feb 2017 18:43:42 +0100 (CET) Date: Fri, 03 Feb 2017 18:43:42 +0100 (CET) Message-Id: <20170203.184342.405194345934698538.mbj@tail-f.com> To: Xufeng_Liu@jabil.com From: Martin Bjorklund In-Reply-To: References: <20170203.170800.1259525494650193374.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:43:46 -0000 Xufeng Liu wrote: > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Friday, February 3, 2017 11:08 AM > > To: Xufeng Liu > > Cc: kwatsen@juniper.net; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > i2rs@ietf.org > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3- > > topology-08: (with COMMENT) > > > > Xufeng Liu wrote: > > > Hi, > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: Friday, February 3, 2017 10:32 AM > > > > To: Xufeng Liu > > > > Cc: kwatsen@juniper.net; draft-ietf-i2rs-yang-l3-topology@ietf.org; > > > > i2rs@ietf.org > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3- > > > > topology-08: (with COMMENT) > > > > > > > > Hi, > > > > > > > > > > > > Xufeng Liu wrote: > > > > > Hi Kent, > > > > > > > > > > > -----Original Message----- > > > > > > From: Kent Watsen [mailto:kwatsen@juniper.net] > > > > > > Sent: Thursday, February 2, 2017 8:39 PM > > > > > > To: Xufeng Liu > > > > > > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > draft-ietf-i2rs-yang-l3- > > > > > > topology-08: (with COMMENT) > > > > > > > > > > > > [reducing distribution] > > > > > > > > > > > > > > > > > > Hi Xufeng, > > > > > > > > > > > > > Assume the following model: > > > > > > > > > > > > > > +--rw nodes > > > > > > > +--rw node [id] > > > > > > > +--rw id string > > > > > > > +--rw under-lay-attribute-a ??? > > > > > > > +---ro nodes-state > > > > > > > +--ro node [id] > > > > > > > +--ro id string > > > > > > > +--ro attribute-a string > > > > > > > > > > > > > > I cannot define the under-lay-attribute-a to reference attribute-a as: > > > > > > > type leafref { > > > > > > > path "../node/attribute-a"' > > > > > > > } > > > > > > > > > > > > > > > > > > True, but maybe it could be: > > > > > > > > > > > > type leafref { > > > > > > path "../node/attribute-a" > > > > > > require-instance false; > > > > > > description > > > > > > "In the case when the referenced instance is not a configured > > > > > > object, the system may resolve it by looking for it under the > > > > > > /nodes-state node. As the referenced operational state data > > > > > > may have a lifecycle independent of configuration, this results > > > > > > in an effect much like pre-provisioning interfaces in RFC > > > > > > 7223."; > > > > > > } > > > > > [Xufeng] I think that "require-instance false" does not help here. > > > > > The validation for path "../node/attribute-a" still fails because > > > > > "attribute-a" does not exist under /nodes/node/. > > > > > > > > No, "require-instance false" essentially turns off validation. > > > > Section > > > > 9.9.3 in RFC 7950 says: > > > > > > > > If "require-instance" is "false", it means that the instance being > > > > referred to MAY exist in valid data. > > > > > > > [Xufeng] My understanding is that this section talks about instance > > > "data" validation, but I was talking about schema validation. The path > > > statement is pointing to a non-existing schema node. > > > > Aha, ok. Yes, the path needs to refer to a valid schema node. So the path would > > be /nodes-state/node/attribute-a. > > > [Xufeng] Right. If we do so, the approach will be different from > RFC7223, and requires the capability that a "config true" leafref > references a "config false" leaf. You don't need any additional capability for this; if you tag the leafref with "require-instance false", it can reference config false (from config true). /martin From nobody Fri Feb 3 10:11:35 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEE31293FB; Fri, 3 Feb 2017 10:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyylEAJXWbmf; Fri, 3 Feb 2017 10:11:31 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E0412948B; Fri, 3 Feb 2017 10:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T6AKuowYQvRv5XgaKKT6rOmkiIKdlYsy2643IuigwzY=; b=TGBNDPa3KPSrY/ldg6JuH1QmdPAWEhm/qNw8oUC2SYDCXN+T3KPBdMRuwtLCUC3ocG1DLOcaluY1wOAk6zNK9POpr7AFZXMUQV1IeHa6Tejqwqz96r+3DjnEI3GL1CRjpvONftzE92Yxo4keonpsRCGLFvU/NpWe1GQIZerRuqs= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 3 Feb 2017 18:11:30 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0888.018; Fri, 3 Feb 2017 18:11:30 +0000 From: Kent Watsen To: Xufeng Liu , Martin Bjorklund Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/yqRSiXVe4g0u0BDQlaxXyX6FJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAbOUAgAAlhgCAAA+qAIAAOUOAgAEq7wCAABHTAIAABTiAgAAExACAAAJvgP//zECA Date: Fri, 3 Feb 2017 18:11:30 +0000 Message-ID: <030B0A7E-5238-4D78-BC97-2140B269D82A@juniper.net> References: <20170203.163216.1400419881696462638.mbj@tail-f.com> <20170203.170800.1259525494650193374.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 92b5a182-cae0-4144-c180-08d44c60144d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:1oiGmJ6eqc3h9HZlAjgbFZ2gY3cZQUpU0b2QIcD9WTqf7NISHeoyq1uYir/JRBZhbIck2pf7BGlBJ+wcUr/rwOLWv3gSoGEL6hvc+1PV8R9NaeH7oTXfKyAQpmySiTyKLXzgF7QORcAUe+ZtoO5PA0rKS0uOa9pfKBdo4AmzUP4Qiatjjog5yrkaKqtLctOUKAuTTLxqMem1g7Qv5Xh+q/25cBKW+CX20gBcJ+fPHijN2qZrguqkGuJeRxyK7nVfdivU4UgUxg2VSRourDf2kkoM28KX8+2uG2jV8WAR63v3bWFZAt92DezE42SeAj5JGMfnZP32um65cGSrX5H6pjKfh5tSL5bkuaTNpnlqcGaFf5szGGxg/wCzs4JbVfDiY51wqjwcYCIbUjBeyECDVuyFQFLEu4Nf0+Sn/vjSswmvJ/K9mBNhHnX7Fcd5roxtbkArwVymgNFU0ldsKIn2GgDz2Q0SiK4Ewae2S21wjFHg54RPIioQw+aeAVfh3MGlUYruUI5EXHbIqT8kazVLVA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(189002)(199003)(52314003)(189998001)(2906002)(4001350100001)(4326007)(97736004)(66066001)(6116002)(2900100001)(5001770100001)(93886004)(36756003)(561944003)(230783001)(92566002)(3846002)(229853002)(6506006)(102836003)(38730400001)(33656002)(54906002)(86362001)(6512007)(3280700002)(25786008)(6486002)(68736007)(3660700001)(82746002)(83716003)(77096006)(83506001)(6436002)(99286003)(122556002)(81166006)(50986999)(76176999)(53936002)(305945005)(7736002)(8676002)(81156014)(54356999)(5660300001)(101416001)(2950100002)(105586002)(8936002)(106116001)(6246003)(106356001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 18:11:30.6433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:11:33 -0000 DQpbWHVmZW5nXSBSaWdodC4gSWYgd2UgZG8gc28sIHRoZSBhcHByb2FjaCB3aWxsIGJlIGRpZmZl cmVudCBmcm9tIFJGQzcyMjMsIGFuZCByZXF1aXJlcyB0aGUgY2FwYWJpbGl0eSB0aGF0IGEgImNv bmZpZyB0cnVlIiBsZWFmcmVmIHJlZmVyZW5jZXMgYSAiY29uZmlnIGZhbHNlIiBsZWFmLg0KDQoN CkkgdGhpbmsgbXkgcHJvcG9zYWwgd2FzIG1pc3VuZGVyc3Rvb2QsIHNvIGhlcmUncyBhIG1vcmUg Y29tcGxldGUgZXhhbXBsZToNCg0KQXNzdW1lIHRoZSBmb2xsb3dpbmcgc2NoZW1hIGlzIHVzZWQg YnkgY2xpZW50L3NlcnZlcnMgdGhhdCBpbXBsZW1lbnQgdGhlIGxvbmctdGVybQ0Kb3BzdGF0ZSBz b2x1dGlvbiBwcmVzZW50ZWQgaW4gdGhlIHJldmlzZWQtZGF0YXN0b3JlcyBkcmFmdDoNCg0KICAg bW9kdWxlIGZvbyB7DQogICAgICBjb250YWluZXIgbm9kZXMgew0KICAgICAgICAgY29uZmlnIHRy dWU7DQogICAgICAgICBsaXN0IG5vZGUgew0KICAgICAgICAgICAga2V5ICJuYW1lIjsNCiAgICAg ICAgICAgIGxlYWYgbmFtZSB7IHR5cGUgc3RyaW5nOyB9DQogICAgICAgICAgICBsZWFmIGRlcGVu ZGVuY3kgew0KICAgICAgICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCiAgICAgICAgICAgICAgICAg cGF0aCAiLi4vbm9kZS9uYW1lIg0KICAgICAgICAgICAgICAgICByZXF1aXJlLWluc3RhbmNlIGZh bHNlOw0KICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgICJJ biB0aGUgY2FzZSB3aGVuIGEgY29uZmlndXJlZCBub2RlIChpLmUuIGluIHRoZSBydW5uaW5nIERT KQ0KICAgICAgICAgICAgICAgICAgICBoYXMgYSBkZXBlbmRlbmN5IG9uIGEgbm9kZSB0aGF0IGlz IG5vdCBjb25maWd1cmVkLCB0aGUgc3lzdGVtDQogICAgICAgICAgICAgICAgICAgIG1heSB0cnkg dG8gcmVzb2x2ZSB0aGUgZGVwZW5kZW5jeSBhcyBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhDQogICAg ICAgICAgICAgICAgICAgIChpLmUuIGluIHRoZSBvcGVyYXRpb25hbC1zdGF0ZSBEUykuICBBcyBv cGVyYXRpb25hbCBzdGF0ZSANCiAgICAgICAgICAgICAgICAgICAgZGF0YSBtYXkgaGF2ZSBhIGxp ZmVjeWNsZSBpbmRlcGVuZGVudCBvZiBjb25maWd1cmF0aW9uLCB0aGVyZQ0KICAgICAgICAgICAg ICAgICAgICBpcyBubyBndWFyYW50ZWUgdGhhdCB0aGUgb3BzdGF0ZSBkYXRhIHdpbGwgZXhpc3Qu ICBUaGVyZWZvcmUsDQogICAgICAgICAgICAgICAgICAgIGFwcGxpY2F0aW9uIG9mIHRoZSBjb25m aWd1cmF0aW9uIG5vZGUgaXMgY29uZGl0aW9uYWwsIHJlc3VsdGluZw0KICAgICAgICAgICAgICAg ICAgICBpbiBhbiBlZmZlY3QgbXVjaCBsaWtlIHByZS1wcm92aXNpb25pbmcgaW50ZXJmYWNlcyBp biBSRkMgNzIyMy4iOw0KICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICAg fQ0KICAgICB9DQogICB9DQoNCg0KU3BlY2lmaWNhbGx5LCBub3RlIHRoYXQgdGhlIGxlYWZyZWYg aXMgZnJvbSBvbmUgY29uZmlnIHRydWUgbm9kZSB0byBhbm90aGVyIGNvbmZpZw0KdHJ1ZSBub2Rl LiAgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHNlbWFudGljcyBhcmUgYWxtb3N0IGFzIGlmIGl0IHdl cmUgbGlrZSBhIGNvbmZpZw0KdHJ1ZSBub2RlIHdlcmUgcG9pbnRpbmcgdG8gYSBjb25maWcgZmFs c2Ugbm9kZSwgYnV0IEkgYmVsaWV2ZSB0aGF0IHRoaXMgc2hvdWxkIGJlDQpva2F5LCB0aGF0IGlz LCB0aGF0IHdlIHNob3VsZCBzcGVjaWZpY2FsbHkgZGVmaW5lIHRoaXMgY29udmVudGlvbiBhcyBv a2F5Lg0KDQoNCkFzc3VtaW5nIHRoYXQgd2UncmUgb2theSB3aXRoIHRoZSBhYm92ZSwgd2UgcHJv cG9zYWwgZm9yIGEgbmVhci10ZXJtIHNvbHV0aW9uLCB0aGF0DQpkb2VzIE5PVCB1dGlsaXplIHRo ZSBvcHN0YXRlIHNvbHV0aW9uLCBmb2xsb3dzOg0KDQogICBtb2R1bGUgZm9vIHsNCiAgICAgIGNv bnRhaW5lciBub2RlcyB7DQogICAgICAgICBjb25maWcgdHJ1ZTsNCiAgICAgICAgIGxpc3Qgbm9k ZSB7DQogICAgICAgICAgICBrZXkgIm5hbWUiOw0KICAgICAgICAgICAgbGVhZiBuYW1lIHsgdHlw ZSBzdHJpbmc7IH0NCiAgICAgICAgICAgIGxlYWYgZGVwZW5kZW5jeSB7DQogICAgICAgICAgICAg ICB0eXBlIGxlYWZyZWYgew0KICAgICAgICAgICAgICAgICBwYXRoICIuLi9ub2RlL25hbWUiDQog ICAgICAgICAgICAgICAgIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2U7DQogICAgICAgICAgICAgICAg IGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICAgIkluIHRoZSBjYXNlIHdoZW4gYSBjb25m aWd1cmVkIG5vZGUgKGkuZS4gaW4gdGhlIHJ1bm5pbmcgRFMpDQogICAgICAgICAgICAgICAgICAg IGhhcyBhIGRlcGVuZGVuY3kgb24gYSBub2RlIHRoYXQgaXMgbm90IGNvbmZpZ3VyZWQsIHRoZSBz eXN0ZW0NCiAgICAgICAgICAgICAgICAgICAgbWF5IHRyeSB0byByZXNvbHZlIHRoZSBkZXBlbmRl bmN5IGFzIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGENCiAgICAgICAgICAgICAgICAgICAgKGkuZS4g dW5kZXIgdGhlIC9ub2Rlcy1zdGF0ZSB0cmVlKS4gIEFzIG9wZXJhdGlvbmFsIHN0YXRlIA0KICAg ICAgICAgICAgICAgICAgICBkYXRhIG1heSBoYXZlIGEgbGlmZWN5Y2xlIGluZGVwZW5kZW50IG9m IGNvbmZpZ3VyYXRpb24sIHRoZXJlDQogICAgICAgICAgICAgICAgICAgIGlzIG5vIGd1YXJhbnRl ZSB0aGF0IHRoZSBvcHN0YXRlIGRhdGEgd2lsbCBleGlzdC4gIFRoZXJlZm9yZSwNCiAgICAgICAg ICAgICAgICAgICAgYXBwbGljYXRpb24gb2YgdGhlIGNvbmZpZ3VyYXRpb24gbm9kZSBpcyBjb25k aXRpb25hbCwgcmVzdWx0aW5nDQogICAgICAgICAgICAgICAgICAgIGluIGFuIGVmZmVjdCBtdWNo IGxpa2UgcHJlLXByb3Zpc2lvbmluZyBpbnRlcmZhY2VzIGluIFJGQyA3MjIzLiI7DQogICAgICAg ICAgICAgICB9DQogICAgICAgICAgICB9DQogICAgICAgICB9DQogICAgICB9DQogICAgICBjb250 YWluZXIgbm9kZXMtc3RhdGUgew0KICAgICAgICAgY29uZmlnIGZhbHNlOw0KICAgICAgICAgbGlz dCBub2RlIHsNCiAgICAgICAgICAgIGtleSAibmFtZSI7DQogICAgICAgICAgICBsZWFmIG5hbWUg eyB0eXBlIHN0cmluZzsgfQ0KICAgICAgICAgICAgbGVhZiBkZXBlbmRlbmN5IHsNCiAgICAgICAg ICAgICAgIHR5cGUgbGVhZnJlZiB7DQogICAgICAgICAgICAgICAgIHBhdGggIi4uL25vZGUvbmFt ZSINCiAgICAgICAgICAgICAgICAgcmVxdWlyZS1pbnN0YW5jZSBmYWxzZTsNCiAgICAgICAgICAg ICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgIH0NCiAgICAgIH0NCiAgIH0NCg0KDQpUaGlz IG1vZHVsZSBpcyBzZW1hbnRpY2FsbHkgaWRlbnRpY2FsIHRvIHRoZSBmaXJzdCwgYnV0IG5vdywg aW4gYWRkaXRpb25hbA0KdG8gdGhlIGxlYWZyZWYgcG90ZW50aWFsbHkgaG9wcGluZyBkYXRhc3Rv cmVzLCBpdCBhbHNvIG5lZWRzIHRvIGhvcCBwYXRocyANCihpLmUuIHMvbm9kZXMvbm9kZXMtc3Rh dGUvKS4gTm90ZSB0aGUgbWludXRlIGNoYW5nZSBpbiB0aGUgZmlyc3Qgc2VudGVuY2UNCm9mIHRo ZSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQuICBZZXMsIGl0J3MgYSBoYWNrLCBidXQgc2luY2UgdGhl IGhvcHBpbmcgaXMNCmltcGxlbWVudGVkIGludGVybmFsbHkgYW55d2F5LCBtYXliZSBpdCdzIG9r YXkgYXMgYSBzdG9wLWdhcCBzaG9ydC10ZXJtDQpzb2x1dGlvbj8NCg0KDQpLZW50DQoNCg0KDQo= From nobody Fri Feb 3 10:14:57 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16342129548; Fri, 3 Feb 2017 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzD5VQVvHGle; Fri, 3 Feb 2017 10:14:53 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B899C1294D3; Fri, 3 Feb 2017 10:14:51 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l19so16672324ywc.2; Fri, 03 Feb 2017 10:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hComkGK1kyeFEUMYJjn3aizoAcZzVSRDjAnYtO/R3Pk=; b=jRMez6J+YQF140EB3f+ujwQ0T+ioJniRvhIxMe6IjKEM/YuCWDYQE28TPeytukbM81 uVginISijnZc14u7ftdqzLhuTkfHGgzgLvckEGwBnkRilmNnyK/t1qNLavwSIgNnxCHV AX7kWDNBWjNjRnd6GyYxvZ5xpApsYGKGiXZ4efKvCulcv/f1fzD5/WDC+c6iwAY6NVvQ SpeGzPjt3wHmcIo/CIzzSQvZk/lAstxREus9G/JY9SxfF5sqdfiLsIMOmD6o72nI7mua mzTqhtjr4tSx//uPrjNRoywlIe1fmZnj2k/zw0nYjW0WIjnboGtwru6LFlm9nez98UJq flAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hComkGK1kyeFEUMYJjn3aizoAcZzVSRDjAnYtO/R3Pk=; b=fquIt1+SMZOAPuMovuTrGrOFd+76s9eKXyX2TwuHgQLh7/U3Aczhf3U0fR/NqXj6qt rdru4rsICQku0QnhXxYhMRHweZpBZm5GelRCY3N4VGwcKlNxbS6W/8WoUT31lJS6rh2d VKsKTvQNTQKgzoxMVtlPR4jMSpusQbvVY6k9Z2Jafc3yB2bji47K7rnsZvt6IkHD3o+i Qd/vbxdSF6GCClzYAUOMbvRYu/PR7R5Rtv0U5lo12HcIgGcECIh61ClDdK7vzYGibnM5 rhZAgqP+KI0keZrhc7RyXs6grWWDhxfJayqwVjg7gt6cACe0pnH3ujcq47c2OLOx0VcX SINg== X-Gm-Message-State: AIkVDXI2fNSekHdbrK7lUNGJsm9PycS9vzLF3JSpoQOqapsNdmbqqlzaoZYZVC/5xsVDDQDqavg5POd/KhrELA== X-Received: by 10.129.118.4 with SMTP id r4mr10596946ywc.85.1486145690765; Fri, 03 Feb 2017 10:14:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Fri, 3 Feb 2017 10:14:49 -0800 (PST) In-Reply-To: <030B0A7E-5238-4D78-BC97-2140B269D82A@juniper.net> References: <20170203.163216.1400419881696462638.mbj@tail-f.com> <20170203.170800.1259525494650193374.mbj@tail-f.com> <030B0A7E-5238-4D78-BC97-2140B269D82A@juniper.net> From: Alia Atlas Date: Fri, 3 Feb 2017 13:14:49 -0500 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=f403045ef482fb92bb0547a441a9 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , Xufeng Liu , Martin Bjorklund , "i2rs@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 18:14:55 -0000 --f403045ef482fb92bb0547a441a9 Content-Type: text/plain; charset=UTF-8 Kent, >From the 5000 foot view, this looks to me like the description changing the behavior of what a system should do. What am I missing? Thanks, Alia On Fri, Feb 3, 2017 at 1:11 PM, Kent Watsen wrote: > > [Xufeng] Right. If we do so, the approach will be different from RFC7223, > and requires the capability that a "config true" leafref references a > "config false" leaf. > > > I think my proposal was misunderstood, so here's a more complete example: > > Assume the following schema is used by client/servers that implement the > long-term > opstate solution presented in the revised-datastores draft: > > module foo { > container nodes { > config true; > list node { > key "name"; > leaf name { type string; } > leaf dependency { > type leafref { > path "../node/name" > require-instance false; > description > "In the case when a configured node (i.e. in the > running DS) > has a dependency on a node that is not configured, the > system > may try to resolve the dependency as operational state > data > (i.e. in the operational-state DS). As operational > state > data may have a lifecycle independent of > configuration, there > is no guarantee that the opstate data will exist. > Therefore, > application of the configuration node is conditional, > resulting > in an effect much like pre-provisioning interfaces in > RFC 7223."; > } > } > } > } > } > > > Specifically, note that the leafref is from one config true node to > another config > true node. I understand that the semantics are almost as if it were like > a config > true node were pointing to a config false node, but I believe that this > should be > okay, that is, that we should specifically define this convention as okay. > > > Assuming that we're okay with the above, we proposal for a near-term > solution, that > does NOT utilize the opstate solution, follows: > > module foo { > container nodes { > config true; > list node { > key "name"; > leaf name { type string; } > leaf dependency { > type leafref { > path "../node/name" > require-instance false; > description > "In the case when a configured node (i.e. in the > running DS) > has a dependency on a node that is not configured, the > system > may try to resolve the dependency as operational state > data > (i.e. under the /nodes-state tree). As operational > state > data may have a lifecycle independent of > configuration, there > is no guarantee that the opstate data will exist. > Therefore, > application of the configuration node is conditional, > resulting > in an effect much like pre-provisioning interfaces in > RFC 7223."; > } > } > } > } > container nodes-state { > config false; > list node { > key "name"; > leaf name { type string; } > leaf dependency { > type leafref { > path "../node/name" > require-instance false; > } > } > } > } > } > > > This module is semantically identical to the first, but now, in additional > to the leafref potentially hopping datastores, it also needs to hop paths > (i.e. s/nodes/nodes-state/). Note the minute change in the first sentence > of the description statement. Yes, it's a hack, but since the hopping is > implemented internally anyway, maybe it's okay as a stop-gap short-term > solution? > > > Kent > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --f403045ef482fb92bb0547a441a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kent,

From the 5000 foot view, this loo= ks to me like the description changing the behavior
of what a sys= tem should do.

What am I missing?

Thanks,
Alia

<= div class=3D"gmail_quote">On Fri, Feb 3, 2017 at 1:11 PM, Kent Watsen <k= watsen@juniper.net> wrote:
=
[Xufeng] Right. If we do so, the approach will be different from RFC7223, a= nd requires the capability that a "config true" leafref reference= s a "config false" leaf.


I think my proposal was misunderstood, so here's a more complete= example:

Assume the following schema is used by client/servers that implement the lo= ng-term
opstate solution presented in the revised-datastores draft:

=C2=A0 =C2=A0module foo {
=C2=A0 =C2=A0 =C2=A0 container nodes {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list node {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { type string; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf dependency {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path "..= /node/name"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0require-insta= nce false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= In the case when a configured node (i.e. in the running DS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has a= dependency on a node that is not configured, the system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may t= ry to resolve the dependency as operational state data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (i.e.= in the operational-state DS).=C2=A0 As operational state
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 data = may have a lifecycle independent of configuration, there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is no= guarantee that the opstate data will exist.=C2=A0 Therefore,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appli= cation of the configuration node is conditional, resulting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 in an effect much like pre-provisioning interfaces in RFC 722= 3.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}


Specifically, note that the leafref is from one config true node to = another config
true node.=C2=A0 I understand that the semantics are almost as if it were l= ike a config
true node were pointing to a config false node, but I believe that this sho= uld be
okay, that is, that we should specifically define this convention as okay.<= br>

Assuming that we're okay with the above, we proposal for a near-term so= lution, that
does NOT utilize the opstate solution, follows:

=C2=A0 =C2=A0module foo {
=C2=A0 =C2=A0 =C2=A0 container nodes {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list node {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { type string; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf dependency {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path "..= /node/name"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0require-insta= nce false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= In the case when a configured node (i.e. in the running DS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has a= dependency on a node that is not configured, the system
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may t= ry to resolve the dependency as operational state data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (i.e.= under the /nodes-state tree).=C2=A0 As operational state
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 data = may have a lifecycle independent of configuration, there
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is no= guarantee that the opstate data will exist.=C2=A0 Therefore,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appli= cation of the configuration node is conditional, resulting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 in an effect much like pre-provisioning interfaces in RFC 722= 3.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 container nodes-state {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list node {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { type string; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf dependency {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path "..= /node/name"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0require-insta= nce false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}


This module is semantically identical to the first, but now, in additional<= br> to the leafref potentially hopping datastores, it also needs to hop paths (i.e. s/nodes/nodes-state/). Note the minute change in the first sentence of the description statement.=C2=A0 Yes, it's a hack, but since the hop= ping is
implemented internally anyway, maybe it's okay as a stop-gap short-term=
solution?


Kent



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

--f403045ef482fb92bb0547a441a9-- From nobody Fri Feb 3 12:38:10 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029D51294DD; Fri, 3 Feb 2017 12:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07LZAiyV1U-x; Fri, 3 Feb 2017 12:38:07 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0131.outbound.protection.outlook.com [104.47.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDD8129474; Fri, 3 Feb 2017 12:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KfhTxiNv1pDGwYBW5sZy2+01yfZdDtNy5dpICRFi4dE=; b=NuuE70mAYpTrhcKZfobsSpdHhaFH85111UrMjZDGhdLr+aK5c50tqopncbapqfgBSWeK0ohHXlrhQMVkL/fV4YeoYH34Kz9ragIaSyujNVWm1LZh+H4t6ZSHH5xeJ12WK4fv8tdMkpZkD/sD6RHiqlwyGVtPVnCCwbN/mAuV/xk= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 3 Feb 2017 20:38:05 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0888.018; Fri, 3 Feb 2017 20:38:05 +0000 From: Kent Watsen To: Alia Atlas Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/yqRSiXVe4g0u0BDQlaxXyX6FJRx6AgAAEUoCAAALgAIALPDeAgAALPQCAABeFgIAABLgAgAAODICAAJ8egIAAbOUAgAAlhgCAAA+qAIAAOUOAgAEq7wCAABHTAIAABTiAgAAExACAAAJvgP//zECAgABUwID//9QzgA== Date: Fri, 3 Feb 2017 20:38:04 +0000 Message-ID: <3BBD2401-A8DF-44C1-9488-901DD95DC8A1@juniper.net> References: <20170203.163216.1400419881696462638.mbj@tail-f.com> <20170203.170800.1259525494650193374.mbj@tail-f.com> <030B0A7E-5238-4D78-BC97-2140B269D82A@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: ccddded2-4a94-4de6-e525-08d44c748e29 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:q9ir8IkuZnZxcMI8FCWewsvKJyoW49A2b3wC5UlwvEVaAWb54pqAmoEBhpYmunvGc33nAghfJTLMDXKgZ62dmrlUzBB/6yg15NRw0RvH/8QQuxLS9KmMNqS2obKe78E1/kC6NMwYw/ae8YgepJUZBmL6vy+fX5nUCoAqSZ8Sg5CMIL6IOj5nUSVnRStjEBoMepjDIBtMb9DcFRlyo289KP+Eh5eU/q+GuRXpWE0f2+lPZ+MYoE75i2Cmasgptk9nwdk9rhwK6dpfFtbhLkGlJ/jIylfHctch7M6ngJe9iI0bg2pUGEjRGTu7EjFPL0PhYXhEFZ63LaqFkhEWjNYGm+iHzhFayPs0YB5wGblLtsDG7ST45RqE/arO9x4KcqVxQK7EJxanHIn3AcZW3LDat0L/TLtEfCtPB1LX61IbH8C2hyUpdgfgoYwP+xouS1GMdNN50sCcNWYrFAHHzj8pt97vohyIeeG7o75vPlr0k2YbfuBvRvwqtLSVbSskJnJQpAaP1VwYuz8ayYgDBCFq+Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(199003)(189002)(68736007)(6486002)(54896002)(3846002)(38730400001)(102836003)(4001350100001)(93886004)(83716003)(97736004)(6506006)(39060400001)(82746002)(229853002)(6246003)(6436002)(122556002)(77096006)(86362001)(83506001)(7736002)(3280700002)(33656002)(110136003)(8936002)(106356001)(92566002)(4326007)(1411001)(189998001)(53936002)(50986999)(6116002)(8676002)(106116001)(2906002)(2950100002)(6916009)(36756003)(6512007)(6306002)(81156014)(101416001)(81166006)(230783001)(3660700001)(2900100001)(76176999)(25786008)(54356999)(99286003)(5660300001)(54906002)(66066001)(105586002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3BBD2401A8DF44C19488901DD95DC8A1junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 20:38:04.9909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , Xufeng Liu , Martin Bjorklund , "i2rs@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:38:09 -0000 --_000_3BBD2401A8DF44C19488901DD95DC8A1junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IEZyb20gdGhlIDUwMDAgZm9vdCB2aWV3LCB0aGlzIGxvb2tzIHRvIG1lIGxpa2UgdGhlIGRl c2NyaXB0aW9uIGNoYW5naW5nDQo+IHRoZSBiZWhhdmlvciBvZiB3aGF0IGEgc3lzdGVtIHNob3Vs ZCBkby4NCg0KQ29ycmVjdC4NCg0KPiBXaGF0IGFtIEkgbWlzc2luZz8NCg0KSSB0aGluayB5b3Ug YXJlIGFza2luZywgaG93IGlzIHRoaXMgZGlmZmVyZW50IHRoYW4gdGhlIGN1cnJlbnQgZHJhZnQn cyBhcHByb2FjaCwgcmlnaHQ/ICAgVGhlIHByaW1hcnkNCmRpc3RpbmN0aW9uIGlzIHRoYXQgdGhp cyBhcHByb2FjaCBkb2Vzbid0IGJyZWFrIGxlZ2FjeSBjbGllbnRzLiAgIEFsbCBleGlzdGluZyBv cGVyYXRpb25zIChiYWNrdXAvcmVzdG9yZSkNCmNvbnRpbnVlIHRvIHdvcmsuDQoNClRoZSBpc3N1 ZSB3YXMgbmV2ZXIgdGhhdCBuZXcgc2VtYW50aWNzIHdlcmUgYmVpbmcgYWRkZWQ7IHdlIGRvIHRo YXQgYWxsIHRoZSB0aW1lIChlLmcuLCBvcHN0YXRlKS4gIFRoZQ0KaXNzdWUgd2FzIHRoYXQgdGhl IG5ldyBzZW1hbnRpY3Mgd2VyZSBiZWluZyBhZGRlZCB3aXRob3V0IGEgc3Ryb25nIG1lY2hhbmlz bSB0byBwcmV2ZW50IGxlZ2FjeQ0KY2xpZW50cyBmcm9tIGRvaW5nIHNvbWV0aGluZyBiYWQgKGku ZS4gYSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgYWxvbmUgaXNuJ3Qgc3VmZmljaWVudCkuDQoNCkJ5 IGV4YW1wbGUsIG5vdGUgdGhhdCBZQU5HIGV4dGVuc2lvbnMsIHdoaWNoIGluY2x1ZGVzIG1ldGFk YXRhIHBlciBSRkMgNzk1MiwgYWxzbyBhcmUgdXNlZCB0bw0KaW50cm9kdWNlIG5ldyBzZW1hbnRp Y3MsIGJ1dCB0aGV5IGNhbm5vdCBkbyBzbyBpcyBhIG5vbiBiYWNrd2FyZHMgY29tcGF0aWJsZSBt YW5uZXIuICBSRkMgNzk1MA0KU2VjdGlvbiA2LjMuMSBzYXlzOg0KDQogICBUaGUgcHJvY2Vzc2lu ZyBvZiBleHRlbnNpb25zIGRlcGVuZHMgb24gd2hldGhlciBzdXBwb3J0IGZvciB0aG9zZQ0KICAg ZXh0ZW5zaW9ucyBpcyBjbGFpbWVkIGZvciBhIGdpdmVuIFlBTkcgcGFyc2VyIG9yIHRoZSB0b29s IHNldCBpbg0KICAgd2hpY2ggaXQgaXMgZW1iZWRkZWQuICBBbiB1bnN1cHBvcnRlZCBleHRlbnNp b24gYXBwZWFyaW5nIGluIGEgWUFORw0KICAgbW9kdWxlIGFzIGFuIHVua25vd24tc3RhdGVtZW50 IChzZWUgU2VjdGlvbiAxNCkgTUFZIGJlIGlnbm9yZWQgaW4gaXRzDQogICBlbnRpcmV0eS4NCg0K YW5kIGFsc286DQoNCiAgIENhcmUgbXVzdCBiZSB0YWtlbiB3aGVuIGRlZmluaW5nIGV4dGVuc2lv bnMgc28gdGhhdCBtb2R1bGVzIHRoYXQgdXNlDQogICB0aGUgZXh0ZW5zaW9ucyBhcmUgbWVhbmlu Z2Z1bCBhbHNvIGZvciBhcHBsaWNhdGlvbnMgdGhhdCBkbyBub3QNCiAgIHN1cHBvcnQgdGhlIGV4 dGVuc2lvbnMuDQoNClNvLCBmb3IgaW5zdGFuY2UsIGlmIHdlIHdhbnRlZCB0byBoYXZlIGEgInNl cnZlci1wcm92aWRlZCIgbWV0YWRhdGEgYW5ub3RhdGlvbiwgd2UnZCBoYXZlIHRvDQppbnRyb2R1 Y2UgaXQgYWxvbmcgd2l0aCBhbiBleHBsaWNpdCBjbGllbnQgcmVxdWVzdCwgc29tZXdoYXQgbGlr ZSB0aGUgPHdpdGgtZGVmYXVsdHM+IHBhcmFtZXRlcg0KYWRkZWQgYnkgUkZDIDYyNDMuICAgV2Ug Y291bGQgZ28gdGhhdCByb3V0ZSBoZXJlIGlmIG5lZWRlZCwgYnV0IEkgZmlyc3Qgd2FudCB0byBz ZWUgaWYgdGhlIGlkZWENCnBvc3RlZCBlYXJseSBpcyBzdWZmaWNpZW50Li4uDQoNCg0KS2VudA0K DQoNCg== --_000_3BBD2401A8DF44C19488901DD95DC8A1junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <382B3C004356A843BB015CEAFC445922@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpi DQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFy aWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNm b3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9 IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBGcm9tIHRoZSA1MDAwIGZv b3QgdmlldywgdGhpcyBsb29rcyB0byBtZSBsaWtlIHRoZSBkZXNjcmlwdGlvbiBjaGFuZ2luZzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyB0aGUgYmVoYXZpb3Igb2Yg d2hhdCBhIHN5c3RlbSBzaG91bGQgZG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNvcnJlY3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsgV2hhdCBhbSBJIG1pc3Npbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgeW91IGFyZSBhc2tpbmcsIGhvdyBpcyB0aGlzIGRpZmZlcmVudCB0aGFuIHRo ZSBjdXJyZW50IGRyYWZ0J3MgYXBwcm9hY2gsIHJpZ2h0PyZuYnNwOyZuYnNwOyBUaGUgcHJpbWFy eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlzdGluY3Rpb24gaXMgdGhh dCB0aGlzIGFwcHJvYWNoIGRvZXNuJ3QgYnJlYWsgbGVnYWN5IGNsaWVudHMuJm5ic3A7Jm5ic3A7 IEFsbCBleGlzdGluZyBvcGVyYXRpb25zIChiYWNrdXAvcmVzdG9yZSk8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbnRpbnVlIHRvIHdvcmsuJm5ic3A7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWUgd2FzIG5ldmVyIHRoYXQgbmV3IHNlbWFudGlj cyB3ZXJlIGJlaW5nIGFkZGVkOyB3ZSBkbyB0aGF0IGFsbCB0aGUgdGltZSAoZS5nLiwgb3BzdGF0 ZSkuJm5ic3A7IFRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXNzdWUg d2FzIHRoYXQgdGhlIG5ldyBzZW1hbnRpY3Mgd2VyZSBiZWluZyBhZGRlZCB3aXRob3V0IGEgc3Ry b25nIG1lY2hhbmlzbSB0byBwcmV2ZW50IGxlZ2FjeQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5jbGllbnRzIGZyb20gZG9pbmcgc29tZXRoaW5nIGJhZCAoaS5lLiBhIGRl c2NyaXB0aW9uIHN0YXRlbWVudCBhbG9uZSBpc24ndCBzdWZmaWNpZW50KS4mbmJzcDsNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CeSBleGFtcGxlLCBub3RlIHRoYXQgWUFORyBleHRlbnNpb25z LCB3aGljaCBpbmNsdWRlcyBtZXRhZGF0YSBwZXIgUkZDIDc5NTIsIGFsc28gYXJlIHVzZWQgdG8N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50cm9kdWNlIG5ldyBzZW1h bnRpY3MsIGJ1dCB0aGV5IGNhbm5vdCBkbyBzbyBpcyBhIG5vbiBiYWNrd2FyZHMgY29tcGF0aWJs ZSBtYW5uZXIuJm5ic3A7IFJGQyA3OTUwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TZWN0aW9uIDYuMy4xIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyBUaGUgcHJvY2Vzc2luZyBvZiBleHRlbnNpb25zIGRlcGVuZHMgb24gd2hldGhlciBzdXBw b3J0IGZvciB0aG9zZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 Jm5ic3A7IGV4dGVuc2lvbnMgaXMgY2xhaW1lZCBmb3IgYSBnaXZlbiBZQU5HIHBhcnNlciBvciB0 aGUgdG9vbCBzZXQgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyB3aGljaCBpdCBpcyBlbWJlZGRlZC4mbmJzcDsgQW4gdW5zdXBwb3J0ZWQgZXh0ZW5z aW9uIGFwcGVhcmluZyBpbiBhIFlBTkc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyBtb2R1bGUgYXMgYW4gdW5rbm93bi1zdGF0ZW1lbnQgKHNlZSBTZWN0 aW9uIDE0KSBNQVkgYmUgaWdub3JlZCBpbiBpdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBlbnRpcmV0eS4mbmJzcDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmFuZCBhbHNvOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgQ2Fy ZSBtdXN0IGJlIHRha2VuIHdoZW4gZGVmaW5pbmcgZXh0ZW5zaW9ucyBzbyB0aGF0IG1vZHVsZXMg dGhhdCB1c2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyB0aGUgZXh0ZW5zaW9ucyBhcmUgbWVhbmluZ2Z1bCBhbHNvIGZvciBhcHBsaWNhdGlvbnMgdGhh dCBkbyBub3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyBzdXBwb3J0IHRoZSBleHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgZm9y IGluc3RhbmNlLCBpZiB3ZSB3YW50ZWQgdG8gaGF2ZSBhICZxdW90O3NlcnZlci1wcm92aWRlZCZx dW90OyBtZXRhZGF0YSBhbm5vdGF0aW9uLCB3ZSdkIGhhdmUgdG8NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50cm9kdWNlIGl0IGFsb25nIHdpdGggYW4gZXhwbGljaXQg Y2xpZW50IHJlcXVlc3QsIHNvbWV3aGF0IGxpa2UgdGhlICZsdDt3aXRoLWRlZmF1bHRzJmd0OyBw YXJhbWV0ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFkZGVkIGJ5IFJG QyA2MjQzLiZuYnNwOyZuYnNwOyBXZSBjb3VsZCBnbyB0aGF0IHJvdXRlIGhlcmUgaWYgbmVlZGVk LCBidXQgSSBmaXJzdCB3YW50IHRvIHNlZSBpZiB0aGUgaWRlYTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+cG9zdGVkIGVhcmx5IGlzIHN1ZmZpY2llbnQuLi48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5LZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3BBD2401A8DF44C19488901DD95DC8A1junipernet_-- From nobody Sun Feb 5 12:20:00 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D931298AF for ; Wed, 25 Jan 2017 04:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jev9FrOwFeTx for ; Wed, 25 Jan 2017 04:27:13 -0800 (PST) Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5661298AD for ; Wed, 25 Jan 2017 04:27:13 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 36DF91E0F70 for ; Wed, 25 Jan 2017 05:27:12 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id ccT81u00B2SSUrH01cTBy6; Wed, 25 Jan 2017 05:27:12 -0700 X-Authority-Analysis: v=2.1 cv=JsBi8qIC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=IgFoBzBjUZAA:10 a=1sjgXBK7AAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=OUXY8nFuAAAA:8 a=WusUA4wHyqQ2Cb6QtV8A:9 a=vee88xjq9iqqPJWa:21 a=0IAYUIx84SJugqCM:21 a=pILNOxqGKmIA:10 a=qowbMnUzjQcM5iyYROrS:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=cAcMbU7R10T-QSRYIcO_:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Cc:References:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cqBI0bR9BVeAkkCFs/e3VvPwqYHVn4esKECATqJfI/Y=; b=JK5iy0p1DwVsHQzOliLIdyk/Sx /trTgjUEEyVNkNdCuqXyrW+QL2bytzskBDs+UF1tTeds6jPBxu8XYWpbJK3D2V3VCqO26XG7g7KuA WMUgz1ziGnxuEH4tRddFoKYj9; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:44230 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cWMfM-0003wl-3c; Wed, 25 Jan 2017 05:27:08 -0700 From: Lou Berger To: Susan Hares References: <029501d27637$456c9af0$d045d0d0$@ndzh.com> <20170124.133529.2274781221200613254.mbj@tail-f.com> <02e301d2764f$eb622f20$c2268d60$@ndzh.com> <20170124.163910.1660442168342299903.mbj@tail-f.com> <000d01d27662$0216d8d0$06448a70$@ndzh.com> Message-ID: <8fca02ad-b589-a77e-0ed9-c12796dc47c3@labn.net> Date: Wed, 25 Jan 2017 07:27:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <000d01d27662$0216d8d0$06448a70$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cWMfM-0003wl-3c X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:44230 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: X-Mailman-Approved-At: Sun, 05 Feb 2017 12:19:59 -0800 Cc: i2rs@ietf.org, 'Martin Bjorklund' , kwatsen@juniper.net, draft-ietf-i2rs-yang-l3-topology@ietf.org, j.schoenwaelder@jacobs-university.de, i2rs-chairs@ietf.org, nite@hq.sk, Kathleen.Moriarty.ietf@gmail.com, iesg@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 12:27:16 -0000 Sue, In short, I'm going to agree with Benoit - but for slightly different reasons as I also co-chair TEAS, a group that is basing some of its work on I2RS developed models. As a WG chair, I have always viewed the models being developed by I2RS as typical models that are generally useful, and being defined by I2RS simply because they were ahead of other groups that might otherwise define the models -- and I view this as a fine thing that has benefit for YANG users and other WGs. As TEAS chair, this is what lead me to ensure that the models being defined in TEAS built on the I2RS YANG modules vs their original path of redefining parallel function. As part of my view of the I2RS models being generally applicable to uses beyond I2RS together with I2RS choosing YANG for modeling ephemeral data, I have always expected that the I2RS WG would at some (perhaps as part of the I2RS protocol definition) define how any YANG model can be used to support I2RS. This view certainly lead me to conclude that having the I2RS models move forward, just like any other YANG model, makes sense and would benefit the other models and WGs that reference this core work. This view also allows for the relationship to the revised-data store work, as well as the specification of which data store(s) I2RS uses, to be separately defined -- and to not gate publication of these models. This separate specification would be the location for any I2RS-specific transport and security considers, so such would not belong in the generally reusable models developed by I2RS. Essentially, As NETMOD co-chair, I concluded that the revised data store work provided the direction on how ephemeral would be supported in a general YANG context and, therefore, the major open issue / gating impediment to progressing I2RS models had been removed and publication of these models were unblocked. This also motivated my comments in the related discussions at the last meeting. If my understanding/view is correct, i.e., that the topology models are just like any other YANG model, then I think publication can and should proceed (with the appropriate text for a typical YANG model). If I misunderstood something, and the models produced by I2RS are limited to ephemeral representations/data stores as well as specific YANG transport protocols -- then as TEAS chair, I have to hit reset on the TEAS topology work, and as NETMOD chair I think the NETMOD WG needs to discuss what it means for a YANG model to be protocol/datastore specific and if any guidelines or other new NTEMOD documents are need to support such. Less importantly, as I2RS participant, I'd also ask for the documents to be sent back to the WG for a new last call once the documents are updated to reflect their narrow scope -- as I bet I'm not the only person who viewed this work applicable to non-ephemeral uses. I hope this helps. Lou On January 24, 2017 11:56:32 AM "Susan Hares" wrote: > To: Martin: > > You have a reasonable request. If the NETMOD WG Chairs confirm their > decision to make I2RS Yang Modules part of the Control Plane Datastore then > as shepherd/WG-chair I will recommend these get added to the draft. > > Note to authors : > > As we wait for the NETMOD WG Chairs and Benoit to deliver the decision on > Config/Control Plane datastore, the authors should work on: Basic Yang > security considerations and the other I2RS Yang Module information. > > Sue Hares (Shepherd) > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, January 24, 2017 10:39 AM > To: shares@ndzh.com > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; > j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; nite@hq.sk; > Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; lberger@labn.net; > kwatsen@juniper.net > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > "Susan Hares" wrote: >> Martin: >> >> >> >> I'm sorry if misunderstood your comments regarding the >> draft-ietf-netmod-revised-datastores-00.txt. The reason the answer is >> unclear is that it depends on the context of the question. >> >> >> >> . If you ask if the pre-standardization I2RS Yang Topology models >> (basic and L3) implemented are part of the configuration data store, >> the answer is yes - AFAIK. > > This is not my question. > >> . If you ask if the WG LC Topology models are approved to be part > of >> the configuration data store, my understanding was no. I2RS WG was to >> abide by the decision of NETMOD WG on which data store I2RS modules >> were placed in. > > Yes, this is my question. And my concern is that even if your understanding > is that they are not designed to be part of the configuration datastores, > this fact is not mentioned in the drafts. > >> If you are concerned the implementation varies from the standardized, > please >> express this to Benoit Claise. Based on your comments on my email > thread, >> I will be brief in my answers today. > > This is not my concern. > > > /martin > > > >> >> >> >> Sue >> >> >> >> >> >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com] >> Sent: Tuesday, January 24, 2017 7:35 AM >> To: shares@ndzh.com >> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topology@ietf.org; >> j.schoenwaelder@jacobs-university.de; i2rs-chairs@ietf.org; >> nite@hq.sk; Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org; >> lberger@labn.net; kwatsen@juniper.net >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> >> >> "Susan Hares" < shares@ndzh.com> wrote: >> >> > Martin: >> >> > >> >> > Your statement "One problem is that relying on the solution in >> >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in >> > fact, >> >> > that document does not yet provide any details at all on the I2RS >> >> > ephemeral data store." This statement is not what I understood from >> > IETF >> 98 or the netmod >> >> > ADs. I guess your objection to this data model falls into Benoit > Claise >> >> > (AD) and the NETMOD folks to answer. >> >> >> >> Why do you think that I have any objection to >> draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. >> >> >> >> My objection regards your statement: >> >> >> >> 1) I2RS Data models do not utilize the configuration data store, >> >> >> >> If this is true it needs to be clarified in the document. >> >> >> >> After all these emails back and forth, it is still not clear whether >> this statement is true or not. >> >> >> >> >> >> /martin >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > Sue Hares >> >> > >> >> > -----Original Message----- >> >> > From: i2rs [ >> > mailto:i2rs-bounces@ietf.org] >> On Behalf Of Martin >> >> > Bjorklund >> >> > Sent: Monday, January 23, 2017 5:26 PM >> >> > To: shares@ndzh.com >> >> > Cc: i2rs@ietf.org; >> >> draft-ietf-i2rs-yang-l3-topology@ietf.org; >> >> > >> j.schoenwaelder@jacobs-university.de; >> i2rs-chairs@ietf.org; >> >> > nite@hq.sk; >> >> Kathleen.Moriarty.ietf@gmail.com; iesg@ietf.org >> >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> > >> >> > "Susan Hares" < shares@ndzh.com> wrote: >> >> > > Robert and Martin: >> >> > > >> >> > > I agree with Robert that the current implementations of the ODL >> >> > > topology models are handled as part of the configuration data >> > > store >> >> > > with >> >> > ephemeral >> >> > > state. I will point out that these implementation are pre-standards >> >> > > implementations of the I2RS YANG Data model. >> >> > > >> >> > > While standardizing the topology data models, the I2RS WG have >> > > been >> >> > > asked to align with the >> > > draft-ietf-netmod-revised-datastores-00.txt >> >> > > NETMOD WG document. This NETMOD WG document moves the I2RS >> >> > > ephemeral data >> >> > store from >> >> > > configuration data store to a Control Plane data store. If we follow >> >> > this >> >> > > draft, the I2RS Topology models are part of the I2RS ephemeral >> > > data >> store. >> >> > > If you disagree with the placement of the Topology data models, >> >> > > please indicate this to the NETMOD WG and to Benoit. Could you >> >> > > propose a way that you would see the ephemeral state working with >> >> > > the configuration data >> >> > store >> >> > > to the NETMOD WG? >> >> > > >> >> > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG > asks >> >> > for >> >> > > Control Plane Data store. You ask for configuration data store >> >> > > (which was the I2RS initial proposal). >> >> > >> >> > Not really; I ask for clarification. >> >> > >> >> > > It is possible for either one to work for I2RS >> >> > > Topology models - if the right details are taken care of. How do we >> make >> >> > > progress on choosing one method so we can write the I2RS Topology >> >> > > Models security considerations.? >> >> > >> >> > One problem is that relying on the solution in >> >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in >> > fact, >> >> > that document does not yet provide any details at all on the I2RS >> >> > ephemeral datastore. >> >> > >> >> > So I see two alternatives. Either wait with these documents, or >> >> > publish them with their datamodels as is (i.e., no new additional >> >> > notes), for the existing protocols and architecure. This would >> > allow >> >> > them to be implemented just like any other YANG data model. This >> >> > would mean that the normal YANG security considerations guidelines >> > should >> be followed. >> >> > >> >> > >> >> > >> >> > /martin >> >> > >> >> > > >> >> > > Sue >> >> > > >> >> > > -----Original Message----- >> >> > > From: Robert Varga [ mailto:nite@hq.sk] >> >> > > Sent: Monday, January 23, 2017 4:11 PM >> >> > > To: Martin Bjorklund; shares@ndzh.com >> >> > > Cc: i2rs@ietf.org; >> >> draft-ietf-i2rs-yang-l3-topology@ietf.org; >> >> > > >> j.schoenwaelder@jacobs-university.de; >> i2rs-chairs@ietf.org; >> >> > > >> Kathleen.Moriarty.ietf@gmail.com; >> iesg@ietf.org >> >> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >> >> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >> >> > > >> >> > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: >> >> > > >> I'm pulling your questions to the top of this email. >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> Question 1: Ok. Just to make sure I understand this correctly >> > > >> - >> >> > > >> these topology models are intended to be I2RS-specific, and >> > > >> they >> >> > > >> cannot be used for any other purpose. If anyone needs a >> > > >> general >> >> > > >> topology model outside of the I2RS protocol, they will have to >> >> > > >> design their own model. Is this correct? >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> Response 1: Not really. >> >> > > > Ok, so are you saying that the models are in fact generic, and >> > > > can >> >> > > > be used outside of I2RS? I.e., they *can* be used with the >> > > > normal >> >> > > > configuration datastores? >> >> > > > >> >> > > >> >> > > From implementation experience, yes, they can be used for storing >> >> > > configuration. OpenDaylight uses (an ancient predecessor of) >> >> > > yang-network-topo to store configure details about devices in its >> >> > > managed networks. >> >> > > >> >> > > Regards, >> >> > > Robert >> >> > > >> >> > > >> >> > >> >> > _______________________________________________ >> >> > i2rs mailing list >> >> > i2rs@ietf.org >> >> > >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > >> > > From nobody Sun Feb 5 17:32:02 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94564120727; Sun, 5 Feb 2017 17:32:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148634472057.31649.18299031480928208765.idtracker@ietfa.amsl.com> Date: Sun, 05 Feb 2017 17:32:00 -0800 Archived-At: Cc: i2rs@ietf.org, skh@ndzh.com, i2rs-chairs@ietf.org, akatlas@gmail.com Subject: [i2rs] i2rs - Update to a Meeting Session Request for IETF 98 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 01:32:00 -0000 An update to a meeting session request has just been submitted by Susan Hares, a Chair of the i2rs working group. --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: idr i2nsf netconf netmod rtgwg rtgarea trill babel grow Second Priority: bess sidrops dots opsawg sfc Third Priority: anima cbor People who must be present: Susan Hares Russ White Alia Atlas Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 10 13:05:15 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A141B129453; Fri, 10 Feb 2017 13:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YOWzzhWfhwRA; Fri, 10 Feb 2017 13:05:12 -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 877C6129593; Fri, 10 Feb 2017 13:05:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGF16147; Fri, 10 Feb 2017 21:05:08 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 10 Feb 2017 21:05:07 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Fri, 10 Feb 2017 13:05:03 -0800 From: Alexander Clemm To: Kent Watsen , Xufeng Liu , Martin Bjorklund Thread-Topic: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Thread-Index: AQHSdw/ybSgJ5VGI5EaXm4CY9Zw+S6FJzTqAgAAEUoCAAALgAIALPDiAgAALPACAABeFgIAABLgA//+CeZCAASqxgIAAbOUAgAAlhgCAAA+rAIAAjRSAgADXHQCAABHTAIAABTmAgAAEwwCAAAJwgIAAIBIAgAqPbyA= Date: Fri, 10 Feb 2017 21:05:02 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7F97C@SJCEML703-CHM.china.huawei.com> References: <20170203.163216.1400419881696462638.mbj@tail-f.com> <20170203.170800.1259525494650193374.mbj@tail-f.com> <030B0A7E-5238-4D78-BC97-2140B269D82A@juniper.net> In-Reply-To: <030B0A7E-5238-4D78-BC97-2140B269D82A@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.589E2B05.0098, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6ff3d7af1302c2899e961bf42b5ae590 Archived-At: Cc: "draft-ietf-i2rs-yang-l3-topology@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 21:05:14 -0000 Hi, just one comment, I think the example is a bit oversimplified. =20 Specifically, the leafref just indicates that you should point to another n= ode. In the full model, there is a requirement that you cannot point just = to any other node, but a node that is part of the actual underlay. Likewis= e, in the case of a TP, the supporting TP cannot just be any other TP, but = a TP in the underlay, itself contained in a supporting node. =20 In the case of the opstate solution, you would need to distinguish differen= t paths based on whether the supporting is opstate or not, and you would li= kewise have to reflect the same in the constraints to make sure that the su= pporting is part of the underlay and not a "random" resource, but one that = makes sense (e.g. supporting TP part of a supporting node, etc). There are= 3 cases: opstate on opstate, configured on configured, and configured on = opstate. =20 The resulting conditions make the model considerable more complex. More co= mplex means harder to use and extend. The alternative is to not model thos= e constraints but put them into the description, thus punting the problem f= rom the framework to the user. This would strike me as SMIv2-ish, which is= a route that I think with a YANG model is better to avoid. =20 --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Friday, February 03, 2017 10:12 AM To: Xufeng Liu ; Martin Bjorklund Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yan= g-l3-topology-08: (with COMMENT) [Xufeng] Right. If we do so, the approach will be different from RFC7223, a= nd requires the capability that a "config true" leafref references a "confi= g false" leaf. I think my proposal was misunderstood, so here's a more complete example: Assume the following schema is used by client/servers that implement the lo= ng-term opstate solution presented in the revised-datastores draft: module foo { container nodes { config true; list node { key "name"; leaf name { type string; } leaf dependency { type leafref { path "../node/name" require-instance false; description "In the case when a configured node (i.e. in the running= DS) has a dependency on a node that is not configured, the = system may try to resolve the dependency as operational state = data (i.e. in the operational-state DS). As operational sta= te=20 data may have a lifecycle independent of configuration,= there is no guarantee that the opstate data will exist. Ther= efore, application of the configuration node is conditional, r= esulting in an effect much like pre-provisioning interfaces in R= FC 7223."; } } } } } Specifically, note that the leafref is from one config true node to another= config true node. I understand that the semantics are almost as if it wer= e like a config true node were pointing to a config false node, but I belie= ve that this should be okay, that is, that we should specifically define th= is convention as okay. Assuming that we're okay with the above, we proposal for a near-term soluti= on, that does NOT utilize the opstate solution, follows: module foo { container nodes { config true; list node { key "name"; leaf name { type string; } leaf dependency { type leafref { path "../node/name" require-instance false; description "In the case when a configured node (i.e. in the running= DS) has a dependency on a node that is not configured, the = system may try to resolve the dependency as operational state = data (i.e. under the /nodes-state tree). As operational sta= te=20 data may have a lifecycle independent of configuration,= there is no guarantee that the opstate data will exist. Ther= efore, application of the configuration node is conditional, r= esulting in an effect much like pre-provisioning interfaces in R= FC 7223."; } } } } container nodes-state { config false; list node { key "name"; leaf name { type string; } leaf dependency { type leafref { path "../node/name" require-instance false; } } } } } This module is semantically identical to the first, but now, in additional = to the leafref potentially hopping datastores, it also needs to hop paths (= i.e. s/nodes/nodes-state/). Note the minute change in the first sentence of= the description statement. Yes, it's a hack, but since the hopping is imp= lemented internally anyway, maybe it's okay as a stop-gap short-term soluti= on? Kent _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Feb 13 19:02:33 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D611A1294CC; Mon, 13 Feb 2017 19:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPl6mCCWyk4Y; Mon, 13 Feb 2017 19:02:24 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0114.outbound.protection.outlook.com [104.47.41.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B698C1293F3; Mon, 13 Feb 2017 19:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hLkIyLOuu8Z6/2uOqj+UD7smsePCHxed3zy4DZeheWM=; b=d609NY3+G0oWuzYbrEjBn1kKA+q+M0KHx5MpwNCVTf3a43GIs+0k5gPJ/yvbMPqbudiihFjULguvZmo5NhKoRRFvhgunV2lf50v54mQU+WUsFXXNNDUvFQ2oclApy2/z91wWePJxc8DVBAwb9CzCGFr2J2d1/7CMvV0QpyQYYfA= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 14 Feb 2017 03:02:22 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.011; Tue, 14 Feb 2017 03:02:22 +0000 From: Kent Watsen To: "i2rs@ietf.org" Thread-Topic: modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9g== Date: Tue, 14 Feb 2017 03:02:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 02dbe24f-0457-4317-5611-08d45485e5db x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:aSi0uQhztQPy0I00bJszzc0Ck0iOieRDyTThXZ+zwiHDghWuKuWmpQf7xIeUczeJ8tP4Q50tO5wO7Ru7+YMEj/dHeeEJyMDPoELOVPumEDvMMQR8nrBrV3MCnoB1eCI5HPrPqp8Jum4YmeWzH6ECbt8mK9R3xlFebHni3IE4k54tQ7x/UzFtzb9seJNrrfKU40reqr9qpBxnqtaPoE/ve40oBcpRyJiJUwevqqfhVuB7wdNAOaEXAWRB4CR/d0W/h31L5CXkUveaHDImUck/FQoogl/oSwzeDMsqnXjK9dbczGJdh2JirGdI/h2P3ucJT3bJN08ffM0GF2zNJohZUaCbo1JfFi5TBrEKuTtLKi4FP41X1V/cOD9lB22dmmT0IyX6wS8JfyGDa+3qwNVWAlf6/5qOT0FSIenlAMAdSZkDFKywyfYBePB/+o8wPBuKIpw15fVr+kohadTS4gBNz7unEal74it6jYTxiYQOjJUYG4ILaURjMELnHGJ7VoDqbFKZy4f0t5ylzlHXx48SYA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(199003)(189002)(52314003)(53754006)(6512007)(25786008)(6436002)(6306002)(6506006)(54356999)(5640700003)(99286003)(101416001)(83716003)(7736002)(6486002)(305945005)(83506001)(82746002)(50986999)(77096006)(6916009)(4001350100001)(3280700002)(86362001)(2906002)(53936002)(38730400002)(3660700001)(2900100001)(450100001)(122556002)(33656002)(97736004)(110136004)(4326007)(8936002)(8676002)(92566002)(81166006)(230783001)(81156014)(189998001)(66066001)(36756003)(68736007)(3846002)(102836003)(6116002)(2351001)(105586002)(106116001)(2501003)(5660300001)(106356001)(81003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <067BE61197D8D34584B8EBC789B28B00@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 03:02:22.8722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: yang-doctors Subject: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 03:02:27 -0000 SGkgQWxsLA0KDQpJdCdzIGJlZW4gcXVpZXQgb24gdGhlIGxpc3QgYXMgYSBzbWFsbCBncm91cCBv ZiB1cyAoQWxleCwgWHVmZW5nLCBQYXZhbiwgYW5kIG15c2VsZikgd2VudCBvZmZsaW5lIHRvIGRp c2N1c3MgZm9yIGEgYml0IGJlZm9yZSBicmluZ2luZyBiYWNrIHRvIHRoZSBncm91cCwgd2hpY2gg SSdtIGRvaW5nIG5vdy4NCg0KUmVnYXJkaW5nIHJlc29sdmluZyB0aGUgbW9kZWxpbmcgdGhlIGlz c3VlLCB3ZSB3ZW50IHRocm91Z2ggbmVhcmx5IGEgZG96ZW4gaWRlYXMgdGhhdCB3ZSd2ZSBuYXJy b3dlZCBkb3duIHRvIHR3by4gIFdlIGRpc2N1c3NlZCB0aGUgcHJvcy9jb25zLCBidXQgc2luY2Ug d2UgZWFjaCBlbXBoYXNpemUgZGlmZmVyZW50IHZhbHVlcywgd2Ugd2VyZSB1bmFibGUgdG8gcmVh Y2ggYSBjb25zZW5zdXMgYW1vbmdzdCBvdXJzZWx2ZXMuICBXZSdyZSBob3BpbmcgdGhhdCBicmlu Z2luZyB0aGUgZGlzY3Vzc2lvbiBoZXJlIHdpbGwgYnJpbmcgbW9yZSBwZXJzcGVjdGl2ZXMgYW5k IHJlc29sdmUgdGhpcyBpc3N1ZS4NCg0KDQpPUFRJT04gMTogc2VwYXJhdGUgL2ZvbyBhbmQgL2Zv by1zdGF0ZSB0cmVlcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KVGhpcyBvcHRpb24gd2FzL2lzIGRlc2NyaWJlZCBoZXJlOiAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pMnJzL2N1cnJlbnQvbXNnMDQzMTYuaHRtbC4NCg0KUFJP UzoNCiAgYSkgZG9lcyBOT1QgYnJlYWsgbGVnYWN5IGNsaWVudHMgKGhvdyB3ZSBnb3QgaGVyZSkN CiAgYikgY29uc2lzdGVudCB3aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYgbW9kdWxl cw0KICBjKSBhYmxlIHRvIHNob3cgaWYvaG93IG9wc3RhdGUgbWF5IGRpZmZlciBmcm9tIGNvbmZp Z3VyZWQgdmFsdWVzDQoNCkNPTlM6DQogIGEpIHF1ZXN0aW9uYWJseSB2YWxpZCBZQU5HIGxlYWZy ZWYgdXNhZ2UNCiAgYikgY29tcGxleCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gKHRvIGhhbmRsZSBy ZXF1aXJlLWluc3RhbmNlIGZhbHNlKQ0KICBjKSBldmVudHVhbGx5IHRoZSBtb2R1bGUgd291bGQg bmVlZCB0byBtaWdyYXRlIHRvIHRoZSBsb25nLXRlcm0gDQogICAgIHNvbHV0aW9uLCB3aGljaCB3 b3VsZCByZXN1bHQgaW4gbmVlZGluZyB0byBhbHNvIHJld3JpdGUgYWxsDQogICAgIG1vZHVsZXMg dGhhdCBoYXZlIGF1Z21lbnRlZCBpdCAoZS5nLiwgaWV0Zi10ZS10b3BvbG9neSkuDQogIGQpIGxl YWZyZWYgcGF0aCBleHByZXNzaW9ucyByZWFsbHkgb25seSB3b3JrIGZvciBjb25maWd1cmF0aW9u IGRhdGEsDQogICAgIHRob3VnaCBhIGNsZXZlciBzZXJ2ZXIgY291bGQgaGF2ZSBhIHNwZWNpYWwg YWJpbGl0eSB0byBwZWFrIGF0DQogICAgIHRoZSBvcHN0YXRlIHZhbHVlcyB3aGVuIGRvaW5nIHZh bGlkYXRpb25zLiAgT2YgY291cnNlLCB3aXRoIA0KICAgICByZXF1aXJlLWluc3RhbmNlIGlzIGZh bHNlLCB0aGUgdmFsdWUgb2YgbGVhZnJlZiBiYXNlZCB2YWxpZGF0aW9uDQogICAgIGNoZWNraW5n IGlzIG5lZ2F0ZWQgYW55d2F5LCBldmVuIGZvciBjb25maWcgdHJ1ZSBub2Rlcywgc28gdGhpcw0K ICAgICBtYXkgbm90IG1hdHRlciBtdWNoLg0KDQoNCg0KT1BUSU9OIDI6IGV4cGxpY2l0IGNsaWVu dC1vcHRpb24gdG8gYWxzbyByZXR1cm4gdGFnZ2VkIG9wc3RhdGUgZGF0YQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpUaGlzIG9wdGlvbiB0YWtlcyBhIGNvdXBsZSBmb3Jtcy4gIFRoZSBmaXJzdCBpcyBtb2R1bGUt c3BlY2lmaWMgYW5kDQp0aGUgc2Vjb25kIGlzIGdlbmVyaWMuICBJbiBib3RoIGNhc2VzLCB0aGUg aWRlYSBpcyBtb2RlbGVkIGFmdGVyIHRoZQ0Kd2l0aC1kZWZhdWx0cyBzb2x1dGlvbiAoUkZDNjI0 MyksIHdoZXJlaW4gdGhlIGNsaWVudCBwYXNzZXMgYSBzcGVjaWFsDQpmbGFnIGludG8gPGdldC1j b25maWc+IGNhdXNpbmcgdGhlIHNlcnZlciB0byBhbHNvIHJldHVybiBvcHN0YXRlIGRhdGEsDQpo YXZpbmcgYSBzcGVjaWFsIG1ldGFkYXRhIGZsYWcgc2V0LCBpbnRlcm1pbmdsZWQgd2l0aCB0aGUg Y29uZmlndXJhdGlvbg0KZGF0YS4NCg0KDQoyQTogTW9kdWxlLXNwZWNpZmljIHZlcnNpb24NCg0K ICAgbW9kdWxlIGZvbyB7DQogICAgICBpbXBvcnQgaWV0Zi1uZXRjb25mIHsgcHJlZml4IG5jOyB9 DQogICAgICBpbXBvcnQgaWV0Zi15YW5nLW1ldGFkYXRhIHsgcHJlZml4IG1kOyB9DQogICAgICBt ZDphbm5vdGF0aW9uIHNlcnZlci1wcm92aWRlZCB7DQogICAgICAgICB0eXBlIGJvb2xlYW47DQog ICAgICB9DQogICAgICBjb250YWluZXIgbm9kZXMgew0KICAgICAgICAgY29uZmlnIHRydWU7DQog ICAgICAgICBsaXN0IG5vZGUgew0KICAgICAgICAgICAga2V5ICJuYW1lIjsNCiAgICAgICAgICAg IGxlYWYgbmFtZSB7IHR5cGUgc3RyaW5nOyB9DQogICAgICAgICAgICBsZWFmIGRlcGVuZGVuY3kg ew0KICAgICAgICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCiAgICAgICAgICAgICAgICAgcGF0aCAi Li4vbm9kZS9uYW1lIg0KICAgICAgICAgICAgICAgICByZXF1aXJlLWluc3RhbmNlIGZhbHNlOw0K ICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAgICAgfQ0KICAg ICAgYXVnbWVudCAvbmM6Z2V0LWNvbmZpZy9uYzppbnB1dCB7DQogICAgICAgICBsZWFmIHdpdGgt c2VydmVyLXByb3ZpZGVkIHsNCiAgICAgICAgICAgIHR5cGUgYm9vbGVhbjsNCiAgICAgICAgIH0N CiAgICAgIH0NCiAgIH0NCg0KRm9yIGluc3RhbmNlOg0KDQogIDxnZXQtY29uZmlnPg0KICAgIDxz b3VyY2U+DQogICAgICA8cnVubmluZy8+DQogICAgPC9zb3VyY2U+DQogICAgPHdpdGgtc2VydmVy LXByb3ZpZGVkLz4NCiAgIDwvZ2V0LWNvbmZpZz4NCg0KICAgPGRhdGE+DQogICAgIDxub2Rlcz4N CiAgICAgICA8bm9kZT4NCiAgICAgICAgIDxuYW1lPm92ZXJsYXktbm9kZTwvbmFtZT4NCiAgICAg ICAgIDxkZXBlbmRlbmN5PnVuZGVybGF5LW5vZGU8L2RlcGVuZGVuY3k+DQogICAgICAgPC9ub2Rl Pg0KICAgICAgIDxub2RlIGZvbzpzZXJ2ZXItcHJvdmlkZWQ9J3RydWUnPg0KICAgICAgICAgPG5h bWU+dW5kZXJsYXktbm9kZTwvbmFtZT4NCiAgICAgICA8L25vZGU+DQogICAgIDwvbm9kZXM+DQog ICA8L2RhdGE+DQoNClBST1M6DQogIGEpIGRvZXMgTk9UIGJyZWFrIGxlZ2FjeSBjbGllbnRzICho b3cgd2UgZ290IGhlcmUpDQogIGIpIGhhdmluZyBhbGwgZGF0YSBpbiBvbmUgbWVyZ2VkIHRyZWUg aXMgc2ltcGxlciB0byBwcm9jZXNzIA0KICAgICB0aGFuIHR3byBzZXBhcmF0ZSBxdWVyaWVzLg0K ICBjKSBtb2R1bGUgZG9lc24ndCBoYXZlIHRvIGJlIHJld3JpdHRlbiBmb3IgcmV2aXNlZC1kYXRh c3RvcmVzOw0KICAgICB0aGUgJ3dpdGgtc2VydmVyLXByb3ZpZGVkJyBzd2l0Y2ggd291bGQganVz dCBub3QgYmUgcGFzc2VkDQogICAgIGJ5IG5ldyBvcHN0YXRlLWF3YXJlIGNsaWVudHMuDQoNCkNP TlM6DQogIGEpIGluY29uc2lzdGVudCB3aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYg bW9kdWxlcw0KICBiKSB1bmNsZWFyIGhvdyB0byBtb2RlbCAnd2l0aC1zZXJ2ZXItcHJvdmlkZWQn IGZvciBSRVNUQ09ORg0KICAgICAoanVzdCB1c2UgYSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgdG8g ZGVmaW5lIGEgcXVlcnkgcGFyYW0/KQ0KICBjKSB1bmFibGUgdG8gcmV0dXJuIHRoZSBvcHN0YXRl IHZhbHVlIGZvciBhbnkgY29uZmlndXJlZCBub2RlDQogICAgIChpcyBpdCBuZWVkZWQgaGVyZT8p DQogIGQpIHJlcXVpcmVzIHNlcnZlciB0byBzdXBwb3J0IG1ldGFkYXRhLCB3aGljaCBpcyBhIHJl bGF0aXZlbHkNCiAgICAgbmV3IGNvbmNlcHQgYW5kIG1heWJlIG5vdCB3ZWxsIHN1cHBvcnRlZCBi eSBzZXJ2ZXJzLg0KICBlKSBvbmx5IGNoYW5nZXMgcHJlc2VudGF0aW9uLWxheWVyIChkb2Vzbid0 IGNoYW5nZSB0aGUgZmFjdCANCiAgICAgdGhhdCAnc2VydmVyLXByb3ZpZGVkJyBkYXRhIGlzIG5v dCBjb25maWd1cmF0aW9uKSwgdGh1cyB0aGUNCiAgICAgbGVhZnJlZiBwYXRoIGV4cHJlc3Npb25z IHN0aWxsIGRvbid0IHdvcmsgcXVpdGUgdGhlIHdheSBhcw0KICAgICBkZXNpcmVkLCB0aG91Z2gg YSBjbGV2ZXIgc2VydmVyIGNvdWxkIGhhdmUgYSBzcGVjaWFsIGFiaWxpdHkNCiAgICAgdG8gcGVh ayBhdCB0aGUgb3BzdGF0ZSB2YWx1ZXMgd2hlbiBkb2luZyB2YWxpZGF0aW9ucy4gT2YgDQogICAg IGNvdXJzZSwgd2l0aCByZXF1aXJlLWluc3RhbmNlIGlzIGZhbHNlLCB0aGUgdmFsdWUgb2YgbGVh ZnJlZg0KICAgICBiYXNlZCB2YWxpZGF0aW9uIGNoZWNraW5nIGlzIG5lZ2F0ZWQgYW55d2F5LCBl dmVuIGZvciBjb25maWcNCiAgICAgdHJ1ZSBub2Rlcywgc28gdGhpcyBtYXkgbm90IG1hdHRlciBt dWNoLg0KDQoNCg0KDQoyQjogR2VuZXJpYyB2ZXJzaW9uDQoNClRoZSBnZW5lcmljIHZlcnNpb24g aXMgbXVjaCB0aGUgc2FtZSwgYnV0IHJhdGhlciB0aGFuIGxldHRpbmcgdGhlDQpzb2x1dGlvbiBi ZSBsaW1pdGVkIHRvIHRoaXMgb25lIG1vZHVsZSwgdGhlIGlkZWEgaXMgdG8gZ2VuZXJhbGl6ZQ0K aXQgc28gaXQgY291bGQgYmUgYSBzZXJ2ZXItbGV2ZWwgZmVhdHVyZS4gIEhhdmluZyBhIGdlbmVy aWMgUlBDIHRvDQpyZXR1cm4gZGF0YSBmcm9tIG1vcmUgdGhhbiBvbmUgRFMgYXQgYSB0aW1lIHdh cyBzb21ldGhpbmcgdGhhdCB3YXMNCmRpc2N1c3NlZCB+MS41IHllYXJzIGFnbyB3aGVuIHdlIHdl cmUga2lja2luZyBvZmYgdGhlIG9wc3RhdGUgZWZmb3J0Lg0KDQpUaGUgUFJPUyBhbmQgQ09OUyBh cmUgc2ltaWxhciwgYnV0IHRoZXJlIGFyZSBhZGRpdGlvbmFsIENPTlMgaW4gdGhlDQpnZW5lcmlj IGNhc2UuICBUaGUgbWFpbiBvbmVzIGJlaW5nIDEpIGhvdyB0byBzaW11bHRhbmVvdXNseSByZXR1 cm4gDQpib3RoIHRoZSBjb25maWcgYW5kIG9wc3RhdGUgdmFsdWVzIGZvciBhIG5vZGUgKHNwbGl0 IGF0IHRoZSBsZWF2ZXMpDQphbmQgMikgaG93IHRvIGhhbmRsZSBzb21lIFlBTkcgc3RhdGVtZW50 cyBzdWNoIGFzIHByZXNlbmNlIGNvbnRhaW5lcnMNCmFuZCBjaG9pY2Ugbm9kZXMuICBGb3IgdGhp cyByZWFzb24sICgyQikgaXMgTk9UIGNvbnNpZGVyZWQgYSB2aWFibGUNCnNvbHV0aW9uIGFuZCBp cyBvbmx5IGhlcmUgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgaXQgd2FzIGRpc2N1c3NlZC4NCg0K DQoNCklmIHRoZXJlIGFyZSBhbnkgb3RoZXIgb3B0aW9ucyBwZW9wbGUgd2FudCB0byBzdWdnZXN0 LCBwbGVhc2UgZG8gc28gbm93IQ0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQo= From nobody Tue Feb 14 03:09:16 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB00129568; Tue, 14 Feb 2017 03:09:14 -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, 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 5H9puXUe5ZCf; Tue, 14 Feb 2017 03:09:13 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAD1293E8; Tue, 14 Feb 2017 03:09:12 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id CCD4A1AE034F; Tue, 14 Feb 2017 12:09:10 +0100 (CET) Date: Tue, 14 Feb 2017 12:09:10 +0100 (CET) Message-Id: <20170214.120910.763903356597953031.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, yang-doctors@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 11:09:15 -0000 Hi, Kent Watsen wrote: > Hi All, > > It's been quiet on the list as a small group of us (Alex, Xufeng, > Pavan, and myself) went offline to discuss for a bit before bringing > back to the group, which I'm doing now. > > Regarding resolving the modeling the issue, we went through nearly a > dozen ideas that we've narrowed down to two. We discussed the > pros/cons, but since we each emphasize different values, we were > unable to reach a consensus amongst ourselves. We're hoping that > bringing the discussion here will bring more perspectives and resolve > this issue. > > > OPTION 1: separate /foo and /foo-state trees > -------------------------------------------- > > This option was/is described here: > https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > PROS: > a) does NOT break legacy clients (how we got here) > b) consistent with convention used in many IETF modules > c) able to show if/how opstate may differ from configured values > > CONS: > a) questionably valid YANG leafref usage What does this mean? > b) complex server implementation (to handle require-instance false) Can you elaborate on this one? > c) eventually the module would need to migrate to the long-term > solution, which would result in needing to also rewrite all > modules that have augmented it (e.g., ietf-te-topology). > d) leafref path expressions really only work for configuration data, > though a clever server could have a special ability to peak at > the opstate values when doing validations. Of course, with > require-instance is false, the value of leafref based validation > checking is negated anyway, even for config true nodes, so this > may not matter much. > > > > OPTION 2: explicit client-option to also return tagged opstate data > ------------------------------------------------------------------- > > This option takes a couple forms. The first is module-specific and > the second is generic. In both cases, the idea is modeled after the > with-defaults solution (RFC6243), wherein the client passes a special > flag into causing the server to also return opstate data, > having a special metadata flag set, intermingled with the > configuration > data. > > > 2A: Module-specific version > > module foo { > import ietf-netconf { prefix nc; } > import ietf-yang-metadata { prefix md; } > md:annotation server-provided { > type boolean; > } > container nodes { > config true; > list node { > key "name"; > leaf name { type string; } > leaf dependency { > type leafref { > path "../node/name" > require-instance false; > } > } > } > } > augment /nc:get-config/nc:input { > leaf with-server-provided { > type boolean; > } > } > } I don't think this solution is substantially different from the solution in draft-ietf-i2rs-yang-network-topo-10. You have just moved a config false leaf to a meta-data annotation. This solution suffers from the same problems as the solution in draft-ietf-i2rs-yang-network-topo-10. /martin > > For instance: > > > > > > > > > > > > overlay-node > underlay-node > > > underlay-node > > > > > PROS: > a) does NOT break legacy clients (how we got here) > b) having all data in one merged tree is simpler to process > than two separate queries. > c) module doesn't have to be rewritten for revised-datastores; > the 'with-server-provided' switch would just not be passed > by new opstate-aware clients. > > CONS: > a) inconsistent with convention used in many IETF modules > b) unclear how to model 'with-server-provided' for RESTCONF > (just use a description statement to define a query param?) > c) unable to return the opstate value for any configured node > (is it needed here?) > d) requires server to support metadata, which is a relatively > new concept and maybe not well supported by servers. > e) only changes presentation-layer (doesn't change the fact > that 'server-provided' data is not configuration), thus the > leafref path expressions still don't work quite the way as > desired, though a clever server could have a special ability > to peak at the opstate values when doing validations. Of > course, with require-instance is false, the value of leafref > based validation checking is negated anyway, even for config > true nodes, so this may not matter much. > > > > > 2B: Generic version > > The generic version is much the same, but rather than letting the > solution be limited to this one module, the idea is to generalize > it so it could be a server-level feature. Having a generic RPC to > return data from more than one DS at a time was something that was > discussed ~1.5 years ago when we were kicking off the opstate effort. > > The PROS and CONS are similar, but there are additional CONS in the > generic case. The main ones being 1) how to simultaneously return > both the config and opstate values for a node (split at the leaves) > and 2) how to handle some YANG statements such as presence containers > and choice nodes. For this reason, (2B) is NOT considered a viable > solution and is only here so that it's clear that it was discussed. > > > > If there are any other options people want to suggest, please do so > now! > > Thanks, > Kent > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Feb 14 05:55:58 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB28E129645 for ; Tue, 14 Feb 2017 05:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htxTFECmBksC for ; Tue, 14 Feb 2017 05:55:53 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA912129621 for ; Tue, 14 Feb 2017 05:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ovby2pmT+m3NcyYzG45+grsygt+jlrGtLxfzcLhQfTo=; b=NSvRgPyrr1g0dnQDu8ova2FpMQkXX+ctTxEDH8ueDzqsC/OV3s58R/B2ZtCXg3qflli/TrHgEho6GC1wwmu1zea0xpsEJUHJAzaXBxtkayJkui9Vtv+XPEAU9aTpPIFzKwyHQkvvgbmHiepdHzYjm9Fzfj3qcDPwcXqdIAhNg20= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 14 Feb 2017 13:55:51 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.011; Tue, 14 Feb 2017 13:55:51 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFoWKoA///awYA= Date: Tue, 14 Feb 2017 13:55:51 +0000 Message-ID: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> References: <20170214.120910.763903356597953031.mbj@tail-f.com> In-Reply-To: <20170214.120910.763903356597953031.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 9a077415-d5f3-400a-da4d-08d454e13032 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:SesiuKO5S2QMkKIXR6zBY8+Y0Dl0jEFMHioFxp0ezKV3YS7YuFCjNJK2YySW0PqdFBYtQ0sPQndhUuGJP+wIbtebQiMZNpjTqgSAthlQBZq3VvfEndBKlbvAYYkks+K7pXX74+cTgXzO3phcxJXvTCAD8zCR8O/Y4yUWCM46pLqVSGlas7DPEmONYLXJSJzZJkHR6VATMz2GZqNeU8kcCQM9YwYGGavy9yGngyWaZEsldsoxd+3OFeTvXxXpXS3H3IPXI6LkqYjDt8wvMo55Q16dSBEkGTKZQppfEJY6+aQ7/U9QjYsip9OetjInUJPiLHanpscr1SWGqAQ/xaKiT25azhTyd+dpF1GcSbMxw5egNo6pryA5IdjnRGAygOQWJDmBz9oMIydySbpmaVk8zB/PZvGjbqCaiA66tqQlsqADElnza86Wn3zaaDxscrgEM6HpQ8fEJMYSgQ9ZMQcsU30VnT7SxRUyGTOajofd8Apkr81LobrLICDjiM1LwDuG5HHjp0YksIhwcl3Z3Zg+ow== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(199003)(189002)(52314003)(82746002)(83506001)(189998001)(38730400002)(53936002)(83716003)(6246003)(110136004)(4326007)(25786008)(50986999)(76176999)(54356999)(86362001)(122556002)(6436002)(77096006)(6486002)(101416001)(33656002)(6506006)(3660700001)(2906002)(5660300001)(66066001)(230783001)(229853002)(106356001)(3846002)(305945005)(102836003)(7736002)(6116002)(6916009)(99286003)(8936002)(92566002)(2950100002)(81156014)(2900100001)(36756003)(4001350100001)(106116001)(8676002)(105586002)(81003)(68736007)(81166006)(6306002)(97736004)(3280700002)(6512007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 13:55:51.7274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 13:55:56 -0000 DQoNClttb3ZpbmcgeWFuZy1kb2N0b3JzIHRvIEJDQ10NCg0KDQo+PiBPUFRJT04gMTogc2VwYXJh dGUgL2ZvbyBhbmQgL2Zvby1zdGF0ZSB0cmVlcw0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gVGhpcyBvcHRpb24gd2FzL2lzIGRlc2NyaWJl ZCBoZXJlOg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pMnJzL2N1 cnJlbnQvbXNnMDQzMTYuaHRtbC4NCj4+IA0KPj4gUFJPUzoNCj4+ICAgYSkgZG9lcyBOT1QgYnJl YWsgbGVnYWN5IGNsaWVudHMgKGhvdyB3ZSBnb3QgaGVyZSkNCj4+ICAgYikgY29uc2lzdGVudCB3 aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYgbW9kdWxlcw0KPj4gICBjKSBhYmxlIHRv IHNob3cgaWYvaG93IG9wc3RhdGUgbWF5IGRpZmZlciBmcm9tIGNvbmZpZ3VyZWQgdmFsdWVzDQo+ PiANCj4+IENPTlM6DQo+PiAgIGEpIHF1ZXN0aW9uYWJseSB2YWxpZCBZQU5HIGxlYWZyZWYgdXNh Z2UNCj4NCj4gV2hhdCBkb2VzIHRoaXMgbWVhbj8NCg0KSSdtIHJlZmVycmluZyB0byBob3cgdGhl IGRlc2NyaXB0aW9uIHN0YXRlbWVudCBleHBsYWlucyB0aGF0DQp0aGUgc2VydmVyIG1heSBsb29r IHRvIG9wZXJhdGlvbmFsIHN0YXRlIGluIG9yZGVyIHRvIHJlc29sdmUNCnRoZSBsZWFmcmVmLCB3 aGljaCBpcyB0byByZXN1bHQgaW4gYmVoYXZpb3Igc2ltaWxhciB0byANCnByZS1jb25maWd1cmF0 aW9uIGluIFJGQyA3MjIzLg0KDQoNCg0KPj4gICBiKSBjb21wbGV4IHNlcnZlciBpbXBsZW1lbnRh dGlvbiAodG8gaGFuZGxlIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2UpDQo+DQo+Q2FuIHlvdSBlbGFi b3JhdGUgb24gdGhpcyBvbmU/DQoNClRoaXMgaXMgcHJpbWFyaWx5IGEgcmVmbGVjdGlvbiBvZiB0 aGUgQ09OIGxpc3RlZCBhYm92ZSwgaW4gdGhhdA0KaXQgc2VlbXMgdGhhdCBhIHNlcnZlciB3b3Vs ZCBuZWVkIHRvIGhhdmUgc3BlY2lhbCBoYW5kbGluZyBmb3IgDQp3aGVuIGRlcGVuZGVuY2llcyB0 cmFuc2l0aW9uIGZyb20gYmVpbmcgcHJlc2VudCB0byBub3QtcHJlc2VudA0KYW5kIHZpY2UgdmVy c2EsIG11Y2ggbGlrZSB0aGUgY29kZSB0byBoYW5kbGUgd2hlbiBhIHBoeXNpY2FsDQpjYXJkIGlz IHBsdWdnZWQgaW4gb3IgcmVtb3ZlZC4NCg0KTm90ZTogSSBzaG91bGQndmUgbGlzdGVkIHRoaXMg YXMgYSBDT04gZm9yIE9QVElPTiAyIGFzIHdlbGwuDQoNCg0KDQo+PiAgIGMpIGV2ZW50dWFsbHkg dGhlIG1vZHVsZSB3b3VsZCBuZWVkIHRvIG1pZ3JhdGUgdG8gdGhlIGxvbmctdGVybSANCj4+ICAg ICAgc29sdXRpb24sIHdoaWNoIHdvdWxkIHJlc3VsdCBpbiBuZWVkaW5nIHRvIGFsc28gcmV3cml0 ZSBhbGwNCj4+ICAgICAgbW9kdWxlcyB0aGF0IGhhdmUgYXVnbWVudGVkIGl0IChlLmcuLCBpZXRm LXRlLXRvcG9sb2d5KS4NCj4+ICAgZCkgbGVhZnJlZiBwYXRoIGV4cHJlc3Npb25zIHJlYWxseSBv bmx5IHdvcmsgZm9yIGNvbmZpZ3VyYXRpb24gZGF0YSwNCj4+ICAgICAgdGhvdWdoIGEgY2xldmVy IHNlcnZlciBjb3VsZCBoYXZlIGEgc3BlY2lhbCBhYmlsaXR5IHRvIHBlYWsgYXQNCj4+ICAgICAg dGhlIG9wc3RhdGUgdmFsdWVzIHdoZW4gZG9pbmcgdmFsaWRhdGlvbnMuICBPZiBjb3Vyc2UsIHdp dGggDQo+PiAgICAgIHJlcXVpcmUtaW5zdGFuY2UgaXMgZmFsc2UsIHRoZSB2YWx1ZSBvZiBsZWFm cmVmIGJhc2VkIHZhbGlkYXRpb24NCj4+ICAgICAgY2hlY2tpbmcgaXMgbmVnYXRlZCBhbnl3YXks IGV2ZW4gZm9yIGNvbmZpZyB0cnVlIG5vZGVzLCBzbyB0aGlzDQo+PiAgICAgIG1heSBub3QgbWF0 dGVyIG11Y2guDQo+PiANCj4+IA0KPj4gDQo+PiBPUFRJT04gMjogZXhwbGljaXQgY2xpZW50LW9w dGlvbiB0byBhbHNvIHJldHVybiB0YWdnZWQgb3BzdGF0ZSBkYXRhDQo+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ PiANCj4+IFRoaXMgb3B0aW9uIHRha2VzIGEgY291cGxlIGZvcm1zLiAgVGhlIGZpcnN0IGlzIG1v ZHVsZS1zcGVjaWZpYyBhbmQNCj4+IHRoZSBzZWNvbmQgaXMgZ2VuZXJpYy4gIEluIGJvdGggY2Fz ZXMsIHRoZSBpZGVhIGlzIG1vZGVsZWQgYWZ0ZXIgdGhlDQo+PiB3aXRoLWRlZmF1bHRzIHNvbHV0 aW9uIChSRkM2MjQzKSwgd2hlcmVpbiB0aGUgY2xpZW50IHBhc3NlcyBhIHNwZWNpYWwNCj4+IGZs YWcgaW50byA8Z2V0LWNvbmZpZz4gY2F1c2luZyB0aGUgc2VydmVyIHRvIGFsc28gcmV0dXJuIG9w c3RhdGUgZGF0YSwNCj4+IGhhdmluZyBhIHNwZWNpYWwgbWV0YWRhdGEgZmxhZyBzZXQsIGludGVy bWluZ2xlZCB3aXRoIHRoZQ0KPj4gY29uZmlndXJhdGlvbg0KPj4gZGF0YS4NCj4+IA0KPj4gDQo+ PiAyQTogTW9kdWxlLXNwZWNpZmljIHZlcnNpb24NCj4+IA0KPj4gICAgbW9kdWxlIGZvbyB7DQo+ PiAgICAgICBpbXBvcnQgaWV0Zi1uZXRjb25mIHsgcHJlZml4IG5jOyB9DQo+PiAgICAgICBpbXBv cnQgaWV0Zi15YW5nLW1ldGFkYXRhIHsgcHJlZml4IG1kOyB9DQo+PiAgICAgICBtZDphbm5vdGF0 aW9uIHNlcnZlci1wcm92aWRlZCB7DQo+PiAgICAgICAgICB0eXBlIGJvb2xlYW47DQo+PiAgICAg ICB9DQo+PiAgICAgICBjb250YWluZXIgbm9kZXMgew0KPj4gICAgICAgICAgY29uZmlnIHRydWU7 DQo+PiAgICAgICAgICBsaXN0IG5vZGUgew0KPj4gICAgICAgICAgICAga2V5ICJuYW1lIjsNCj4+ ICAgICAgICAgICAgIGxlYWYgbmFtZSB7IHR5cGUgc3RyaW5nOyB9DQo+PiAgICAgICAgICAgICBs ZWFmIGRlcGVuZGVuY3kgew0KPj4gICAgICAgICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCj4+ICAg ICAgICAgICAgICAgICAgcGF0aCAiLi4vbm9kZS9uYW1lIg0KPj4gICAgICAgICAgICAgICAgICBy ZXF1aXJlLWluc3RhbmNlIGZhbHNlOw0KPj4gICAgICAgICAgICAgICAgfQ0KPj4gICAgICAgICAg ICAgfQ0KPj4gICAgICAgICAgfQ0KPj4gICAgICAgfQ0KPj4gICAgICAgYXVnbWVudCAvbmM6Z2V0 LWNvbmZpZy9uYzppbnB1dCB7DQo+PiAgICAgICAgICBsZWFmIHdpdGgtc2VydmVyLXByb3ZpZGVk IHsNCj4+ICAgICAgICAgICAgIHR5cGUgYm9vbGVhbjsNCj4+ICAgICAgICAgIH0NCj4+ICAgICAg IH0NCj4+ICAgIH0NCj4NCj4gSSBkb24ndCB0aGluayB0aGlzIHNvbHV0aW9uIGlzIHN1YnN0YW50 aWFsbHkgZGlmZmVyZW50IGZyb20gdGhlDQo+IHNvbHV0aW9uIGluIGRyYWZ0LWlldGYtaTJycy15 YW5nLW5ldHdvcmstdG9wby0xMC4gIFlvdSBoYXZlIGp1c3QgbW92ZWQNCj4gYSBjb25maWcgZmFs c2UgbGVhZiB0byBhIG1ldGEtZGF0YSBhbm5vdGF0aW9uLiAgVGhpcyBzb2x1dGlvbiBzdWZmZXJz DQo+IGZyb20gdGhlIHNhbWUgcHJvYmxlbXMgYXMgdGhlIHNvbHV0aW9uIGluDQo+IGRyYWZ0LWll dGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0xMC4NCg0KVGhlcmUgYXJlIHR3byBwcmltYXJ5IGRp ZmZlcmVuY2VzOg0KDQoxKSBJdCBkb2Vzbid0IGJyZWFrIGxlZ2FjeSBjbGllbnRzLCBiZWNhdXNl IGl0IHJlcXVpcmVzIHRoZSBjbGllbnQgdG8NCiAgIGV4cGxpY2l0bHkgcGFzcyBhICd3aXRoLXNl cnZlci1wcm92aWRlZCcgZmxhZyBpbiB0aGUgPGdldC1jb25maWc+DQogICByZXF1ZXN0IGluIG9y ZGVyIHRvIGdldCBiYWNrIHRoZSBleHRlbmRlZCByZXNwb25zZS4gIExpa2V3aXNlLCBpdA0KICAg ZG9lc24ndCBicmVhayBiYWNrdXAvcmVzdG9yZSB3b3JrZmxvd3MsIGFzIHRoZSBzZXJ2ZXIgY2Fu IGRpc2NhcmQNCiAgIGFueSAnc2VydmVyLXByb3ZpZGVkJyBub2RlcyBwYXNzZWQgaW4gYW4gPGVk aXQtY29uZmlnPiBvcGVyYXRpb24uDQogICBMYXN0bHksIGl0IGRvZXNuJ3QgYnJlYWsgPGxvY2s+ Lzx1bmxvY2s+LCBhcyB0aGVyZSBpcyBubyBjb21pbmdsaW5nDQogICBvZiBvcHN0YXRlIGRhdGEg aW4gdGhlICdydW5uaW5nJyBkYXRhc3RvcmUuDQoNCjIpIEl0IGRvZXNuJ3Qgc2F5IGFueXRoaW5n IGFib3V0IGhvdyB0aGUgb3BzdGF0ZSBkYXRhIGlzIHN0b3JlZCBvbiB0aGUNCiAgIHNlcnZlci4g IFRoZSBvcHN0YXRlIGRhdGEgaXMgbm90IG1vZGVsZWQgYXQgYWxsLiAgVGhpcyBhcHByb2FjaCAN CiAgIG9ubHkgZGVmaW5lcyBhIHByZXNlbnRhdGlvbi1sYXllciBmb3JtYXQgZm9yIGhvdyBvcHN0 YXRlIGRhdGEgY2FuDQogICBiZSByZXR1cm5lZCB2aWEgYW4gUlBDLiAgVGhlIHNlcnZlciBpcyBm cmVlIHRvIHBlcnNpc3QgdGhlIG9wc3RhdGUNCiAgIGRhdGEgYW55d2F5IGl0IHdhbnRzLCBwZXJo YXBzIGluIGFuIGludGVybmFsIGRhdGFzdG9yZSBjYWxsZWQgDQogICAnb3BlcmF0aW9uYWwtc3Rh dGUnIG9yIGluIGFuIHViZXItZGF0YXN0b3JlIHdpdGggdGhlIG9wc3RhdGUgZGF0YQ0KICAgZmxh Z2dlZCB3aXRoIGEgZGF0YXN0b3JlPSdvcGVyLXN0YXRlJyBhdHRyaWJ1dGUuICBSZWdhcmRsZXNz LCBpdCdzDQogICBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsIGFuZCB0aGUgY29uY2VwdHVhbCBk YXRhc3RvcmUgbW9kZWwgaXMNCiAgIHByZXNlcnZlZC4NCg0KDQoNCj4gL21hcnRpbg0KDQpLZW50 DQoNCg0KDQoNCj4+IA0KPj4gRm9yIGluc3RhbmNlOg0KPj4gDQo+PiAgIDxnZXQtY29uZmlnPg0K Pj4gICAgIDxzb3VyY2U+DQo+PiAgICAgICA8cnVubmluZy8+DQo+PiAgICAgPC9zb3VyY2U+DQo+ PiAgICAgPHdpdGgtc2VydmVyLXByb3ZpZGVkLz4NCj4+ICAgIDwvZ2V0LWNvbmZpZz4NCj4+IA0K Pj4gICAgPGRhdGE+DQo+PiAgICAgIDxub2Rlcz4NCj4+ICAgICAgICA8bm9kZT4NCj4+ICAgICAg ICAgIDxuYW1lPm92ZXJsYXktbm9kZTwvbmFtZT4NCj4+ICAgICAgICAgIDxkZXBlbmRlbmN5PnVu ZGVybGF5LW5vZGU8L2RlcGVuZGVuY3k+DQo+PiAgICAgICAgPC9ub2RlPg0KPj4gICAgICAgIDxu b2RlIGZvbzpzZXJ2ZXItcHJvdmlkZWQ9J3RydWUnPg0KPj4gICAgICAgICAgPG5hbWU+dW5kZXJs YXktbm9kZTwvbmFtZT4NCj4+ICAgICAgICA8L25vZGU+DQo+PiAgICAgIDwvbm9kZXM+DQo+PiAg ICA8L2RhdGE+DQo+PiANCj4+IFBST1M6DQo+PiAgIGEpIGRvZXMgTk9UIGJyZWFrIGxlZ2FjeSBj bGllbnRzIChob3cgd2UgZ290IGhlcmUpDQo+PiAgIGIpIGhhdmluZyBhbGwgZGF0YSBpbiBvbmUg bWVyZ2VkIHRyZWUgaXMgc2ltcGxlciB0byBwcm9jZXNzIA0KPj4gICAgICB0aGFuIHR3byBzZXBh cmF0ZSBxdWVyaWVzLg0KPj4gICBjKSBtb2R1bGUgZG9lc24ndCBoYXZlIHRvIGJlIHJld3JpdHRl biBmb3IgcmV2aXNlZC1kYXRhc3RvcmVzOw0KPj4gICAgICB0aGUgJ3dpdGgtc2VydmVyLXByb3Zp ZGVkJyBzd2l0Y2ggd291bGQganVzdCBub3QgYmUgcGFzc2VkDQo+PiAgICAgIGJ5IG5ldyBvcHN0 YXRlLWF3YXJlIGNsaWVudHMuDQo+PiANCj4+IENPTlM6DQo+PiAgIGEpIGluY29uc2lzdGVudCB3 aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYgbW9kdWxlcw0KPj4gICBiKSB1bmNsZWFy IGhvdyB0byBtb2RlbCAnd2l0aC1zZXJ2ZXItcHJvdmlkZWQnIGZvciBSRVNUQ09ORg0KPj4gICAg ICAoanVzdCB1c2UgYSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgdG8gZGVmaW5lIGEgcXVlcnkgcGFy YW0/KQ0KPj4gICBjKSB1bmFibGUgdG8gcmV0dXJuIHRoZSBvcHN0YXRlIHZhbHVlIGZvciBhbnkg Y29uZmlndXJlZCBub2RlDQo+PiAgICAgIChpcyBpdCBuZWVkZWQgaGVyZT8pDQo+PiAgIGQpIHJl cXVpcmVzIHNlcnZlciB0byBzdXBwb3J0IG1ldGFkYXRhLCB3aGljaCBpcyBhIHJlbGF0aXZlbHkN Cj4+ICAgICAgbmV3IGNvbmNlcHQgYW5kIG1heWJlIG5vdCB3ZWxsIHN1cHBvcnRlZCBieSBzZXJ2 ZXJzLg0KPj4gICBlKSBvbmx5IGNoYW5nZXMgcHJlc2VudGF0aW9uLWxheWVyIChkb2Vzbid0IGNo YW5nZSB0aGUgZmFjdCANCj4+ICAgICAgdGhhdCAnc2VydmVyLXByb3ZpZGVkJyBkYXRhIGlzIG5v dCBjb25maWd1cmF0aW9uKSwgdGh1cyB0aGUNCj4+ICAgICAgbGVhZnJlZiBwYXRoIGV4cHJlc3Np b25zIHN0aWxsIGRvbid0IHdvcmsgcXVpdGUgdGhlIHdheSBhcw0KPj4gICAgICBkZXNpcmVkLCB0 aG91Z2ggYSBjbGV2ZXIgc2VydmVyIGNvdWxkIGhhdmUgYSBzcGVjaWFsIGFiaWxpdHkNCj4+ICAg ICAgdG8gcGVhayBhdCB0aGUgb3BzdGF0ZSB2YWx1ZXMgd2hlbiBkb2luZyB2YWxpZGF0aW9ucy4g T2YgDQo+PiAgICAgIGNvdXJzZSwgd2l0aCByZXF1aXJlLWluc3RhbmNlIGlzIGZhbHNlLCB0aGUg dmFsdWUgb2YgbGVhZnJlZg0KPj4gICAgICBiYXNlZCB2YWxpZGF0aW9uIGNoZWNraW5nIGlzIG5l Z2F0ZWQgYW55d2F5LCBldmVuIGZvciBjb25maWcNCj4+ICAgICAgdHJ1ZSBub2Rlcywgc28gdGhp cyBtYXkgbm90IG1hdHRlciBtdWNoLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAyQjogR2VuZXJp YyB2ZXJzaW9uDQo+PiANCj4+IFRoZSBnZW5lcmljIHZlcnNpb24gaXMgbXVjaCB0aGUgc2FtZSwg YnV0IHJhdGhlciB0aGFuIGxldHRpbmcgdGhlDQo+PiBzb2x1dGlvbiBiZSBsaW1pdGVkIHRvIHRo aXMgb25lIG1vZHVsZSwgdGhlIGlkZWEgaXMgdG8gZ2VuZXJhbGl6ZQ0KPj4gaXQgc28gaXQgY291 bGQgYmUgYSBzZXJ2ZXItbGV2ZWwgZmVhdHVyZS4gIEhhdmluZyBhIGdlbmVyaWMgUlBDIHRvDQo+ PiByZXR1cm4gZGF0YSBmcm9tIG1vcmUgdGhhbiBvbmUgRFMgYXQgYSB0aW1lIHdhcyBzb21ldGhp bmcgdGhhdCB3YXMNCj4+IGRpc2N1c3NlZCB+MS41IHllYXJzIGFnbyB3aGVuIHdlIHdlcmUga2lj a2luZyBvZmYgdGhlIG9wc3RhdGUgZWZmb3J0Lg0KPj4gDQo+PiBUaGUgUFJPUyBhbmQgQ09OUyBh cmUgc2ltaWxhciwgYnV0IHRoZXJlIGFyZSBhZGRpdGlvbmFsIENPTlMgaW4gdGhlDQo+PiBnZW5l cmljIGNhc2UuICBUaGUgbWFpbiBvbmVzIGJlaW5nIDEpIGhvdyB0byBzaW11bHRhbmVvdXNseSBy ZXR1cm4gDQo+PiBib3RoIHRoZSBjb25maWcgYW5kIG9wc3RhdGUgdmFsdWVzIGZvciBhIG5vZGUg KHNwbGl0IGF0IHRoZSBsZWF2ZXMpDQo+PiBhbmQgMikgaG93IHRvIGhhbmRsZSBzb21lIFlBTkcg c3RhdGVtZW50cyBzdWNoIGFzIHByZXNlbmNlIGNvbnRhaW5lcnMNCj4+IGFuZCBjaG9pY2Ugbm9k ZXMuICBGb3IgdGhpcyByZWFzb24sICgyQikgaXMgTk9UIGNvbnNpZGVyZWQgYSB2aWFibGUNCj4+ IHNvbHV0aW9uIGFuZCBpcyBvbmx5IGhlcmUgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgaXQgd2Fz IGRpc2N1c3NlZC4NCj4+IA0KPj4gDQo+PiANCj4+IElmIHRoZXJlIGFyZSBhbnkgb3RoZXIgb3B0 aW9ucyBwZW9wbGUgd2FudCB0byBzdWdnZXN0LCBwbGVhc2UgZG8gc28NCj4+IG5vdyENCj4+IA0K Pj4gVGhhbmtzLA0KPj4gS2VudA0KPj4gDQoNCg0K From nobody Tue Feb 14 07:19:14 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2174E1295F4 for ; Tue, 14 Feb 2017 07:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, 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 MOuIDcB18wwU for ; Tue, 14 Feb 2017 07:19:11 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCFE1295A1 for ; Tue, 14 Feb 2017 07:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8579; q=dns/txt; s=iport; t=1487085550; x=1488295150; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=FTFfXGzepNEbZEvsGBkXzYYhvsGZvoDiNs+cFj9g/Ts=; b=GyRhVH17Qj1lVX6A6conex4T/RVsnt7gHbJI5BHil5OijbCJHn2D1klK 71/S4K+SLZFlL5Pu9aapgfPR7l6LIQmijzU9sFPQvhh2DNa7eexIcKyhU di1KdCZtz6elDmHjh+lrxmHg66JbG49H1mv9LAHa9oKW9ikmCqgjU2uD/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAQA8H6NY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDMDJ1+NYXKRHpU2ggwfC4V4AoI6GAECAQEBAQEBAWIohGkBAQE?= =?us-ascii?q?DAQEBNjYbCw4KLicwBgEMBgIBAReJSAgOsTqLXAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFhkyCBYJqhB0TBwEBBYV7BYkMhjeML4oPiAWBe4UXgy2GRosQiAUfOIE?= =?us-ascii?q?AIBQIFRU9hkNANQGHYwINFweCDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,161,1484006400"; d="scan'208";a="649637150" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2017 15:19:06 +0000 Received: from [10.63.23.109] (dhcp-ensft1-uk-vla370-10-63-23-109.cisco.com [10.63.23.109]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1EFJ5e1027952; Tue, 14 Feb 2017 15:19:06 GMT To: Kent Watsen , "i2rs@ietf.org" References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> From: Robert Wilton Message-ID: <1df4c6fa-c8f1-43c1-780a-3860b1ccb358@cisco.com> Date: Tue, 14 Feb 2017 15:19:02 +0000 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: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 15:19:13 -0000 Hi Kent, I think that the answer depends on when this module needs to be published: If it needs to be published now, then I think that it should follow the standard IETF config/state module conventions and use separate /foo and /foo-state trees. This should make the module most widely usable. Would it help if the model defined two "require-instance false" dependency leaf refs, one to the potential underlay node in the config tree, and a second to the potential underlay node in the state tree? Otherwise, if this model can be delayed until the revised datastores and I2RS work progresses then it could use a single combined config/state tree. It seems that the revised datastore solution would allow for a simpler model to be constructed to represent network topologies. Rob On 14/02/2017 13:55, Kent Watsen wrote: > > [moving yang-doctors to BCC] > > >>> OPTION 1: separate /foo and /foo-state trees >>> -------------------------------------------- >>> >>> This option was/is described here: >>> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. >>> >>> PROS: >>> a) does NOT break legacy clients (how we got here) >>> b) consistent with convention used in many IETF modules >>> c) able to show if/how opstate may differ from configured values >>> >>> CONS: >>> a) questionably valid YANG leafref usage >> What does this mean? > I'm referring to how the description statement explains that > the server may look to operational state in order to resolve > the leafref, which is to result in behavior similar to > pre-configuration in RFC 7223. > > > >>> b) complex server implementation (to handle require-instance false) >> Can you elaborate on this one? > This is primarily a reflection of the CON listed above, in that > it seems that a server would need to have special handling for > when dependencies transition from being present to not-present > and vice versa, much like the code to handle when a physical > card is plugged in or removed. > > Note: I should've listed this as a CON for OPTION 2 as well. > > > >>> c) eventually the module would need to migrate to the long-term >>> solution, which would result in needing to also rewrite all >>> modules that have augmented it (e.g., ietf-te-topology). >>> d) leafref path expressions really only work for configuration data, >>> though a clever server could have a special ability to peak at >>> the opstate values when doing validations. Of course, with >>> require-instance is false, the value of leafref based validation >>> checking is negated anyway, even for config true nodes, so this >>> may not matter much. >>> >>> >>> >>> OPTION 2: explicit client-option to also return tagged opstate data >>> ------------------------------------------------------------------- >>> >>> This option takes a couple forms. The first is module-specific and >>> the second is generic. In both cases, the idea is modeled after the >>> with-defaults solution (RFC6243), wherein the client passes a special >>> flag into causing the server to also return opstate data, >>> having a special metadata flag set, intermingled with the >>> configuration >>> data. >>> >>> >>> 2A: Module-specific version >>> >>> module foo { >>> import ietf-netconf { prefix nc; } >>> import ietf-yang-metadata { prefix md; } >>> md:annotation server-provided { >>> type boolean; >>> } >>> container nodes { >>> config true; >>> list node { >>> key "name"; >>> leaf name { type string; } >>> leaf dependency { >>> type leafref { >>> path "../node/name" >>> require-instance false; >>> } >>> } >>> } >>> } >>> augment /nc:get-config/nc:input { >>> leaf with-server-provided { >>> type boolean; >>> } >>> } >>> } >> I don't think this solution is substantially different from the >> solution in draft-ietf-i2rs-yang-network-topo-10. You have just moved >> a config false leaf to a meta-data annotation. This solution suffers >> from the same problems as the solution in >> draft-ietf-i2rs-yang-network-topo-10. > There are two primary differences: > > 1) It doesn't break legacy clients, because it requires the client to > explicitly pass a 'with-server-provided' flag in the > request in order to get back the extended response. Likewise, it > doesn't break backup/restore workflows, as the server can discard > any 'server-provided' nodes passed in an operation. > Lastly, it doesn't break /, as there is no comingling > of opstate data in the 'running' datastore. > > 2) It doesn't say anything about how the opstate data is stored on the > server. The opstate data is not modeled at all. This approach > only defines a presentation-layer format for how opstate data can > be returned via an RPC. The server is free to persist the opstate > data anyway it wants, perhaps in an internal datastore called > 'operational-state' or in an uber-datastore with the opstate data > flagged with a datastore='oper-state' attribute. Regardless, it's > an implementation detail, and the conceptual datastore model is > preserved. > > > >> /martin > Kent > > > > >>> For instance: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> overlay-node >>> underlay-node >>> >>> >>> underlay-node >>> >>> >>> >>> >>> PROS: >>> a) does NOT break legacy clients (how we got here) >>> b) having all data in one merged tree is simpler to process >>> than two separate queries. >>> c) module doesn't have to be rewritten for revised-datastores; >>> the 'with-server-provided' switch would just not be passed >>> by new opstate-aware clients. >>> >>> CONS: >>> a) inconsistent with convention used in many IETF modules >>> b) unclear how to model 'with-server-provided' for RESTCONF >>> (just use a description statement to define a query param?) >>> c) unable to return the opstate value for any configured node >>> (is it needed here?) >>> d) requires server to support metadata, which is a relatively >>> new concept and maybe not well supported by servers. >>> e) only changes presentation-layer (doesn't change the fact >>> that 'server-provided' data is not configuration), thus the >>> leafref path expressions still don't work quite the way as >>> desired, though a clever server could have a special ability >>> to peak at the opstate values when doing validations. Of >>> course, with require-instance is false, the value of leafref >>> based validation checking is negated anyway, even for config >>> true nodes, so this may not matter much. >>> >>> >>> >>> >>> 2B: Generic version >>> >>> The generic version is much the same, but rather than letting the >>> solution be limited to this one module, the idea is to generalize >>> it so it could be a server-level feature. Having a generic RPC to >>> return data from more than one DS at a time was something that was >>> discussed ~1.5 years ago when we were kicking off the opstate effort. >>> >>> The PROS and CONS are similar, but there are additional CONS in the >>> generic case. The main ones being 1) how to simultaneously return >>> both the config and opstate values for a node (split at the leaves) >>> and 2) how to handle some YANG statements such as presence containers >>> and choice nodes. For this reason, (2B) is NOT considered a viable >>> solution and is only here so that it's clear that it was discussed. >>> >>> >>> >>> If there are any other options people want to suggest, please do so >>> now! >>> >>> Thanks, >>> Kent >>> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > . > From nobody Tue Feb 14 08:41:11 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4ED1293DC for ; Tue, 14 Feb 2017 08:41: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, 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 AMLHh6tcnsPX for ; Tue, 14 Feb 2017 08:41: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 C48E5128E19 for ; Tue, 14 Feb 2017 08:41:07 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id CF46A1AE034F; Tue, 14 Feb 2017 17:41:06 +0100 (CET) Date: Tue, 14 Feb 2017 17:41:06 +0100 (CET) Message-Id: <20170214.174106.332845199336010868.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:41:10 -0000 Kent Watsen wrote: > > > [moving yang-doctors to BCC] > > > >> OPTION 1: separate /foo and /foo-state trees > >> -------------------------------------------- > >> > >> This option was/is described here: > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > >> > >> PROS: > >> a) does NOT break legacy clients (how we got here) > >> b) consistent with convention used in many IETF modules > >> c) able to show if/how opstate may differ from configured values > >> > >> CONS: > >> a) questionably valid YANG leafref usage > > > > What does this mean? > > I'm referring to how the description statement explains that > the server may look to operational state in order to resolve > the leafref, which is to result in behavior similar to > pre-configuration in RFC 7223. Ok, I didn't pay close attention to the proposal in the quoted email. I would design this a bit differently. The config true leaf "dependency" should have a leafref to the config false node name, with require-instance false. The description should explain that the configuration item will be used by the server if all dependencies exist. When the configuration item is used, it shows up in the config false list. This way, the leafref usage is valid and straight forward. > >> b) complex server implementation (to handle require-instance false) > > > >Can you elaborate on this one? > > This is primarily a reflection of the CON listed above, in that > it seems that a server would need to have special handling for > when dependencies transition from being present to not-present > and vice versa, much like the code to handle when a physical > card is plugged in or removed. Yes, but I think this is inherent to the problem at hand. Even with the config true solution defined in the current draft, it is not clear how things that were created by the server would be deleted (if there were references to them). > Note: I should've listed this as a CON for OPTION 2 as well. > > > > >> c) eventually the module would need to migrate to the long-term > >> solution, which would result in needing to also rewrite all > >> modules that have augmented it (e.g., ietf-te-topology). > >> d) leafref path expressions really only work for configuration data, > >> though a clever server could have a special ability to peak at > >> the opstate values when doing validations. Of course, with > >> require-instance is false, the value of leafref based validation > >> checking is negated anyway, even for config true nodes, so this > >> may not matter much. > >> > >> > >> > >> OPTION 2: explicit client-option to also return tagged opstate data > >> ------------------------------------------------------------------- > >> > >> This option takes a couple forms. The first is module-specific and > >> the second is generic. In both cases, the idea is modeled after the > >> with-defaults solution (RFC6243), wherein the client passes a special > >> flag into causing the server to also return opstate data, > >> having a special metadata flag set, intermingled with the > >> configuration > >> data. > >> > >> > >> 2A: Module-specific version > >> > >> module foo { > >> import ietf-netconf { prefix nc; } > >> import ietf-yang-metadata { prefix md; } > >> md:annotation server-provided { > >> type boolean; > >> } > >> container nodes { > >> config true; > >> list node { > >> key "name"; > >> leaf name { type string; } > >> leaf dependency { > >> type leafref { > >> path "../node/name" > >> require-instance false; > >> } > >> } > >> } > >> } > >> augment /nc:get-config/nc:input { > >> leaf with-server-provided { > >> type boolean; > >> } > >> } > >> } > > > > I don't think this solution is substantially different from the > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just moved > > a config false leaf to a meta-data annotation. This solution suffers > > from the same problems as the solution in > > draft-ietf-i2rs-yang-network-topo-10. > > There are two primary differences: > > 1) It doesn't break legacy clients The solution in the draft doesn't break legacy clients either - there's a config false leaf among the config true. No problem. > , because it requires the client to > explicitly pass a 'with-server-provided' flag in the > request in order to get back the extended response. Likewise, it > doesn't break backup/restore workflows, as the server can discard > any 'server-provided' nodes passed in an operation. Huh? This goes against the defined behavior of 6241 + 7950. This is the main problem with the solution in the current draft. If a client sends a for data in running, the server cannot send back data that is not in running. > Lastly, it doesn't break /, as there is no comingling > of opstate data in the 'running' datastore. > > 2) It doesn't say anything about how the opstate data is stored on the > server. The opstate data is not modeled at all. This approach > only defines a presentation-layer format for how opstate data can > be returned via an RPC. The server is free to persist the opstate > data anyway it wants, perhaps in an internal datastore called > 'operational-state' or in an uber-datastore with the opstate data > flagged with a datastore='oper-state' attribute. Regardless, it's > an implementation detail, and the conceptual datastore model is > preserved. You are essentially defining a new operation, but do it by modifying the semantics of an existing one. I don't think this is a good idea; it is better to define a new rpc. /martin From nobody Tue Feb 14 17:57:00 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2107712944A for ; Tue, 14 Feb 2017 17:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0dm6rDmGLVJ2 for ; Tue, 14 Feb 2017 17:56: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 7015C129486 for ; Tue, 14 Feb 2017 17:56:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGM62826; Wed, 15 Feb 2017 01:56:53 +0000 (GMT) Received: from LHREML709-CAH.china.huawei.com (10.201.108.32) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 01:56:53 +0000 Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 01:56:52 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Tue, 14 Feb 2017 17:56:50 -0800 From: Alexander Clemm To: Martin Bjorklund , "kwatsen@juniper.net" Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFo3scAgAAukoCAAC4rAIAACldw Date: Wed, 15 Feb 2017 01:56:48 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> In-Reply-To: <20170214.174106.332845199336010868.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58A3B566.014E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 421a5ff6348e06f086431402a07a4120 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 01:57:00 -0000 Hi,=20 One comment inline re: option 1, Thanks --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Tuesday, February 14, 2017 8:41 AM To: kwatsen@juniper.net Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Kent Watsen wrote: >=20 >=20 > [moving yang-doctors to BCC] >=20 >=20 > >> OPTION 1: separate /foo and /foo-state trees > >> -------------------------------------------- > >>=20 > >> This option was/is described here: > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > >>=20 > >> PROS: > >> a) does NOT break legacy clients (how we got here) > >> b) consistent with convention used in many IETF modules > >> c) able to show if/how opstate may differ from configured values > >>=20 > >> CONS: > >> a) questionably valid YANG leafref usage > > > > What does this mean? >=20 > I'm referring to how the description statement explains that the=20 > server may look to operational state in order to resolve the leafref,=20 > which is to result in behavior similar to pre-configuration in RFC=20 > 7223. Ok, I didn't pay close attention to the proposal in the quoted email. I would design this a bit differently. The config true leaf "dependency" s= hould have a leafref to the config false node name, with require-instance f= alse. The description should explain that the configuration item will be u= sed by the server if all dependencies exist. When the configuration item i= s used, it shows up in the config false list. This way, the leafref usage is valid and straight forward. =20 Hi Martin, =20 I don't understand one statement you are making "When the configuration ite= m is used, it shows up in the config false list" - can you please elaborate= ?=20 One of the issues that we are facing is that a configured topology might re= fer to a configured topology or a server-provided topology, and we would li= ke to avoid making a case distinction as to which category we are referring= to. =20 At the same time, we are making use of leafrefs to express a number of inte= grity constraints which are part of the model: as a node is part of a topo= logy, and a topology has an underlay topology, we make sure that the underl= ay node is part of the underlay topology (and not just any arbitrary node).= Likewise for termination points and links (with some additional constrain= ts, such as a TP's supporting TP be contained in the TP's containing node's= supporting node, with supporting links of a link being terminated by suppo= rting TPs of the link's TP, etc) It would be really nice to capture these = without resorting to description statements, and without overly complex pat= h expressions (particularly as leafrefs refer to a single path, not a choic= e of alternative paths)=20 What you describe above does not seem to address this entirely. You descri= be having a leafref to a config false node. We need to have a leafref that= can effectively be pointed at a config false, or a config true node. How = can we achieve that when both nodes are in separate subtrees? We could consider a solution in which we have two dependencies - one leafre= f to point to config false, another leafref to point to config true. But t= his solution seems a bit awkward, as it requires different handling by appl= ications of each case. Perhaps use a union of two leafrefs with different = paths. This might be a solution, but the question regarding how to capture= the overlay/underlay layering constraints remains. =20 --- Alex > >> b) complex server implementation (to handle require-instance=20 > >> false) > > > >Can you elaborate on this one? >=20 > This is primarily a reflection of the CON listed above, in that it=20 > seems that a server would need to have special handling for when=20 > dependencies transition from being present to not-present and vice=20 > versa, much like the code to handle when a physical card is plugged in=20 > or removed. Yes, but I think this is inherent to the problem at hand. Even with the co= nfig true solution defined in the current draft, it is not clear how things= that were created by the server would be deleted (if there were references= to them). > Note: I should've listed this as a CON for OPTION 2 as well. >=20 >=20 >=20 > >> c) eventually the module would need to migrate to the long-term=20 > >> solution, which would result in needing to also rewrite all > >> modules that have augmented it (e.g., ietf-te-topology). > >> d) leafref path expressions really only work for configuration data, > >> though a clever server could have a special ability to peak at > >> the opstate values when doing validations. Of course, with=20 > >> require-instance is false, the value of leafref based validation > >> checking is negated anyway, even for config true nodes, so this > >> may not matter much. > >>=20 > >>=20 > >>=20 > >> OPTION 2: explicit client-option to also return tagged opstate data > >> ------------------------------------------------------------------- > >>=20 > >> This option takes a couple forms. The first is module-specific and=20 > >> the second is generic. In both cases, the idea is modeled after=20 > >> the with-defaults solution (RFC6243), wherein the client passes a=20 > >> special flag into causing the server to also return=20 > >> opstate data, having a special metadata flag set, intermingled with=20 > >> the configuration data. > >>=20 > >>=20 > >> 2A: Module-specific version > >>=20 > >> module foo { > >> import ietf-netconf { prefix nc; } > >> import ietf-yang-metadata { prefix md; } > >> md:annotation server-provided { > >> type boolean; > >> } > >> container nodes { > >> config true; > >> list node { > >> key "name"; > >> leaf name { type string; } > >> leaf dependency { > >> type leafref { > >> path "../node/name" > >> require-instance false; > >> } > >> } > >> } > >> } > >> augment /nc:get-config/nc:input { > >> leaf with-server-provided { > >> type boolean; > >> } > >> } > >> } > > > > I don't think this solution is substantially different from the=20 > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just=20 > > moved a config false leaf to a meta-data annotation. This solution=20 > > suffers from the same problems as the solution in=20 > > draft-ietf-i2rs-yang-network-topo-10. >=20 > There are two primary differences: >=20 > 1) It doesn't break legacy clients The solution in the draft doesn't break legacy clients either - there's a c= onfig false leaf among the config true. No problem. > , because it requires the client to > explicitly pass a 'with-server-provided' flag in the > request in order to get back the extended response. Likewise, it > doesn't break backup/restore workflows, as the server can discard > any 'server-provided' nodes passed in an operation. Huh? This goes against the defined behavior of 6241 + 7950. This is the m= ain problem with the solution in the current draft. If a client sends a for data in running, the server cannot sen= d back data that is not in running. > Lastly, it doesn't break /, as there is no comingling > of opstate data in the 'running' datastore. >=20 > 2) It doesn't say anything about how the opstate data is stored on the > server. The opstate data is not modeled at all. This approach=20 > only defines a presentation-layer format for how opstate data can > be returned via an RPC. The server is free to persist the opstate > data anyway it wants, perhaps in an internal datastore called=20 > 'operational-state' or in an uber-datastore with the opstate data > flagged with a datastore=3D'oper-state' attribute. Regardless, it's > an implementation detail, and the conceptual datastore model is > preserved. You are essentially defining a new operation, but do it by modifying the se= mantics of an existing one. I don't think this is a good idea; it is bette= r to define a new rpc. /martin _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Feb 15 00:12:26 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4722E1294E5 for ; Wed, 15 Feb 2017 00:12:23 -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 xY9hIXf6s2Y8 for ; Wed, 15 Feb 2017 00:12:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DBDD3128AC9 for ; Wed, 15 Feb 2017 00:12:20 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 91D281AE0332; Wed, 15 Feb 2017 09:12:19 +0100 (CET) Date: Wed, 15 Feb 2017 09:12:19 +0100 (CET) Message-Id: <20170215.091219.721914825568257957.mbj@tail-f.com> To: alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> References: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 08:12:25 -0000 Hi, Alexander Clemm wrote: > Hi, > > One comment inline re: option 1, > > Thanks > --- Alex > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > Bjorklund > Sent: Tuesday, February 14, 2017 8:41 AM > To: kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > Kent Watsen wrote: > > > > > > [moving yang-doctors to BCC] > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > >> -------------------------------------------- > > >> > > >> This option was/is described here: > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > >> > > >> PROS: > > >> a) does NOT break legacy clients (how we got here) > > >> b) consistent with convention used in many IETF modules > > >> c) able to show if/how opstate may differ from configured values > > >> > > >> CONS: > > >> a) questionably valid YANG leafref usage > > > > > > What does this mean? > > > > I'm referring to how the description statement explains that the > > server may look to operational state in order to resolve the leafref, > > which is to result in behavior similar to pre-configuration in RFC > > 7223. > > Ok, I didn't pay close attention to the proposal in the quoted email. > > I would design this a bit differently. The config true leaf > "dependency" should have a leafref to the config false node name, with > require-instance false. The description should explain that the > configuration item will be used by the server if all dependencies > exist. When the configuration item is used, it shows up in the config > false list. > > This way, the leafref usage is valid and straight forward. > > > Hi Martin, > > I don't understand one statement you are making "When the > configuration item is used, it shows up in the config false list" - > can you please elaborate? I mean that the server will consider a configured item, and decide if it can be used or not. If the configured item has a reference to something that doesn't (yet) exist (weak reference; require-instance false), the server leaves the item in the config, and moves on. At some later time, suppose the weak reference is fulfilled; at this point the server decides that the configured item can be used, and it instantiates the item in the /-state list. Once it is there, maybe some other configured item has a reference to this one, and it can also be instantiated etc. And it goes the other way as well; suppose a server provided item is removed by the server; at this point the server would also remove items in the state list that originated in the configuration - however they are not removed from the config, just the state. (Server provided items would only show up in the state in this solution). The state subtree works exactly like the operational-state datastore in draft-ietf-netmod-revised-datastores. > One of the issues that we are facing is that a configured topology > might refer to a configured topology or a server-provided topology, > and we would like to avoid making a case distinction as to which > category we are referring to. I believe my proposed solution handles this. > At the same time, we are making use of leafrefs to express a number of > integrity constraints which are part of the model: as a node is part > of a topology, and a topology has an underlay topology, we make sure > that the underlay node is part of the underlay topology (and not just > any arbitrary node). Can you point me to the place in the model where this is specified? Or did you mean that today you have to mention this in plain text, but it would be nice if it could be captured formally in the model? > Likewise for termination points and links (with > some additional constraints, such as a TP's supporting TP be contained > in the TP's containing node's supporting node, with supporting links > of a link being terminated by supporting TPs of the link's TP, etc) It > would be really nice to capture these without resorting to description > statements, and without overly complex path expressions (particularly > as leafrefs refer to a single path, not a choice of alternative paths) > > What you describe above does not seem to address this entirely. You > describe having a leafref to a config false node. We need to have a > leafref that can effectively be pointed at a config false, or a config > true node. How can we achieve that when both nodes are in separate > subtrees? > > We could consider a solution in which we have two dependencies - one > leafref to point to config false, another leafref to point to config > true. But this solution seems a bit awkward, as it requires different > handling by applications of each case. Perhaps use a union of two > leafrefs with different paths. This might be a solution, but the > question regarding how to capture the overlay/underlay layering > constraints remains. /martin > > --- Alex > > > > > >> b) complex server implementation (to handle require-instance > > >> false) > > > > > >Can you elaborate on this one? > > > > This is primarily a reflection of the CON listed above, in that it > > seems that a server would need to have special handling for when > > dependencies transition from being present to not-present and vice > > versa, much like the code to handle when a physical card is plugged in > > or removed. > > Yes, but I think this is inherent to the problem at hand. Even with > the config true solution defined in the current draft, it is not clear > how things that were created by the server would be deleted (if there > were references to them). > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > >> solution, which would result in needing to also rewrite all > > >> modules that have augmented it (e.g., ietf-te-topology). > > >> d) leafref path expressions really only work for configuration data, > > >> though a clever server could have a special ability to peak at > > >> the opstate values when doing validations. Of course, with > > >> require-instance is false, the value of leafref based validation > > >> checking is negated anyway, even for config true nodes, so this > > >> may not matter much. > > >> > > >> > > >> > > >> OPTION 2: explicit client-option to also return tagged opstate data > > >> ------------------------------------------------------------------- > > >> > > >> This option takes a couple forms. The first is module-specific and > > >> the second is generic. In both cases, the idea is modeled after > > >> the with-defaults solution (RFC6243), wherein the client passes a > > >> special flag into causing the server to also return > > >> opstate data, having a special metadata flag set, intermingled with > > >> the configuration data. > > >> > > >> > > >> 2A: Module-specific version > > >> > > >> module foo { > > >> import ietf-netconf { prefix nc; } > > >> import ietf-yang-metadata { prefix md; } > > >> md:annotation server-provided { > > >> type boolean; > > >> } > > >> container nodes { > > >> config true; > > >> list node { > > >> key "name"; > > >> leaf name { type string; } > > >> leaf dependency { > > >> type leafref { > > >> path "../node/name" > > >> require-instance false; > > >> } > > >> } > > >> } > > >> } > > >> augment /nc:get-config/nc:input { > > >> leaf with-server-provided { > > >> type boolean; > > >> } > > >> } > > >> } > > > > > > I don't think this solution is substantially different from the > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > moved a config false leaf to a meta-data annotation. This solution > > > suffers from the same problems as the solution in > > > draft-ietf-i2rs-yang-network-topo-10. > > > > There are two primary differences: > > > > 1) It doesn't break legacy clients > > The solution in the draft doesn't break legacy clients either - > there's a config false leaf among the config true. No problem. > > > , because it requires the client to > > explicitly pass a 'with-server-provided' flag in the > > request in order to get back the extended response. Likewise, it > > doesn't break backup/restore workflows, as the server can discard > > any 'server-provided' nodes passed in an operation. > > Huh? This goes against the defined behavior of 6241 + 7950. This is > the main problem with the solution in the current draft. > > If a client sends a for data in running, the server > cannot send back data that is not in running. > > > Lastly, it doesn't break /, as there is no comingling > > of opstate data in the 'running' datastore. > > > > 2) It doesn't say anything about how the opstate data is stored on the > > server. The opstate data is not modeled at all. This approach > > only defines a presentation-layer format for how opstate data can > > be returned via an RPC. The server is free to persist the opstate > > data anyway it wants, perhaps in an internal datastore called > > 'operational-state' or in an uber-datastore with the opstate data > > flagged with a datastore='oper-state' attribute. Regardless, it's > > an implementation detail, and the conceptual datastore model is > > preserved. > > You are essentially defining a new operation, but do it by modifying > the semantics of an existing one. I don't think this is a good idea; > it is better to define a new rpc. > > > /martin > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Feb 15 10:24:52 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D742A129B13 for ; Wed, 15 Feb 2017 10:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 iifAFZmSjkK5 for ; Wed, 15 Feb 2017 10:24:48 -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 9D294129ACB for ; Wed, 15 Feb 2017 10:24:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGO02893; Wed, 15 Feb 2017 18:24:45 +0000 (GMT) Received: from LHREML712-CAH.china.huawei.com (10.201.108.35) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 18:24:37 +0000 Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 18:24:36 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Wed, 15 Feb 2017 10:24:31 -0800 From: Alexander Clemm To: Martin Bjorklund Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFo3scAgAAukoCAAC4rAIAACldwgAD514CAACAzkA== Date: Wed, 15 Feb 2017 18:24:30 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> References: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> <20170215.091219.721914825568257957.mbj@tail-f.com> In-Reply-To: <20170215.091219.721914825568257957.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58A49CED.029C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 421a5ff6348e06f086431402a07a4120 Archived-At: Cc: "i2rs@ietf.org" , "kwatsen@juniper.net" Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:24:51 -0000 Hello Martin, =20 Thank you. Your first explanation is clear. Regarding the expression of c= onstraints, see inline, below (thread is pruned for clarity) --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Wednesday, February 15, 2017 12:12 AM To: Alexander Clemm Cc: kwatsen@juniper.net; i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo ................. I mean that the server will consider a configured item, and decide if it ca= n be used or not. If the configured item has a reference to something that= doesn't (yet) exist (weak reference; require-instance false), the server l= eaves the item in the config, and moves on. At some later time, suppose th= e weak reference is fulfilled; at this point the server decides that the co= nfigured item can be used, and it instantiates the item in the /-state list= . Once it is there, maybe some other configured item has a reference to th= is one, and it can also be instantiated etc. And it goes the other way as well; suppose a server provided item is remove= d by the server; at this point the server would also remove items in the st= ate list that originated in the configuration - however they are not remove= d from the config, just the state. (Server provided items would only show up in the state in this solution). The state subtree works exactly like the operational-state datastore in dra= ft-ietf-netmod-revised-datastores. Thank you, this clarifies the earlier statement > One of the issues that we are facing is that a configured topology=20 > might refer to a configured topology or a server-provided topology,=20 > and we would like to avoid making a case distinction as to which=20 > category we are referring to. I believe my proposed solution handles this. > At the same time, we are making use of leafrefs to express a number of=20 > integrity constraints which are part of the model: as a node is part=20 > of a topology, and a topology has an underlay topology, we make sure=20 > that the underlay node is part of the underlay topology (and not just=20 > any arbitrary node). Can you point me to the place in the model where this is specified? Or did you mean that today you have to mention this in plain text, but it w= ould be nice if it could be captured formally in the model? It is covered in the model today. E.g.: In networks/network/node/supporting-node=20 leaf network-ref { type leafref { path "../../../supporting-network/network-ref"; require-instance false; } (supporting node is contained in supporting network) Supporting link: +--rw supporting-link* [network-ref link-ref] +--rw network-ref -> ../../../nd:supporting-network/network-ref +--rw link-ref -> /nd:networks/network[nd:network-id=3Dcurre= nt()/../network-ref]/link/link-id (supporting link is a link contained in the supporting network) Supporting termination point: +--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw network-ref -> ../../../nd:supporting-node/network-ref +--rw node-ref -> ../../../nd:supporting-node/node-ref +--rw tp-ref -> /nd:networks/network[nd:network-id=3Dcurre= nt()/../network-ref]/node[nd:node-id=3Dcurrent()/../node-ref]/termination-p= oint/tp-id (supporting termination point is contained in supporting network and suppor= ting node) It is those leafrefs whose transposition in the split subtree model (where = we encounter alternative paths) I am concerned will be problematic. =20 =20 From nobody Wed Feb 15 10:41:32 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B91129B09 for ; Wed, 15 Feb 2017 10:41:30 -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 ZmpU5aOGXPev for ; Wed, 15 Feb 2017 10:41:29 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C2ACF129A97 for ; Wed, 15 Feb 2017 10:41:28 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 5D8A01AE0398; Wed, 15 Feb 2017 19:41:26 +0100 (CET) Date: Wed, 15 Feb 2017 19:41:26 +0100 (CET) Message-Id: <20170215.194126.118198588680956999.mbj@tail-f.com> To: alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> <20170215.091219.721914825568257957.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:41:31 -0000 Alexander Clemm wrote: > Hello Martin, > Thank you. Your first explanation is clear. Regarding the expression > of constraints, see inline, below (thread is pruned for clarity) > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, February 15, 2017 12:12 AM > To: Alexander Clemm > Cc: kwatsen@juniper.net; i2rs@ietf.org > Subject: Re: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > > > ................. > I mean that the server will consider a configured item, and decide if > it can be used or not. If the configured item has a reference to > something that doesn't (yet) exist (weak reference; require-instance > false), the server leaves the item in the config, and moves on. At > some later time, suppose the weak reference is fulfilled; at this > point the server decides that the configured item can be used, and it > instantiates the item in the /-state list. Once it is there, maybe > some other configured item has a reference to this one, and it can > also be instantiated etc. > > And it goes the other way as well; suppose a server provided item is > removed by the server; at this point the server would also remove > items in the state list that originated in the configuration - however > they are not removed from the config, just the state. > (Server provided items would only show up in the state in this > solution). > > The state subtree works exactly like the operational-state datastore > in draft-ietf-netmod-revised-datastores. > > > Thank you, this clarifies the earlier statement > > > > One of the issues that we are facing is that a configured topology > > might refer to a configured topology or a server-provided topology, > > and we would like to avoid making a case distinction as to which > > category we are referring to. > > I believe my proposed solution handles this. > > > At the same time, we are making use of leafrefs to express a number of > > integrity constraints which are part of the model: as a node is part > > of a topology, and a topology has an underlay topology, we make sure > > that the underlay node is part of the underlay topology (and not just > > any arbitrary node). > > Can you point me to the place in the model where this is specified? > > Or did you mean that today you have to mention this in plain text, but > it would be nice if it could be captured formally in the model? > > It is covered in the model today. E.g.: Ok. Here the model uses require-instance false, so if these ponts to the state tree instead, you'd get the same effect. /martin > > In networks/network/node/supporting-node > leaf network-ref { > type leafref { > path "../../../supporting-network/network-ref"; > require-instance false; > } > (supporting node is contained in supporting network) > > Supporting link: > +--rw supporting-link* [network-ref link-ref] > +--rw network-ref -> ../../../nd:supporting-network/network-ref > +--rw link-ref -> > /nd:networks/network[nd:network-id=current()/../network-ref]/link/link-id > > (supporting link is a link contained in the supporting network) > > Supporting termination point: > +--rw supporting-termination-point* [network-ref node-ref tp-ref] > +--rw network-ref -> ../../../nd:supporting-node/network-ref > +--rw node-ref -> ../../../nd:supporting-node/node-ref > +--rw tp-ref -> > /nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:node-id=current()/../node-ref]/termination-point/tp-id > > (supporting termination point is contained in supporting network and > supporting node) > > It is those leafrefs whose transposition in the split subtree model > (where we encounter alternative paths) I am concerned will be > problematic. > > > > From nobody Wed Feb 15 11:14:11 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6D61296FB for ; Wed, 15 Feb 2017 11:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Hwp8ikw1GqKJ for ; Wed, 15 Feb 2017 11:14:08 -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 75D80126DFB for ; Wed, 15 Feb 2017 11:14:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAR56570; Wed, 15 Feb 2017 19:14:05 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 15 Feb 2017 19:14:01 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Wed, 15 Feb 2017 11:13:57 -0800 From: Alexander Clemm To: Martin Bjorklund Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFo3scAgAAukoCAAC4rAIAACldwgAD514CAACAzkIAAj5MA//98/oA= Date: Wed, 15 Feb 2017 19:13:56 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF804DE@SJCEML703-CHM.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> <20170215.091219.721914825568257957.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> <20170215.194126.118198588680956999.mbj@tail-f.com> In-Reply-To: <20170215.194126.118198588680956999.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58A4A87D.03B8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 54197619c840e95cd3e30388045b4986 Archived-At: Cc: "i2rs@ietf.org" , "kwatsen@juniper.net" Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:14:10 -0000 So, the suggested solution would be to not have validation of information, = but simply have misconfigured stuff that violates integrity constraints nev= er show up in the state tree. =20 Perhaps this is the best that YANG can support today, although I still find= this not very satisfying. At a minimum, it would be good if the framework= would support an indication whether the configured topology information we= nt into effect or not. The implication is that a client will need to achie= ve this now by retrieving the corresponding state tree after each configura= tion operation (and if the configuration would not show correspondingly in = the state tree, troubleshoot to see what's wrong). So, if this is taken a= s design pattern, it would be good to introduce operations to support that.= Likewise, it would be good to have a "diffing" operation in which state t= ree and configuration tree are checked for differences and discrepancies ar= e reported (e.g. config not in state, and possibly vice versa). These shou= ld probably be added as requirements for I2Rs and the next revision of the = overall YANG+associated protocols framework. =20 --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Wednesday, February 15, 2017 10:41 AM To: Alexander Clemm Cc: kwatsen@juniper.net; i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Alexander Clemm wrote: > Hello Martin, > Thank you. Your first explanation is clear. Regarding the expression=20 > of constraints, see inline, below (thread is pruned for clarity) > --- Alex >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, February 15, 2017 12:12 AM > To: Alexander Clemm > Cc: kwatsen@juniper.net; i2rs@ietf.org > Subject: Re: [i2rs] modeling options for=20 > draft-ietf-i2rs-yang-network-topo >=20 >=20 > > ................. > I mean that the server will consider a configured item, and decide if=20 > it can be used or not. If the configured item has a reference to=20 > something that doesn't (yet) exist (weak reference; require-instance=20 > false), the server leaves the item in the config, and moves on. At=20 > some later time, suppose the weak reference is fulfilled; at this=20 > point the server decides that the configured item can be used, and it=20 > instantiates the item in the /-state list. Once it is there, maybe=20 > some other configured item has a reference to this one, and it can=20 > also be instantiated etc. >=20 > And it goes the other way as well; suppose a server provided item is=20 > removed by the server; at this point the server would also remove=20 > items in the state list that originated in the configuration - however=20 > they are not removed from the config, just the state. > (Server provided items would only show up in the state in this=20 > solution). >=20 > The state subtree works exactly like the operational-state datastore=20 > in draft-ietf-netmod-revised-datastores. >=20 > > Thank you, this clarifies the earlier statement >=20 > > One of the issues that we are facing is that a configured topology=20 > > might refer to a configured topology or a server-provided topology,=20 > > and we would like to avoid making a case distinction as to which=20 > > category we are referring to. >=20 > I believe my proposed solution handles this. >=20 > > At the same time, we are making use of leafrefs to express a number=20 > > of integrity constraints which are part of the model: as a node is=20 > > part of a topology, and a topology has an underlay topology, we make=20 > > sure that the underlay node is part of the underlay topology (and=20 > > not just any arbitrary node). >=20 > Can you point me to the place in the model where this is specified? >=20 > Or did you mean that today you have to mention this in plain text, but=20 > it would be nice if it could be captured formally in the model? >=20 > It is covered in the model today. E.g.: Ok. Here the model uses require-instance false, so if these ponts to the s= tate tree instead, you'd get the same effect. /martin >=20 > In networks/network/node/supporting-node=20 > leaf network-ref { > type leafref { > path "../../../supporting-network/network-ref"; > require-instance false; > } > (supporting node is contained in supporting network) >=20 > Supporting link: > +--rw supporting-link* [network-ref link-ref] > +--rw network-ref -> ../../../nd:supporting-network/network-r= ef > +--rw link-ref -> > =20 > /nd:networks/network[nd:network-id=3Dcurrent()/../network-ref]/link/link > -id >=20 > (supporting link is a link contained in the supporting network) >=20 > Supporting termination point: > +--rw supporting-termination-point* [network-ref node-ref tp-ref] > +--rw network-ref -> ../../../nd:supporting-node/network-ref > +--rw node-ref -> ../../../nd:supporting-node/node-ref > +--rw tp-ref -> > =20 > /nd:networks/network[nd:network-id=3Dcurrent()/../network-ref]/node[nd:n > ode-id=3Dcurrent()/../node-ref]/termination-point/tp-id >=20 > (supporting termination point is contained in supporting network and=20 > supporting node) >=20 > It is those leafrefs whose transposition in the split subtree model=20 > (where we encounter alternative paths) I am concerned will be=20 > problematic. >=20 > > =20 >=20 From nobody Wed Feb 15 11:27:41 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E301299FE for ; Wed, 15 Feb 2017 11:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2TnFgiemCYy for ; Wed, 15 Feb 2017 11:27:39 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0114.outbound.protection.outlook.com [104.47.40.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F7D129A00 for ; Wed, 15 Feb 2017 11:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pbUEHpWOVL189CsimyGr/06pa864p/MmExIh8O/M1MY=; b=ZOBG+JYqGePCEjclAs5TCFs2MlDB1UqEAdMy4M+2P0qvVnJwkw/h8o4Z5kLG9HaaJMXvsyBYsSlvvlntGAtsVAN4YjMUWvpRHYhQkY8+CVc8DxEDAS4LpH4aAgvxHOW1kXhbEnNXCoiIXjvNz+WH2Aw2eEKKPqNkmA52LG7BVbA= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Wed, 15 Feb 2017 19:27:32 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.013; Wed, 15 Feb 2017 19:27:32 +0000 From: Kent Watsen To: Alexander Clemm , Martin Bjorklund Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFoWKoA///awYCAAIH9AIAAm0MAgABo64CAAKsLAIAABLsAgAAJFAD//6/6gA== Date: Wed, 15 Feb 2017 19:27:32 +0000 Message-ID: <36186505-9F9E-49EA-B033-D4AFDFD66661@juniper.net> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> <20170215.091219.721914825568257957.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> <20170215.194126.118198588680956999.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF804DE@SJCEML703-CHM.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF804DE@SJCEML703-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 07f11400-8fb1-4e4f-0de5-08d455d8b024 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:xj0Rdn8FW4Bhj1AJfC9COd6RlCMY46/ZvFDqM4hp5yT8EuUsDtQ7tnERdC1q0q+RznFVvJYk+nQOyv8JqLRFPagVOfwDOKvpKmXA74LNfVmhRVXx9Lh1zYPtCQdzw69CqWFvCQNWjMdSh8uQ2qrnV50Ehd3dIFAV9vGvvnVieb+ckExM/OQDRsZWXVlKDZuNYqjkrMInmGic585w2w7PZyPUNEit8QR4JNTm1jAmElPkAYYCeoXZdchuZAOdX/T0Qdxa42QdLzW/VDLG8AydjT1MD6UIaO9DDsZkM+a6LQG4xwmJeFj35lmYNHV1/6MTmrfbGd2DJjukEjnrv4XzzA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39840400002)(39850400002)(39410400002)(189002)(199003)(81156014)(8676002)(38730400002)(68736007)(101416001)(92566002)(105586002)(106356001)(106116001)(2900100001)(36756003)(6246003)(86362001)(53936002)(54356999)(76176999)(93886004)(230783001)(102836003)(50986999)(3846002)(81166006)(6116002)(389900002)(7736002)(305945005)(5660300001)(77096006)(2950100002)(82746002)(229853002)(122556002)(4001350100001)(6486002)(83506001)(4326007)(83716003)(2906002)(6512007)(97736004)(189998001)(33656002)(25786008)(6506006)(66066001)(99286003)(3660700001)(3280700002)(8936002)(6436002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3F56BD87D0AA014A8A364B66A601E28D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 19:27:32.1791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:27:40 -0000 DQo+IFNvLCB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9uIHdvdWxkIGJlIHRvIG5vdCBoYXZlIHZhbGlk YXRpb24NCj4gb2YgaW5mb3JtYXRpb24sIGJ1dCBzaW1wbHkgaGF2ZSBtaXNjb25maWd1cmVkIHN0 dWZmIHRoYXQNCj4gdmlvbGF0ZXMgaW50ZWdyaXR5IGNvbnN0cmFpbnRzIG5ldmVyIHNob3cgdXAg aW4gdGhlIHN0YXRlIHRyZWUuICANCg0KQSBsZWFmcmVmIHdpdGggcmVxdWlyZS1pbnN0YW5jZSBm YWxzZSwgZXZlbiBpZiBwb2ludGluZyB0byBhIHBhdGgNCmluIHRoZSBjb25maWd1cmF0aW9uLCBl ZmZlY3RpdmVseSBkaXNhYmxlcyB2YWxpZGF0aW9uLiAgU3RpbGwsIEkNCnRoaW5rIGEgbGVhZnJl ZiBpcyBiZXR0ZXIgdGhhbiBqdXN0IGEgZGVzY3JpcHRpb24gc3RhdGVtZW50Lg0KDQo+IFBlcmhh cHMgdGhpcyBpcyB0aGUgYmVzdCB0aGF0IFlBTkcgY2FuIHN1cHBvcnQgdG9kYXksIGFsdGhvdWdo DQo+IEkgc3RpbGwgZmluZCB0aGlzIG5vdCB2ZXJ5IHNhdGlzZnlpbmcuICBBdCBhIG1pbmltdW0s IGl0IHdvdWxkDQo+IGJlIGdvb2QgaWYgdGhlIGZyYW1ld29yayB3b3VsZCBzdXBwb3J0IGFuIGlu ZGljYXRpb24gd2hldGhlcg0KPiB0aGUgY29uZmlndXJlZCB0b3BvbG9neSBpbmZvcm1hdGlvbiB3 ZW50IGludG8gZWZmZWN0IG9yIG5vdC4NCg0KVGhlIHJldmlzZWQtZGF0YXN0b3JlIHNvbHV0aW9u IGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYSB3YXkgdG8NCnNob3cgdGhpcy4gIFNlZSBkcmFmdC1p ZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMuDQoNCj4gVGhlIGltcGxpY2F0aW9uIGlzIHRoYXQgYSBj bGllbnQgd2lsbCBuZWVkIHRvIGFjaGlldmUgdGhpcyBub3cNCj4gYnkgcmV0cmlldmluZyB0aGUg Y29ycmVzcG9uZGluZyBzdGF0ZSB0cmVlIGFmdGVyIGVhY2gNCj4gY29uZmlndXJhdGlvbiBvcGVy YXRpb24gKGFuZCBpZiB0aGUgY29uZmlndXJhdGlvbiB3b3VsZCBub3QNCj4gc2hvdyBjb3JyZXNw b25kaW5nbHkgaW4gdGhlIHN0YXRlIHRyZWUsIHRyb3VibGVzaG9vdCB0byBzZWUNCj4gd2hhdCdz IHdyb25nKS4gICBTbywgaWYgdGhpcyBpcyB0YWtlbiBhcyBkZXNpZ24gcGF0dGVybiwgaXQNCj4g d291bGQgYmUgZ29vZCB0byBpbnRyb2R1Y2Ugb3BlcmF0aW9ucyB0byBzdXBwb3J0IHRoYXQuDQoN ClNlZSBkcmFmdC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMuDQoNCj4gTGlrZXdpc2UsIGl0IHdv dWxkIGJlIGdvb2QgdG8gaGF2ZSBhICJkaWZmaW5nIiBvcGVyYXRpb24gDQo+IGluIHdoaWNoIHN0 YXRlIHRyZWUgYW5kIGNvbmZpZ3VyYXRpb24gdHJlZSBhcmUgY2hlY2tlZCBmb3INCj4gZGlmZmVy ZW5jZXMgYW5kIGRpc2NyZXBhbmNpZXMgYXJlIHJlcG9ydGVkIChlLmcuIGNvbmZpZyBub3QNCj4g aW4gc3RhdGUsIGFuZCBwb3NzaWJseSB2aWNlIHZlcnNhKS4NCg0KU2VlIG9wc3RhdGUtcmVxcywg cmVxdWlyZW1lbnQgMi1DLg0KDQo+IFRoZXNlIHNob3VsZCBwcm9iYWJseQ0KPiBiZSBhZGRlZCBh cyByZXF1aXJlbWVudHMgZm9yIEkyUnMgYW5kIHRoZSBuZXh0IHJldmlzaW9uIG9mIA0KPiB0aGUg b3ZlcmFsbCBZQU5HK2Fzc29jaWF0ZWQgcHJvdG9jb2xzIGZyYW1ld29yay4gICAgDQoNClN1cmUs IGJ1dCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgbmVlZGVkLCBhcyB3ZSBhbHJlYWR5IGhhdmUgdGhl DQpvcHN0YXRlLXJlcXMgZHJhZnQuDQoNCg0KS2VudA0KDQoNCg== From nobody Wed Feb 15 11:53:56 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85BB129A82 for ; Wed, 15 Feb 2017 11:53:54 -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 Ak5mkdkcBzQf for ; Wed, 15 Feb 2017 11:53:53 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41B129A8A for ; Wed, 15 Feb 2017 11:53:53 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 6607F1AE0398; Wed, 15 Feb 2017 20:53:50 +0100 (CET) Date: Wed, 15 Feb 2017 20:53:50 +0100 (CET) Message-Id: <20170215.205350.344644482805960248.mbj@tail-f.com> To: alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF804DE@SJCEML703-CHM.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> <20170215.194126.118198588680956999.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF804DE@SJCEML703-CHM.china.huawei.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:53:55 -0000 Alexander Clemm wrote: > So, the suggested solution would be to not have validation of > information, but simply have misconfigured stuff that violates > integrity constraints never show up in the state tree. If I'm not mistaken, this is how the solution in the current draft works. And it seems to me that it more or less follows from the requirement that the server can create/modify/delete any server-provided data at any time. > Perhaps this is the best that YANG can support today, although I still > find this not very satisfying. At a minimum, it would be good if the > framework would support an indication whether the configured topology > information went into effect or not. I'm not sure how useful that information would be, given that the server-provided data might disappear at any time after such an indication. /martin > The implication is that a client > will need to achieve this now by retrieving the corresponding state > tree after each configuration operation (and if the configuration > would not show correspondingly in the state tree, troubleshoot to see > what's wrong). So, if this is taken as design pattern, it would be > good to introduce operations to support that. Likewise, it would be > good to have a "diffing" operation in which state tree and > configuration tree are checked for differences and discrepancies are > reported (e.g. config not in state, and possibly vice versa). These > should probably be added as requirements for I2Rs and the next > revision of the overall YANG+associated protocols framework. > > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, February 15, 2017 10:41 AM > To: Alexander Clemm > Cc: kwatsen@juniper.net; i2rs@ietf.org > Subject: Re: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > Alexander Clemm wrote: > > Hello Martin, > > Thank you. Your first explanation is clear. Regarding the expression > > of constraints, see inline, below (thread is pruned for clarity) > > --- Alex > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Wednesday, February 15, 2017 12:12 AM > > To: Alexander Clemm > > Cc: kwatsen@juniper.net; i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > > > > > ................. > > I mean that the server will consider a configured item, and decide if > > it can be used or not. If the configured item has a reference to > > something that doesn't (yet) exist (weak reference; require-instance > > false), the server leaves the item in the config, and moves on. At > > some later time, suppose the weak reference is fulfilled; at this > > point the server decides that the configured item can be used, and it > > instantiates the item in the /-state list. Once it is there, maybe > > some other configured item has a reference to this one, and it can > > also be instantiated etc. > > > > And it goes the other way as well; suppose a server provided item is > > removed by the server; at this point the server would also remove > > items in the state list that originated in the configuration - however > > they are not removed from the config, just the state. > > (Server provided items would only show up in the state in this > > solution). > > > > The state subtree works exactly like the operational-state datastore > > in draft-ietf-netmod-revised-datastores. > > > > > > Thank you, this clarifies the earlier statement > > > > > One of the issues that we are facing is that a configured topology > > > might refer to a configured topology or a server-provided topology, > > > and we would like to avoid making a case distinction as to which > > > category we are referring to. > > > > I believe my proposed solution handles this. > > > > > At the same time, we are making use of leafrefs to express a number > > > of integrity constraints which are part of the model: as a node is > > > part of a topology, and a topology has an underlay topology, we make > > > sure that the underlay node is part of the underlay topology (and > > > not just any arbitrary node). > > > > Can you point me to the place in the model where this is specified? > > > > Or did you mean that today you have to mention this in plain text, but > > it would be nice if it could be captured formally in the model? > > > > It is covered in the model today. E.g.: > > Ok. Here the model uses require-instance false, so if these ponts to > the state tree instead, you'd get the same effect. > > > /martin > > > > > > In networks/network/node/supporting-node > > leaf network-ref { > > type leafref { > > path "../../../supporting-network/network-ref"; > > require-instance false; > > } > > (supporting node is contained in supporting network) > > > > Supporting link: > > +--rw supporting-link* [network-ref link-ref] > > +--rw network-ref -> ../../../nd:supporting-network/network-ref > > +--rw link-ref -> > > > > /nd:networks/network[nd:network-id=current()/../network-ref]/link/link > > -id > > > > (supporting link is a link contained in the supporting network) > > > > Supporting termination point: > > +--rw supporting-termination-point* [network-ref node-ref tp-ref] > > +--rw network-ref -> ../../../nd:supporting-node/network-ref > > +--rw node-ref -> ../../../nd:supporting-node/node-ref > > +--rw tp-ref -> > > > > /nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:n > > ode-id=current()/../node-ref]/termination-point/tp-id > > > > (supporting termination point is contained in supporting network and > > supporting node) > > > > It is those leafrefs whose transposition in the split subtree model > > (where we encounter alternative paths) I am concerned will be > > problematic. > > > > > > > > > From nobody Thu Feb 16 07:32:45 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159C0129621 for ; Thu, 16 Feb 2017 07:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L03LTeNkVdkz for ; Thu, 16 Feb 2017 07:32:42 -0800 (PST) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C9B12009C for ; Thu, 16 Feb 2017 07:32:41 -0800 (PST) Received: by mail-lf0-x244.google.com with SMTP id x1so1768644lff.0 for ; Thu, 16 Feb 2017 07:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=NBQc+3VbjB+L2HCz5p2ICc7F6ubLei4n6QPLsrUkY4I=; b=KHbMX9kdzGM755bqATZDoYFsV18OidWt4jSE7NdrvIki4k4Uq4581ITutCiWvThqqS t/LDnru58Pz0HKYoS2nJOVfeCYgzjoX0zlC/H3Pbd8eLs4FWddAJAiQTxo/EXVAfTfzK 9U6owGQ8fGZ5AieG5NfygoXblvkD+xws3QgN222Trn3rrzgr4Gc1R+ReOFmE0m4x6DW3 g9l/TdeArlt5FxrndbqdMqw9PQH6jlAqych8mPsKubi6CgObGTavYR3Th1AiTK9e5VxK dbCmv/IvzRrPFvcqUEFgSCA0zu23jJg/r5hMyF1+P6hVc7XTk+BhX/BwD2Dz5fE5BI9U IVpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=NBQc+3VbjB+L2HCz5p2ICc7F6ubLei4n6QPLsrUkY4I=; b=pcmpfiPr7I1UboHSqSv+PrUiC8NTqrWmhIBWsnVYBZ/d47s1oR8lyO40py+vFWU2ic 94dwaDKB4Vxxi5S11Hb7RvI8rraBXrdc65hPOPeZ4l14h5sYSlbNGd9ZrzXDt/out2Gp BNHw9YaCtsMOJGXL7/819Z/hBPQtt6I6j/p7JvyU38O+fl5UiJVal6z3NVEY49FEB/zk OIl66oaZtpGMCk45eC88ahoEPdaMDRip/tWrAeUfRmqTLTiXTr/SWweFGMPxZ2Rqn/t1 J9P9EqvBw9qs4loaHY4VwDslaqDd21oCvDC2EoOC6s3hW772fFdSw8Bhes3InW5falLD yPRQ== X-Gm-Message-State: AMke39kPNljgq6ZpcZ9FuleBZ2j6qjZGkfVVDkK61GSLQMZgeww77hYVezWvW5COshOimw== X-Received: by 10.25.216.93 with SMTP id p90mr852034lfg.59.1487259160091; Thu, 16 Feb 2017 07:32:40 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id r74sm1821523lfi.67.2017.02.16.07.32.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 07:32:39 -0800 (PST) From: "Xufeng Liu" To: "'Martin Bjorklund'" , References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> <20170215.091219.721914825568257957.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> <20170215.194126.118198588680956999.mbj@tail-f.com> In-Reply-To: <20170215.194126.118198588680956999.mbj@tail-f.com> Date: Thu, 16 Feb 2017 10:32:37 -0500 Message-ID: <007501d28869$e81639c0$b842ad40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJmRgmU/Xe+ods6juchSbrEmCYsFQFedek0AUU1L9gBd9nDtKAjaoZA Content-Language: en-us Archived-At: Cc: i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:32:44 -0000 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Wednesday, February 15, 2017 1:41 PM > To: alexander.clemm@huawei.com > Cc: i2rs@ietf.org; kwatsen@juniper.net > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > Alexander Clemm wrote: > > Hello Martin, > > Thank you. Your first explanation is clear. Regarding the expression > > of constraints, see inline, below (thread is pruned for clarity) > > --- Alex > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Wednesday, February 15, 2017 12:12 AM > > To: Alexander Clemm > > Cc: kwatsen@juniper.net; i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > > > > > ................. > > I mean that the server will consider a configured item, and decide if > > it can be used or not. If the configured item has a reference to > > something that doesn't (yet) exist (weak reference; require-instance > > false), the server leaves the item in the config, and moves on. At > > some later time, suppose the weak reference is fulfilled; at this > > point the server decides that the configured item can be used, and it > > instantiates the item in the /-state list. Once it is there, maybe > > some other configured item has a reference to this one, and it can > > also be instantiated etc. > > > > And it goes the other way as well; suppose a server provided item is > > removed by the server; at this point the server would also remove > > items in the state list that originated in the configuration - however > > they are not removed from the config, just the state. > > (Server provided items would only show up in the state in this > > solution). > > > > The state subtree works exactly like the operational-state datastore > > in draft-ietf-netmod-revised-datastores. > > > > > > Thank you, this clarifies the earlier statement > > > > > One of the issues that we are facing is that a configured topology > > > might refer to a configured topology or a server-provided topology, > > > and we would like to avoid making a case distinction as to which > > > category we are referring to. > > > > I believe my proposed solution handles this. > > > > > At the same time, we are making use of leafrefs to express a number > > > of integrity constraints which are part of the model: as a node is > > > part of a topology, and a topology has an underlay topology, we make > > > sure that the underlay node is part of the underlay topology (and > > > not just any arbitrary node). > > > > Can you point me to the place in the model where this is specified? > > > > Or did you mean that today you have to mention this in plain text, but > > it would be nice if it could be captured formally in the model? > > > > It is covered in the model today. E.g.: > > Ok. Here the model uses require-instance false, so if these ponts to the state > tree instead, you'd get the same effect. > [Xufeng] Does the leafref point to the "state tree" only? If we do so, we will miss the other half - the possible dependency to the config tree. If we let the leafref point to both, we will get the unmanageable complications. > > /martin > > > > > > In networks/network/node/supporting-node > > leaf network-ref { > > type leafref { > > path "../../../supporting-network/network-ref"; > > require-instance false; > > } > > (supporting node is contained in supporting network) > > > > Supporting link: > > +--rw supporting-link* [network-ref link-ref] > > +--rw network-ref -> ../../../nd:supporting-network/network-ref > > +--rw link-ref -> > > > > /nd:networks/network[nd:network-id=current()/../network-ref]/link/link > > -id > > > > (supporting link is a link contained in the supporting network) > > > > Supporting termination point: > > +--rw supporting-termination-point* [network-ref node-ref tp-ref] > > +--rw network-ref -> ../../../nd:supporting-node/network-ref > > +--rw node-ref -> ../../../nd:supporting-node/node-ref > > +--rw tp-ref -> > > > > /nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:n > > ode-id=current()/../node-ref]/termination-point/tp-id > > > > (supporting termination point is contained in supporting network and > > supporting node) > > > > It is those leafrefs whose transposition in the split subtree model > > (where we encounter alternative paths) I am concerned will be > > problematic. > > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 07:38:46 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78A9129A4A for ; Thu, 16 Feb 2017 07:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AHuBISF3upf for ; Thu, 16 Feb 2017 07:38:43 -0800 (PST) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80D812965D for ; Thu, 16 Feb 2017 07:38:42 -0800 (PST) Received: by mail-lf0-x244.google.com with SMTP id h65so1766443lfi.3 for ; Thu, 16 Feb 2017 07:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=pZxxTivVSJIqtxniFL7419Jj3FCBJaUl038PDZY+xAM=; b=JMFFVldJUZPArR6P3OubVHtr8hHq6S1tmLQPMXhIRwGV4dInlPok+D76W66ixUPF4Y sXaKpJXQ6YapNqAQba59eLKv8sboQe+AxnSdQHLUeRtnjv5cyxYGTvdS/ErsIMFlrwmo ZUkZkkAThCMQhzTliq5eH2/8QzjPdzg7DuwbH70Pp64X57eMRVDoA2pKgFpyRNLwxKaE T7FRuqudbjADGJNrroRbySdCxozaFdRcdMC3ghD0cHaa2oHcgcPydR4fm3q1byebclxk Ft00d3Ktnaf3d8Ye22FyYGW8C37vvil+xKJaxXs05G9rN3QQU87oJzFbz91qsB+ii8+d p2iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=pZxxTivVSJIqtxniFL7419Jj3FCBJaUl038PDZY+xAM=; b=BguscEg6cv6I8k8NU4sPPdnK6IAqhrHBsmalBjSy22r4qVz4i+CJW0mcnVab+YyeQG R7kl3g8nTRylnu4Nnhm2yJ6G0dX3R8PT7pORX7xV4M1tHKmL0eHBrYwbj2cfGE3MWf++ mu8G3I4UCsLESsZ1UCcSRG+J5ZFBNoWoRLtiygGKGg5ArLTi7uR6/e3+JNEZtr0NKbYr D5q7FrZjq9kCNND366dyS8IrDRF0tpYCSVqHjQMeH8wLQ+wQFSn01pajRveXEzeILXqE 3VMQRR+x70QP5PVxIs8E3M8y2UXP2Ok/LOl2Y5ttpvkVAAkX5V41EPIrrIAtC9BMrDWc r3Bw== X-Gm-Message-State: AMke39l8aFzlaARU26wEGFH1O1aFvU15m+A2SCf32w8332YQw9Zb6ZGKTljxAoyWj3MRRw== X-Received: by 10.46.71.207 with SMTP id u198mr847608lja.42.1487259520786; Thu, 16 Feb 2017 07:38:40 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id f25sm1844602lji.26.2017.02.16.07.38.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 07:38:40 -0800 (PST) From: "Xufeng Liu" To: "'Martin Bjorklund'" , References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> In-Reply-To: <20170214.174106.332845199336010868.mbj@tail-f.com> Date: Thu, 16 Feb 2017 10:38:37 -0500 Message-ID: <007601d2886a$bf085170$3d18f450$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQx8r72RrckYMhXWnaB0v1b2P4ZAEWoFNQAqHHXJ0B1BTo7J/C4SUw Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:38:45 -0000 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Tuesday, February 14, 2017 11:41 AM > To: kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > Kent Watsen wrote: > > > > > > [moving yang-doctors to BCC] > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > >> -------------------------------------------- > > >> > > >> This option was/is described here: > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > >> > > >> PROS: > > >> a) does NOT break legacy clients (how we got here) > > >> b) consistent with convention used in many IETF modules > > >> c) able to show if/how opstate may differ from configured values > > >> > > >> CONS: > > >> a) questionably valid YANG leafref usage > > > > > > What does this mean? > > > > I'm referring to how the description statement explains that the > > server may look to operational state in order to resolve the leafref, > > which is to result in behavior similar to pre-configuration in RFC > > 7223. > > Ok, I didn't pay close attention to the proposal in the quoted email. > > I would design this a bit differently. The config true leaf "dependency" should > have a leafref to the config false node name, with require-instance false. The > description should explain that the configuration item will be used by the server > if all dependencies exist. When the configuration item is used, it shows up in the > config false list. > > This way, the leafref usage is valid and straight forward. > > > >> b) complex server implementation (to handle require-instance > > >> false) > > > > > >Can you elaborate on this one? > > > > This is primarily a reflection of the CON listed above, in that it > > seems that a server would need to have special handling for when > > dependencies transition from being present to not-present and vice > > versa, much like the code to handle when a physical card is plugged in > > or removed. > > Yes, but I think this is inherent to the problem at hand. Even with the config true > solution defined in the current draft, it is not clear how things that were created > by the server would be deleted (if there were references to them). > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > >> solution, which would result in needing to also rewrite all > > >> modules that have augmented it (e.g., ietf-te-topology). > > >> d) leafref path expressions really only work for configuration data, > > >> though a clever server could have a special ability to peak at > > >> the opstate values when doing validations. Of course, with > > >> require-instance is false, the value of leafref based validation > > >> checking is negated anyway, even for config true nodes, so this > > >> may not matter much. > > >> > > >> > > >> > > >> OPTION 2: explicit client-option to also return tagged opstate data > > >> ------------------------------------------------------------------- > > >> > > >> This option takes a couple forms. The first is module-specific and > > >> the second is generic. In both cases, the idea is modeled after > > >> the with-defaults solution (RFC6243), wherein the client passes a > > >> special flag into causing the server to also return > > >> opstate data, having a special metadata flag set, intermingled with > > >> the configuration data. > > >> > > >> > > >> 2A: Module-specific version > > >> > > >> module foo { > > >> import ietf-netconf { prefix nc; } > > >> import ietf-yang-metadata { prefix md; } > > >> md:annotation server-provided { > > >> type boolean; > > >> } > > >> container nodes { > > >> config true; > > >> list node { > > >> key "name"; > > >> leaf name { type string; } > > >> leaf dependency { > > >> type leafref { > > >> path "../node/name" > > >> require-instance false; > > >> } > > >> } > > >> } > > >> } > > >> augment /nc:get-config/nc:input { > > >> leaf with-server-provided { > > >> type boolean; > > >> } > > >> } > > >> } > > > > > > I don't think this solution is substantially different from the > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > moved a config false leaf to a meta-data annotation. This solution > > > suffers from the same problems as the solution in > > > draft-ietf-i2rs-yang-network-topo-10. > > > > There are two primary differences: > > > > 1) It doesn't break legacy clients > > The solution in the draft doesn't break legacy clients either - there's a config > false leaf among the config true. No problem. > > > , because it requires the client to > > explicitly pass a 'with-server-provided' flag in the > > request in order to get back the extended response. Likewise, it > > doesn't break backup/restore workflows, as the server can discard > > any 'server-provided' nodes passed in an operation. > > Huh? This goes against the defined behavior of 6241 + 7950. This is the main > problem with the solution in the current draft. > > If a client sends a for data in running, the server cannot send back > data that is not in running. > > > Lastly, it doesn't break /, as there is no comingling > > of opstate data in the 'running' datastore. > > > > 2) It doesn't say anything about how the opstate data is stored on the > > server. The opstate data is not modeled at all. This approach > > only defines a presentation-layer format for how opstate data can > > be returned via an RPC. The server is free to persist the opstate > > data anyway it wants, perhaps in an internal datastore called > > 'operational-state' or in an uber-datastore with the opstate data > > flagged with a datastore='oper-state' attribute. Regardless, it's > > an implementation detail, and the conceptual datastore model is > > preserved. > > You are essentially defining a new operation, but do it by modifying the > semantics of an existing one. I don't think this is a good idea; it is better to > define a new rpc. [Xufeng] Is using a new rpc is acceptable? If so, this could be a viable option. > > > /martin > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 10:00:07 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D64128E19; Thu, 16 Feb 2017 10:00:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148726800366.1103.8452894331998920509.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 10:00:03 -0800 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-11.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:00:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : A Data Model for Network Topologies Authors : Alexander Clemm Jan Medved Robert Varga Nitin Bahadur Hariharan Ananthakrishnan Xufeng Liu Filename : draft-ietf-i2rs-yang-network-topo-11.txt Pages : 34 Date : 2017-02-16 Abstract: This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 16 10:08:33 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6D12962B for ; Thu, 16 Feb 2017 10:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MdhEwNgHg0hi for ; Thu, 16 Feb 2017 10:08:30 -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 D138A1294F8 for ; Thu, 16 Feb 2017 10:08:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGP77795; Thu, 16 Feb 2017 18:08:26 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 16 Feb 2017 18:08:25 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Thu, 16 Feb 2017 10:08:23 -0800 From: Alexander Clemm To: "i2rs@ietf.org" Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-11.txt Thread-Index: AQHSiH6k63XOxPxydkCWyt6BK6gxgaFr7J/w Date: Thu, 16 Feb 2017 18:08:22 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF808A7@SJCEML703-CHM.china.huawei.com> References: <148726800366.1103.8452894331998920509.idtracker@ietfa.amsl.com> In-Reply-To: <148726800366.1103.8452894331998920509.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58A5EA9B.02D3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 917ce8c9e2f39919220b47c59757498d Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-11.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:08:32 -0000 Hi, This draft contains mainly updates to the security considerations, as reque= sted by the chairs and area directors. =20 The draft does not yet reflect the ongoing discussions (e.g. on the other t= hread) of the design team regarding the issues related to overlay/underlay = topologies, in which we need to accommodate scenarios in which we can have = combinations between topologies that are discovered and populated by the se= rver and overlay topologies configured on top (and on top of other overlays= ). We expect to post another revision shortly to reflect those discussion= s and their outcome. --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Thursday, February 16, 2017 10:00 AM To: i-d-announce@ietf.org Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System of the IET= F. Title : A Data Model for Network Topologies Authors : Alexander Clemm Jan Medved Robert Varga Nitin Bahadur Hariharan Ananthakrishnan Xufeng Liu Filename : draft-ietf-i2rs-yang-network-topo-11.txt Pages : 34 Date : 2017-02-16 Abstract: This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-yang-network-topo-11 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 10:57:29 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32433129611 for ; Thu, 16 Feb 2017 10:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwSRhh5yPHXm for ; Thu, 16 Feb 2017 10:57:27 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D4612951B for ; Thu, 16 Feb 2017 10:57:26 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.167.252; From: "Susan Hares" To: "'Kent Watsen'" , "'Alexander Clemm'" , "'Martin Bjorklund'" References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80205@SJCEML703-CHM.china.huawei.com> <20170215.091219.721914825568257957.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> <20170215.194126.118198588680956999.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF804DE@SJCEML703-CHM.china.huawei.com> <36186505-9F9E-49EA-B033-D4AFDFD66661@juniper.net> In-Reply-To: <36186505-9F9E-49EA-B033-D4AFDFD66661@juniper.net> Date: Thu, 16 Feb 2017 13:51:55 -0500 Message-ID: <04fc01d28885$bf3eaf70$3dbc0e50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FD_01D2885B.D669B8E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJmRgmU/Xe+ods6juchSbrEmCYsFQFedek0AUU1L9gBd9nDtAK9vGWnAkMzOeKf+5huAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:57:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04FD_01D2885B.D669B8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kent, Alex, and Martin: These are clarifying question regarding the future when revised data stores is deployed: 1) If I2RS topology model and L3 Topology models are generic model in the configuration data store, . a. is disabling validation using the require-instance false path in configuration is the best mechanism you can obtain for the configuration not being there? b. Is get-state the appropriate information to determine what is the applied data store? c. Can notifications operate on changes in operational state in the applied data store? That is, if the server-supplied information is updated can notifications provide the signaling of the topology node being added to the operational state? 2) If I2RS topology model and L3 Topology model are models in the ephemeral data store? a. Can the long-term solution Kent proposed in https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html be supported by the basic get-data , write-data (or your equivalent) get-state and notification services? Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Wednesday, February 15, 2017 2:28 PM To: Alexander Clemm; Martin Bjorklund Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > So, the suggested solution would be to not have validation of > information, but simply have misconfigured stuff that violates > integrity constraints never show up in the state tree. A leafref with require-instance false, even if pointing to a path in the configuration, effectively disables validation. Still, I think a leafref is better than just a description statement. > Perhaps this is the best that YANG can support today, although I still > find this not very satisfying. At a minimum, it would be good if the > framework would support an indication whether the configured topology > information went into effect or not. The revised-datastore solution is intended to provide a way to show this. See draft-ietf-netmod-opstate-reqs. > The implication is that a client will need to achieve this now by > retrieving the corresponding state tree after each configuration > operation (and if the configuration would not show correspondingly in > the state tree, troubleshoot to see > what's wrong). So, if this is taken as design pattern, it > would be good to introduce operations to support that. See draft-ietf-netmod-opstate-reqs. > Likewise, it would be good to have a "diffing" operation in which > state tree and configuration tree are checked for differences and > discrepancies are reported (e.g. config not in state, and possibly > vice versa). See opstate-reqs, requirement 2-C. > These should probably > be added as requirements for I2Rs and the next revision of > the overall YANG+associated protocols framework. Sure, but I don't think this is needed, as we already have the opstate-reqs draft. Kent _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_04FD_01D2885B.D669B8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kent, = Alex, and Martin:

 

These = are clarifying question regarding the future when revised data stores is = deployed:  

 

1)      = If I2RS topology model and L3 Topology models = are generic model in the configuration data store,  … =

a.       is = disabling validation using the require-instance false path in = configuration is the best mechanism you can obtain for the configuration = not being there? 

b.      = Is get-state the appropriate information to = determine what is the applied data store?

c.       Can = notifications operate on changes in operational state in the applied = data store?  That is, if the server-supplied information is updated = can notifications provide the signaling of the topology node being added = to the operational state?

 

2)      = If I2RS topology model and L3 Topology model are = models in the ephemeral data store?

a.       Can = the long-term solution Kent proposed in https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html

        &nbs= p;        =      be supported by the basic get-data = <datastore-ephemeral>,  write-data = <datastore-ephemeral> (or your equivalent)

        &nbs= p;            = ;get-state <applied-state> and notification services? =  

 

Sue Hares

 

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: = Wednesday, February 15, 2017 2:28 PM
To: Alexander Clemm; Martin = Bjorklund
Cc: i2rs@ietf.org
Subject: Re: [i2rs] modeling options = for draft-ietf-i2rs-yang-network-topo

 

 

> = So, the suggested solution would be to not have validation of =

> information, but simply have = misconfigured stuff that violates

> integrity constraints never show up in the = state tree.

 

A = leafref with require-instance false, even if pointing to a path in the = configuration, effectively disables validation.  Still, I think a = leafref is better than just a description statement.

 

> = Perhaps this is the best that YANG can support today, although I still =

> find this not very = satisfying.  At a minimum, it would be good if the =

> framework would support an = indication whether the configured topology

> information went into effect or = not.

 

The revised-datastore solution is intended to = provide a way to show this.  See = draft-ietf-netmod-opstate-reqs.

 

> = The implication is that a client will need to achieve this now by =

> retrieving the corresponding = state tree after each configuration

> operation (and if the configuration would not = show correspondingly in

> the = state tree, troubleshoot to see

> what's wrong).   So, if this is = taken as design pattern, it

> = would be good to introduce operations to support that.

 

See = draft-ietf-netmod-opstate-reqs.

 

> = Likewise, it would be good to have a "diffing" operation in = which

> state tree and = configuration tree are checked for differences and

> discrepancies are reported (e.g. config not in = state, and possibly

> vice = versa).

 

See opstate-reqs, requirement 2-C.

 

> = These should probably

> be = added as requirements for I2Rs and the next revision of =

> the overall YANG+associated = protocols framework.   

 

Sure, = but I don't think this is needed, as we already have the opstate-reqs = draft.

 

 

Kent

 

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_04FD_01D2885B.D669B8E0-- From nobody Thu Feb 16 11:00:17 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9B212955E for ; Thu, 16 Feb 2017 11:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdHK8Oeqbcrl for ; Thu, 16 Feb 2017 11:00:13 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3B312941A for ; Thu, 16 Feb 2017 11:00:13 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id i10so18144032wrb.0 for ; Thu, 16 Feb 2017 11:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OG/oaEEFolzmN0xJmlaTEEo9tP9ukvks7zS1+wu0zrE=; b=ayX745bxgWYgjN00Kti3IsbtscJDC36pKWo+p2tOdZxKlgXOHvMkGmW8xVY9p4hjdf kQ+Q3uLy5LD6k2m98nU/EI6ENtFEKur4ovxT+TXObkHAgGNXEyfqSBdz3kgC/hGZBc0h uNcyoRLe4t+3/dyztNTqxuDrYZjjmJW9sMsQL9O9r82j5e0vYDjrZEBhGUyT13l1kbtz tDlArQAvKEM4b31m5U/n8KPi8WCr4l+i5n3RGzSj8EIVUROBy07hltH13zWoaYxX6/NT uN82nk9rHR0xQuAH2iwI5raMJgjD4I+99fFgX+v/ihr3L2Ctvy/wlGHzHXNTvH+fObsf TBmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OG/oaEEFolzmN0xJmlaTEEo9tP9ukvks7zS1+wu0zrE=; b=ik8tptJt6nEpR8lWxF34Zbjov1Z500Kc8xggmiOsQ0hEKYA6s3be65e+6Hv4b3bGd6 Jqzrar/gBW7H29CKG/3lSEHvv9fjDE5JvGkmfRg/lG+ZP9L1Panp0Vgx5juxn9qOyvNH CqRm1GejTGt+WcP/H8kFEC6RY6AMXggADuepmnWPEoLH2VM3kj1OAlIoN9qKGjQzRhCB 0jO4mRUpdQENLPhoJWUeVkM8QecukDzFkyW1RZ2WyggZXKNi4dGeKZnnXTviWMP32c+Y 62YBH/xL4YkOZEGJFKuquTtiRtt1WLWrnBOgZqAoUCd/AX65vTOcBGJ9YS1X/jNs3oR7 jqcg== X-Gm-Message-State: AMke39nE9BeVcaukSYolsxwR8gxTWl6/5CV/0uox434r+MyiFdkqZsOcS3DirZPSWGX86XZg2BL7UugiLaG2JA== X-Received: by 10.223.151.138 with SMTP id s10mr3551513wrb.65.1487271611256; Thu, 16 Feb 2017 11:00:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Thu, 16 Feb 2017 11:00:10 -0800 (PST) From: Andy Bierman Date: Thu, 16 Feb 2017 11:00:10 -0800 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b59121355510548aa68ee Archived-At: Subject: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:00:15 -0000 --94eb2c1b59121355510548aa68ee Content-Type: text/plain; charset=UTF-8 Hi, The use of NACM for server-provided data is under-specified (at best) from sec. 4.1: Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that can be discovered. If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. *Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true.* When they do, they need to be aware that any modifications they make are subject to be reverted by the server. For servers that support NACM (Netconf Access Control Model), *data node rules should ideally prevent* write access by other clients to network instances for which server- provided is set to true. The SHOULD NOT above is really odd, considering is not supported by YANG or the NC/RC protocols. "data node rules should ideally prevent" s/should/SHOULD/ Ideally prevent? Is that a new engineering term? Either this new usage of NACM works or it doesn't. Also, there is no guidance or examples of the NACM config that the server is supposed to magically create for server-provided topology data. There is nothing in NACM at all about server-created data rules. This is not supported by NACM. Does the I2RS text imply that the server-provided property extends to the NACM sub-trees? They are also subject to replacement by the server? The client SHOULD NOT change these NACM rules? IMO the way this server-provided property is being done is a short-sighted point solution, but this should be a fundamental part of the revised datastores work. Is there something special about network topology such that server-provided data for a different module will require a different solution? If not, is the topo module solution reusable? Andy --94eb2c1b59121355510548aa68ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The use of NACM for server-provided= data is under-specified (at best)


= from sec. 4.1:

   Finally, there is an object "=
;server-provided".  This object is state
   that indicates how the network came into being.  Network data can
   come into being in one of two ways.  In one way, network data is
   configured by client applications, for example in case of overlay
   networks that are configured by an SDN Controller application.  In
   annother way, it is populated by the server, in case of networks that
   can be discovered.

   If server-provided is set to false, the network was configured by a
   client application, for example in the case of an overlay network
   that is configured by a controller application.  If server-provided
   is set to true, the network was populated by the server itself,
   respectively an application on the server that is able to discover
   the network.  Client applications SHOULD NOT modify configurations of
   networks for which "server-provided" is true.  When they d=
o, they
   need to be aware that any modifications they make are subject to be
   reverted by the server.  For servers that support NACM (Netconf
   Access Control Model), data node rules should ideally prevent wri=
te
   access by other clients to network instances for which server-
   provided is set to true.

The SHOULD NOT above is really odd, conside= ring is not supported by YANG
or the NC/RC protocols.
<= br>
"d= ata node rules should ideally prevent"

s/should/SHOULD/

Ideally prevent?
Is th= at a new engineering term?
Either this new usage of NACM works or it doesn'= t.
<= br>
= Also, there is no guidance or examples of the NACM config that the
server is su= pposed to magically create for server-provided topology data.
<= div>There is nothing = in NACM at all about server-created data rules.
This is not supported by NACM.<= /span>

=
Does the I2RS text imply that the server-provided property extends
to the NACM sub-trees? They are also subject to replacement by the se= rver?
The client SHOULD NOT change these NACM rules?
IMO the way this server-provided property is being done is a s= hort-sighted
point solution, but this should be a fundamental par= t of the revised datastores work.
Is there something special abou= t network topology such that
server-provided data for a different= module will require a different
solution? If not, is the topo m= odule solution reusable?


Andy



--94eb2c1b59121355510548aa68ee-- From nobody Thu Feb 16 11:07:02 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0AF12966C for ; Thu, 16 Feb 2017 11:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqwfLqR9mHaZ for ; Thu, 16 Feb 2017 11:07:00 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F55412951B for ; Thu, 16 Feb 2017 11:07:00 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.167.252; From: "Susan Hares" To: "'Xufeng Liu'" , "'Martin Bjorklund'" , References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> In-Reply-To: <007601d2886a$bf085170$3d18f450$@gmail.com> Date: Thu, 16 Feb 2017 14:01:57 -0500 Message-ID: <050901d28887$25a887d0$70f99770$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKQx8r72RrckYMhXWnaB0v1b2P4ZAEWoFNQAqHHXJ0B1BTo7AGVrx3gn7Zq7OA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:07:02 -0000 To Xufeng: Clarifying question - Are you asking about I2RS topology as a generic yang model for any configuration or are you asking about I2RS topology model as an ephemeral topology model. To Martin: Clarifying questions: 1) Is your rpc suggest target toward the I2RS topology model as a generic topology model or an I2RS ephemeral state model or both? 2) Could we define rpcs now that operate as Alex desired for generic topology models that could be replaced by more generic mechanisms later? For example, the I2RS RIB has defined rpcs for all major functions (add/delete rib, add/delete route, add/delete nexhop) plus notifications for changes. Is this the best approach here? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, February 16, 2017 10:39 AM To: 'Martin Bjorklund'; kwatsen@juniper.net Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > Bjorklund > Sent: Tuesday, February 14, 2017 11:41 AM > To: kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > Kent Watsen wrote: > > > > > > [moving yang-doctors to BCC] > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > >> -------------------------------------------- > > >> > > >> This option was/is described here: > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > >> > > >> PROS: > > >> a) does NOT break legacy clients (how we got here) > > >> b) consistent with convention used in many IETF modules > > >> c) able to show if/how opstate may differ from configured > > >> values > > >> > > >> CONS: > > >> a) questionably valid YANG leafref usage > > > > > > What does this mean? > > > > I'm referring to how the description statement explains that the > > server may look to operational state in order to resolve the > > leafref, which is to result in behavior similar to pre-configuration > > in RFC 7223. > > Ok, I didn't pay close attention to the proposal in the quoted email. > > I would design this a bit differently. The config true leaf "dependency" should > have a leafref to the config false node name, with require-instance false. The > description should explain that the configuration item will be used by > the server > if all dependencies exist. When the configuration item is used, it > shows up in the > config false list. > > This way, the leafref usage is valid and straight forward. > > > >> b) complex server implementation (to handle require-instance > > >> false) > > > > > >Can you elaborate on this one? > > > > This is primarily a reflection of the CON listed above, in that it > > seems that a server would need to have special handling for when > > dependencies transition from being present to not-present and vice > > versa, much like the code to handle when a physical card is plugged > > in or removed. > > Yes, but I think this is inherent to the problem at hand. Even with > the config true > solution defined in the current draft, it is not clear how things that were created > by the server would be deleted (if there were references to them). > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > >> solution, which would result in needing to also rewrite all > > >> modules that have augmented it (e.g., ietf-te-topology). > > >> d) leafref path expressions really only work for configuration data, > > >> though a clever server could have a special ability to peak at > > >> the opstate values when doing validations. Of course, with > > >> require-instance is false, the value of leafref based validation > > >> checking is negated anyway, even for config true nodes, so this > > >> may not matter much. > > >> > > >> > > >> > > >> OPTION 2: explicit client-option to also return tagged opstate > > >> data > > >> ----------------------------------------------------------------- > > >> -- > > >> > > >> This option takes a couple forms. The first is module-specific > > >> and the second is generic. In both cases, the idea is modeled > > >> after the with-defaults solution (RFC6243), wherein the client > > >> passes a special flag into causing the server to > > >> also return opstate data, having a special metadata flag set, > > >> intermingled with the configuration data. > > >> > > >> > > >> 2A: Module-specific version > > >> > > >> module foo { > > >> import ietf-netconf { prefix nc; } > > >> import ietf-yang-metadata { prefix md; } > > >> md:annotation server-provided { > > >> type boolean; > > >> } > > >> container nodes { > > >> config true; > > >> list node { > > >> key "name"; > > >> leaf name { type string; } > > >> leaf dependency { > > >> type leafref { > > >> path "../node/name" > > >> require-instance false; > > >> } > > >> } > > >> } > > >> } > > >> augment /nc:get-config/nc:input { > > >> leaf with-server-provided { > > >> type boolean; > > >> } > > >> } > > >> } > > > > > > I don't think this solution is substantially different from the > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > moved a config false leaf to a meta-data annotation. This > > > solution suffers from the same problems as the solution in > > > draft-ietf-i2rs-yang-network-topo-10. > > > > There are two primary differences: > > > > 1) It doesn't break legacy clients > > The solution in the draft doesn't break legacy clients either - > there's a config > false leaf among the config true. No problem. > > > , because it requires the client to > > explicitly pass a 'with-server-provided' flag in the > > request in order to get back the extended response. Likewise, it > > doesn't break backup/restore workflows, as the server can discard > > any 'server-provided' nodes passed in an operation. > > Huh? This goes against the defined behavior of 6241 + 7950. This is > the main > problem with the solution in the current draft. > > If a client sends a for data in running, the server > cannot send back > data that is not in running. > > > Lastly, it doesn't break /, as there is no comingling > > of opstate data in the 'running' datastore. > > > > 2) It doesn't say anything about how the opstate data is stored on the > > server. The opstate data is not modeled at all. This approach > > only defines a presentation-layer format for how opstate data can > > be returned via an RPC. The server is free to persist the opstate > > data anyway it wants, perhaps in an internal datastore called > > 'operational-state' or in an uber-datastore with the opstate data > > flagged with a datastore='oper-state' attribute. Regardless, it's > > an implementation detail, and the conceptual datastore model is > > preserved. > > You are essentially defining a new operation, but do it by modifying > the semantics of an existing one. I don't think this is a good idea; > it is better to > define a new rpc. [Xufeng] Is using a new rpc is acceptable? If so, this could be a viable option. > > > /martin > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 11:41:39 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551221294C3 for ; Thu, 16 Feb 2017 11:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4YKyC4ampee for ; Thu, 16 Feb 2017 11:41:36 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918B512941A for ; Thu, 16 Feb 2017 11:41:36 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.20.38; From: "Susan Hares" To: "'Andy Bierman'" , References: In-Reply-To: Date: Thu, 16 Feb 2017 14:29:52 -0500 Message-ID: <052601d2888b$0c11cad0$24356070$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0527_01D28861.233D2260" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5e8ZMvi/EETguMJznKI7RJqEheaCeHQ7Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:41:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0527_01D28861.233D2260 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 =20 Thank you for bringing up your questions regarding NACM, I2RS = topologies, and revised data stores. This area of discussion may be = part of Alex=E2=80=99s work that he indicates he=E2=80=99s going to = review. Splitting the conversation into =E2=80=9Ccurrent=E2=80=9D yang = and =E2=80=9Crevised datastores=E2=80=9D yang is a very good idea. I = encourage the authors to do so. =20 =20 =20 =20 IMO the way this server-provided property is being done is a = short-sighted point solution, but this should be a fundamental part of the revised = datastores work. Is there something special about network topology such that server-provided data for a different module will require a different solution? If not, is the topo module solution reusable?=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, February 16, 2017 2:00 PM To: i2rs@ietf.org Subject: [i2rs] topo model use of NACM =20 Hi, =20 The use of NACM for server-provided data is under-specified (at best) =20 =20 from sec. 4.1: =20 Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that can be discovered. =20 If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true. When they do, they need to be aware that any modifications they make are subject to be reverted by the server. For servers that support NACM (Netconf Access Control Model), data node rules should ideally prevent write access by other clients to network instances for which server- provided is set to true. =20 The SHOULD NOT above is really odd, considering is not supported by YANG or the NC/RC protocols. =20 "data node rules should ideally prevent" =20 s/should/SHOULD/ =20 Ideally prevent? Is that a new engineering term? Either this new usage of NACM works or it doesn't. =20 Also, there is no guidance or examples of the NACM config that the server is supposed to magically create for server-provided topology = data. There is nothing in NACM at all about server-created data rules. This is not supported by NACM. =20 Does the I2RS text imply that the server-provided property extends to the NACM sub-trees? They are also subject to replacement by the = server? The client SHOULD NOT change these NACM rules? =20 IMO the way this server-provided property is being done is a = short-sighted point solution, but this should be a fundamental part of the revised = datastores work. Is there something special about network topology such that server-provided data for a different module will require a different solution? If not, is the topo module solution reusable?=20 =20 =20 Andy =20 =20 =20 ------=_NextPart_000_0527_01D28861.233D2260 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

<chair hat>

Thank you for bringing up your questions regarding NACM, =C2=A0I2RS = topologies, and revised data stores. =C2=A0This area of discussion may = be part of Alex=E2=80=99s work that he indicates he=E2=80=99s going to = review.=C2=A0 Splitting the conversation into =E2=80=9Ccurrent=E2=80=9D = yang and =E2=80=9Crevised datastores=E2=80=9D yang is a very good = idea.=C2=A0 I encourage the authors to do so.=C2=A0 =

</chair hat off>

 

 

IMO the way this server-provided property is being = done is a short-sighted

point solution, but this should be a fundamental = part of the revised datastores work.

Is there something special = about network topology such that

server-provided data for a = different module will require a different

solution? If not, is the = topo module solution reusable?

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Thursday, February 16, 2017 2:00 = PM
To: i2rs@ietf.org
Subject: [i2rs] topo model use = of NACM

 

Hi,

 

The use of NACM for server-provided data is = under-specified (at best)

 

 

from sec. 4.1:

 

=C2=A0=C2=A0 Finally, there is an object =
"server-provided".=C2=A0 This object is =
state
=C2=A0=C2=A0 that indicates how the network came =
into being.=C2=A0 Network data can
=C2=A0=C2=A0 come into being in one of two =
ways.=C2=A0 In one way, network data =
is
=C2=A0=C2=A0 =
configured by client applications, for example in case of =
overlay
=C2=A0=C2=A0 networks that are configured by an =
SDN Controller application.=C2=A0 In
=C2=A0=C2=A0 annother way, it is populated by the =
server, in case of networks that
=C2=A0=C2=A0 can be =
discovered.
 
=C2=A0=C2=A0 If server-provided is set to false, =
the network was configured by a
=C2=A0=C2=A0 client application, for example in =
the case of an overlay network
=C2=A0=C2=A0 that is configured by a controller =
application.=C2=A0 If server-provided
=C2=A0=C2=A0 is set to true, the network was =
populated by the server itself,
=C2=A0=C2=A0 respectively an application on the =
server that is able to discover
=C2=A0=C2=A0 the network.=C2=A0 Client =
applications SHOULD NOT modify configurations =
of
=C2=A0=C2=A0 networks for which =
"server-provided" is true.=C2=A0 When they do, =
they
=C2=A0=C2=A0 need to be aware that any =
modifications they make are subject to =
be
=C2=A0=C2=A0 =
reverted by the server.=C2=A0 For servers that support NACM =
(Netconf
=C2=A0=C2=A0 Access Control Model), data node =
rules should ideally prevent write
=C2=A0=C2=A0 access by other clients to network =
instances for which server-
=C2=A0=C2=A0 provided is set to =
true.

 

The SHOULD NOT above is really odd, considering is not = supported by YANG

or the = NC/RC protocols.

 

"data node rules = should ideally prevent"

 

s/should/SHOULD/

 

Ideally = prevent?

Is that a new engineering = term?

Either this new usage of NACM works or it = doesn't.

 

Also, there is no guidance = or examples of the NACM config that = the

server is supposed to magically create for = server-provided topology data.

There is nothing in NACM = at all about server-created data = rules.

This is not supported by = NACM.

 

Does the I2RS text imply = that the server-provided property = extends

to the NACM sub-trees? They are also subject to = replacement by the server?

The client SHOULD NOT = change these NACM rules?

 

IMO the way this = server-provided property is being done is a = short-sighted

point solution, but this should be a fundamental = part of the revised datastores work.

Is there something special = about network topology such that

server-provided data for a = different module will require a = different

solution? If not, is the topo module solution = reusable?

 

 

Andy

 

 

 

------=_NextPart_000_0527_01D28861.233D2260-- From nobody Thu Feb 16 11:48:27 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DF3129470 for ; Thu, 16 Feb 2017 11:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voRUAjgS4OGe for ; Thu, 16 Feb 2017 11:48:23 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B382A128E18 for ; Thu, 16 Feb 2017 11:48:22 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id q89so2243279lfi.1 for ; Thu, 16 Feb 2017 11:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=w8tr/6oH0bP73573iA9gl3e0FYPqymE6tJsvGiMPuEg=; b=Ottd8v2gj9/yw0fUEM84NCqUde53zCUUdyVifsd6qDaNRIU7UXmTGKcsKpEmQh36Ut EzHCSfeUThFJy2rHG8gZE7JdO/jWc49FMLBfO2ESrk+pcL3su688fS/Ft+Zf6NyRIlxA iOrG83QOqj8tXHzLTNUpIgfskUvUjDqqPJQkTXN8nVy4B838LFBRKqQlpyLfM4g+wZ50 1Djhk3mkYustn2BqqeUvL09AUcREfc1AlI/7FwgP13y0FnXNI7FJblcq3VGrUAEJ+AgA e5g8YnUMhxjiwsnvOnyrau/fGxfMJkQ2igZR1T23+R9SDGxalV6w4Ong7IiVn3g5KPot n4Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=w8tr/6oH0bP73573iA9gl3e0FYPqymE6tJsvGiMPuEg=; b=exqjikGsgI8czlFw6u7112o5ZD/He7Wy/EHh4rCMBBRk6oTT+tzpxe7cJ0e0Cwlx4Q 6imLYi/9NCSFeSh9LSaIci8NtMu4FDTMBGy1Ky8CNXz6OHVtTNcqiJjhfDvWuybdE4dk 0ncVxpJ5hCy7B3m85PWRe5D+KpjJYbysFPHfRhoh3dISrC5XIlGeKY3o3dN50CQg+6nl vfO6J5rV17hAvaWwJ7wPePtK/52LyCcg5JYi9fEyPYvtH7JZfoRopuxx5o6XrHFIGlu7 CIYGfgc9a9SAGWdGVFJAcj5/AhLHTkARdgWFcDA7GfJ0iGvyRD4CgnrCuezB9ex32F+o 76Iw== X-Gm-Message-State: AMke39mS7sUCGbQDI9dwST6ZK/6GrVPGvR+l2jpQ3z/mZHH/la8pVHFKHkgoDiS9Hd5kHw== X-Received: by 10.46.77.27 with SMTP id a27mr1125685ljb.104.1487274500886; Thu, 16 Feb 2017 11:48:20 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id 64sm1957592lfs.30.2017.02.16.11.48.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 11:48:20 -0800 (PST) From: "Xufeng Liu" To: "'Susan Hares'" , "'Martin Bjorklund'" , References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <050901d28887$25a887d0$70f99770$@ndzh.com> In-Reply-To: <050901d28887$25a887d0$70f99770$@ndzh.com> Date: Thu, 16 Feb 2017 14:48:17 -0500 Message-ID: <00bd01d2888d$9fe53290$dfaf97b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQx8r72RrckYMhXWnaB0v1b2P4ZAEWoFNQAqHHXJ0B1BTo7AGVrx3gAjEJjgefpPDKgA== Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:48:25 -0000 Hi Sue, > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, February 16, 2017 2:02 PM > To: 'Xufeng Liu' ; 'Martin Bjorklund' f.com>; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: RE: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > To Xufeng: > > Clarifying question - Are you asking about I2RS topology as a generic yang > model for any configuration or are you asking about I2RS topology model as an > ephemeral topology model. [Xufeng] I was talking about I2RS topology as a generic yang model for any configuration, but I think that the same solution can be applied to ephemeral case, though a separate rpc might be needed. Thanks, - Xufeng > > To Martin: > Clarifying questions: > > 1) Is your rpc suggest target toward the I2RS topology model as a generic > topology model or an I2RS ephemeral state model or both? > > 2) Could we define rpcs now that operate as Alex desired for generic topology > models that could be replaced by more generic mechanisms later? > For example, the I2RS RIB has defined rpcs for all major functions (add/delete rib, > add/delete route, add/delete nexhop) plus notifications for changes. Is this the > best approach here? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > Sent: Thursday, February 16, 2017 10:39 AM > To: 'Martin Bjorklund'; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > > Bjorklund > > Sent: Tuesday, February 14, 2017 11:41 AM > > To: kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > Kent Watsen wrote: > > > > > > > > > [moving yang-doctors to BCC] > > > > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > > >> -------------------------------------------- > > > >> > > > >> This option was/is described here: > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > > >> > > > >> PROS: > > > >> a) does NOT break legacy clients (how we got here) > > > >> b) consistent with convention used in many IETF modules > > > >> c) able to show if/how opstate may differ from configured > > > >> values > > > >> > > > >> CONS: > > > >> a) questionably valid YANG leafref usage > > > > > > > > What does this mean? > > > > > > I'm referring to how the description statement explains that the > > > server may look to operational state in order to resolve the > > > leafref, which is to result in behavior similar to pre-configuration > > > in RFC 7223. > > > > Ok, I didn't pay close attention to the proposal in the quoted email. > > > > I would design this a bit differently. The config true leaf "dependency" > should > > have a leafref to the config false node name, with require-instance false. > The > > description should explain that the configuration item will be used by > > the > server > > if all dependencies exist. When the configuration item is used, it > > shows > up in the > > config false list. > > > > This way, the leafref usage is valid and straight forward. > > > > > >> b) complex server implementation (to handle require-instance > > > >> false) > > > > > > > >Can you elaborate on this one? > > > > > > This is primarily a reflection of the CON listed above, in that it > > > seems that a server would need to have special handling for when > > > dependencies transition from being present to not-present and vice > > > versa, much like the code to handle when a physical card is plugged > > > in or removed. > > > > Yes, but I think this is inherent to the problem at hand. Even with > > the > config true > > solution defined in the current draft, it is not clear how things that > were created > > by the server would be deleted (if there were references to them). > > > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > > >> solution, which would result in needing to also rewrite all > > > >> modules that have augmented it (e.g., ietf-te-topology). > > > >> d) leafref path expressions really only work for configuration > data, > > > >> though a clever server could have a special ability to peak at > > > >> the opstate values when doing validations. Of course, with > > > >> require-instance is false, the value of leafref based validation > > > >> checking is negated anyway, even for config true nodes, so this > > > >> may not matter much. > > > >> > > > >> > > > >> > > > >> OPTION 2: explicit client-option to also return tagged opstate > > > >> data > > > >> ----------------------------------------------------------------- > > > >> -- > > > >> > > > >> This option takes a couple forms. The first is module-specific > > > >> and the second is generic. In both cases, the idea is modeled > > > >> after the with-defaults solution (RFC6243), wherein the client > > > >> passes a special flag into causing the server to > > > >> also return opstate data, having a special metadata flag set, > > > >> intermingled with the configuration data. > > > >> > > > >> > > > >> 2A: Module-specific version > > > >> > > > >> module foo { > > > >> import ietf-netconf { prefix nc; } > > > >> import ietf-yang-metadata { prefix md; } > > > >> md:annotation server-provided { > > > >> type boolean; > > > >> } > > > >> container nodes { > > > >> config true; > > > >> list node { > > > >> key "name"; > > > >> leaf name { type string; } > > > >> leaf dependency { > > > >> type leafref { > > > >> path "../node/name" > > > >> require-instance false; > > > >> } > > > >> } > > > >> } > > > >> } > > > >> augment /nc:get-config/nc:input { > > > >> leaf with-server-provided { > > > >> type boolean; > > > >> } > > > >> } > > > >> } > > > > > > > > I don't think this solution is substantially different from the > > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > > moved a config false leaf to a meta-data annotation. This > > > > solution suffers from the same problems as the solution in > > > > draft-ietf-i2rs-yang-network-topo-10. > > > > > > There are two primary differences: > > > > > > 1) It doesn't break legacy clients > > > > The solution in the draft doesn't break legacy clients either - > > there's a > config > > false leaf among the config true. No problem. > > > > > , because it requires the client to > > > explicitly pass a 'with-server-provided' flag in the > > > request in order to get back the extended response. Likewise, it > > > doesn't break backup/restore workflows, as the server can discard > > > any 'server-provided' nodes passed in an operation. > > > > Huh? This goes against the defined behavior of 6241 + 7950. This is > > the > main > > problem with the solution in the current draft. > > > > If a client sends a for data in running, the server > > cannot > send back > > data that is not in running. > > > > > Lastly, it doesn't break /, as there is no comingling > > > of opstate data in the 'running' datastore. > > > > > > 2) It doesn't say anything about how the opstate data is stored on the > > > server. The opstate data is not modeled at all. This approach > > > only defines a presentation-layer format for how opstate data can > > > be returned via an RPC. The server is free to persist the opstate > > > data anyway it wants, perhaps in an internal datastore called > > > 'operational-state' or in an uber-datastore with the opstate data > > > flagged with a datastore='oper-state' attribute. Regardless, it's > > > an implementation detail, and the conceptual datastore model is > > > preserved. > > > > You are essentially defining a new operation, but do it by modifying > > the semantics of an existing one. I don't think this is a good idea; > > it is > better to > > define a new rpc. > > [Xufeng] Is using a new rpc is acceptable? If so, this could be a viable option. > > > > > > > /martin > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 11:52:19 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323CC128E18 for ; Thu, 16 Feb 2017 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BORjY89-cs4R for ; Thu, 16 Feb 2017 11:52:13 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36DA129689 for ; Thu, 16 Feb 2017 11:52:12 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.20.38; From: "Susan Hares" To: "'Andy Bierman'" , References: In-Reply-To: Date: Thu, 16 Feb 2017 14:47:16 -0500 Message-ID: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_054C_01D28863.91D4D4F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5e8ZMvi/EETguMJznKI7RJqEheaCeHo7A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:52:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_054C_01D28863.91D4D4F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 =20 AFAIK =E2=80=93 I believe the revised data store model is right = approach. It is an important question to ask whether the ability to = have a mixture of =E2=80=9Cserver-provided=E2=80=9D and = =E2=80=9Cconfigured=E2=80=9D is important for all topology models. I = hope Xufeng and other topology models will comment on this point.=20 =20 =20 Does the NETCONF data store in the revised data-store future include the = control plane data stores? I thought the answer was =E2=80=9Cno=E2=80=9D = it does not. Here=E2=80=99s some text from = draft-ietf-netconf-rfc6536bis that leads me to believe that=20 =20 On NACM, draft-ietf-netconf-rfc6536bis it says:=20 =20 It is necessary to control access to specific nodes and subtrees within the NETCONF datastore, regardless of which protocol operation, standard or proprietary, was used to access the datastore. =20 = 3.2. Datastore Access The same access control rules apply to all datastores, for example, the candidate configuration datastore or the running configuration datastore. =20 Only the standard NETCONF datastores (candidate, running, and startup) are controlled by NACM. Local or remote files or datastores accessed via the parameter are not controlled by NACM. A standalone RESTCONF server (i.e., not co-located with a NETCONF server) applies NACM rules to a conceptual datastore, since datastores are not supported in RESTCONF. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 The I2RS security environment actually looks at 3 policies on the server = =20 Network Access =C3=9F-=C3=A0 server =C3=9F-=C3=A0 routing-system access = (aka I2RS agent) |=C3=9F=C3=A0 System access=20 =20 It also looks at application access to the client=20 =20 Network access=C3=9F=C3=A0 client =C3=9F=C3=A0 application-access =20 =20 =20 The protocol only needs to consider the NACM Access, but the routing = infrastructure need to consider the server to/from routing system, and = server to/from system. My understanding is that the Routing system = access control module (RACM) and the system access control module (SACM) = functions were not in NACM.=20 =20 Thanks again for posting,=20 =20 Sue =20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, February 16, 2017 2:00 PM To: i2rs@ietf.org Subject: [i2rs] topo model use of NACM =20 Hi, =20 The use of NACM for server-provided data is under-specified (at best) =20 =20 from sec. 4.1: =20 Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that can be discovered. =20 If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true. When they do, they need to be aware that any modifications they make are subject to be reverted by the server. For servers that support NACM (Netconf Access Control Model), data node rules should ideally prevent write access by other clients to network instances for which server- provided is set to true. =20 The SHOULD NOT above is really odd, considering is not supported by YANG or the NC/RC protocols. =20 "data node rules should ideally prevent" =20 s/should/SHOULD/ =20 Ideally prevent? Is that a new engineering term? Either this new usage of NACM works or it doesn't. =20 Also, there is no guidance or examples of the NACM config that the server is supposed to magically create for server-provided topology = data. There is nothing in NACM at all about server-created data rules. This is not supported by NACM. =20 Does the I2RS text imply that the server-provided property extends to the NACM sub-trees? They are also subject to replacement by the = server? The client SHOULD NOT change these NACM rules? =20 IMO the way this server-provided property is being done is a = short-sighted point solution, but this should be a fundamental part of the revised = datastores work. Is there something special about network topology such that server-provided data for a different module will require a different solution? If not, is the topo module solution reusable?=20 =20 =20 Andy =20 =20 =20 ------=_NextPart_000_054C_01D28863.91D4D4F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy: =

<chair = hat off, individual contributor hat on>

 =

AFAIK = =E2=80=93 I believe the revised data store model is right approach. = =C2=A0=C2=A0It is an important question to ask whether the ability to = have a mixture of =E2=80=9Cserver-provided=E2=80=9D and = =E2=80=9Cconfigured=E2=80=9D is important for all topology models.=C2=A0 = I hope Xufeng and other topology models will comment on this point. =

 =

 

Does the NETCONF = data store in the revised data-store future include the control plane = data stores? I thought the answer was =E2=80=9Cno=E2=80=9D it does = not.=C2=A0 =C2=A0Here=E2=80=99s some text from = draft-ietf-netconf-rfc6536bis that leads me to believe that =

 =

On NACM, = draft-ietf-netconf-rfc6536bis it says:

 =

=C2=A0=C2=A0 It is = necessary to control access to specific nodes and = subtrees

=C2=A0=C2=A0 within = the NETCONF datastore, regardless of which protocol = operation,

=C2=A0=C2=A0 = standard or proprietary, was used to access the = datastore.

 

3.2.=C2=A0 = Datastore Access

 =
=C2=A0=C2=A0The same access control rules apply to all datastores, for =
example,
=C2=A0=C2=A0 the candidate configuration datastore =
or the running configuration
=C2=A0=C2=A0 =
datastore.
 
=C2=A0=C2=A0 Only the standard NETCONF datastores =
(candidate, running, and
=C2=A0=C2=A0 startup) are controlled by =
NACM.=C2=A0 Local or remote files or =
datastores
=C2=A0=C2=A0 accessed via the <url> =
parameter are not controlled by NACM.=C2=A0 =
A
=C2=A0=C2=A0 =
standalone RESTCONF server (i.e., not co-located with a =
NETCONF
=C2=A0=C2=A0 server) applies NACM rules to a =
conceptual datastore, since
=C2=A0=C2=A0 datastores are not supported in =
RESTCONF.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

The I2RS security = environment actually looks at 3 policies on the server =

 

Network Access = =C3=9F-=C3=A0 server = =C3=9F-=C3=A0 routing-system = access =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0(aka I2RS agent)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0|=C3=9F=C3=A0 System access =

 

It also looks at = application access to the client

 

=C2=A0 Network = access=C3=9F=C3=A0 client = =C3=9F=C3=A0 application-access = =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

The protocol only = needs to consider the NACM Access, but the routing infrastructure need = to consider the server to/from routing system, and server to/from = system. =C2=A0My understanding is that the Routing system access control = module (RACM) and the system access control module (SACM) functions were = not in NACM.

 

Thanks again for = posting,

 

Sue = =C2=A0

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Thursday, February 16, 2017 2:00 = PM
To: i2rs@ietf.org
Subject: [i2rs] topo model use = of NACM

 

Hi,

 

The use of NACM for server-provided data is = under-specified (at best)

 

 

from sec. 4.1:

 

=C2=A0=C2=A0 Finally, there is an object =
"server-provided".=C2=A0 This object is =
state
=C2=A0=C2=A0 that indicates how the network came =
into being.=C2=A0 Network data can
=C2=A0=C2=A0 come into being in one of two =
ways.=C2=A0 In one way, network data =
is
=C2=A0=C2=A0 =
configured by client applications, for example in case of =
overlay
=C2=A0=C2=A0 networks that are configured by an =
SDN Controller application.=C2=A0 In
=C2=A0=C2=A0 annother way, it is populated by the =
server, in case of networks that
=C2=A0=C2=A0 can be =
discovered.
 
=C2=A0=C2=A0 If server-provided is set to false, =
the network was configured by a
=C2=A0=C2=A0 client application, for example in =
the case of an overlay network
=C2=A0=C2=A0 that is configured by a controller =
application.=C2=A0 If server-provided
=C2=A0=C2=A0 is set to true, the network was =
populated by the server itself,
=C2=A0=C2=A0 respectively an application on the =
server that is able to discover
=C2=A0=C2=A0 the network.=C2=A0 Client =
applications SHOULD NOT modify configurations =
of
=C2=A0=C2=A0 networks for which =
"server-provided" is true.=C2=A0 When they do, =
they
=C2=A0=C2=A0 need to be aware that any =
modifications they make are subject to =
be
=C2=A0=C2=A0 =
reverted by the server.=C2=A0 For servers that support NACM =
(Netconf
=C2=A0=C2=A0 Access Control Model), data node =
rules should ideally prevent write
=C2=A0=C2=A0 access by other clients to network =
instances for which server-
=C2=A0=C2=A0 provided is set to =
true.

 

The SHOULD NOT above is really odd, considering is not = supported by YANG

or the = NC/RC protocols.

 

"data node rules = should ideally prevent"

 

s/should/SHOULD/

 

Ideally = prevent?

Is that a new engineering = term?

Either this new usage of NACM works or it = doesn't.

 

Also, there is no guidance = or examples of the NACM config that = the

server is supposed to magically create for = server-provided topology data.

There is nothing in NACM = at all about server-created data = rules.

This is not supported by = NACM.

 

Does the I2RS text imply = that the server-provided property = extends

to the NACM sub-trees? They are also subject to = replacement by the server?

The client SHOULD NOT = change these NACM rules?

 

IMO the way this = server-provided property is being done is a = short-sighted

point solution, but this should be a fundamental = part of the revised datastores work.

Is there something special = about network topology such that

server-provided data for a = different module will require a = different

solution? If not, is the topo module solution = reusable?

 

 

Andy

 

 

 

------=_NextPart_000_054C_01D28863.91D4D4F0-- From nobody Thu Feb 16 11:58:40 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A831294C3 for ; Thu, 16 Feb 2017 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNuliVkUV44K for ; Thu, 16 Feb 2017 11:58:37 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B65B1296A4 for ; Thu, 16 Feb 2017 11:58:32 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.20.38; From: "Susan Hares" To: "'Xufeng Liu'" , "'Martin Bjorklund'" , References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <050901d28887$25a887d0$70f99770$@ndzh.com> <00bd01d2888d$9fe53290$dfaf97b0$@gmail.com> In-Reply-To: <00bd01d2888d$9fe53290$dfaf97b0$@gmail.com> Date: Thu, 16 Feb 2017 14:53:15 -0500 Message-ID: <055801d2888e$50276ba0$f07642e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKQx8r72RrckYMhXWnaB0v1b2P4ZAEWoFNQAqHHXJ0B1BTo7AGVrx3gAjEJjgcB0cJWu5+WZK+Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:58:39 -0000 Xufeng: I suspect 2 rpcs will be needed, but Martin and Kent are the experts. Do you think trying to accelerate the revised data stores solutions is a better way to go? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, February 16, 2017 2:48 PM To: 'Susan Hares'; 'Martin Bjorklund'; kwatsen@juniper.net Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Hi Sue, > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, February 16, 2017 2:02 PM > To: 'Xufeng Liu' ; 'Martin Bjorklund' f.com>; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: RE: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > To Xufeng: > > Clarifying question - Are you asking about I2RS topology as a generic > yang model for any configuration or are you asking about I2RS topology > model as an > ephemeral topology model. [Xufeng] I was talking about I2RS topology as a generic yang model for any configuration, but I think that the same solution can be applied to ephemeral case, though a separate rpc might be needed. Thanks, - Xufeng > > To Martin: > Clarifying questions: > > 1) Is your rpc suggest target toward the I2RS topology model as a > generic topology model or an I2RS ephemeral state model or both? > > 2) Could we define rpcs now that operate as Alex desired for generic topology > models that could be replaced by more generic mechanisms later? > For example, the I2RS RIB has defined rpcs for all major functions (add/delete rib, > add/delete route, add/delete nexhop) plus notifications for changes. > Is this the > best approach here? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > Sent: Thursday, February 16, 2017 10:39 AM > To: 'Martin Bjorklund'; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > > Bjorklund > > Sent: Tuesday, February 14, 2017 11:41 AM > > To: kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > Kent Watsen wrote: > > > > > > > > > [moving yang-doctors to BCC] > > > > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > > >> -------------------------------------------- > > > >> > > > >> This option was/is described here: > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > > >> > > > >> PROS: > > > >> a) does NOT break legacy clients (how we got here) > > > >> b) consistent with convention used in many IETF modules > > > >> c) able to show if/how opstate may differ from configured > > > >> values > > > >> > > > >> CONS: > > > >> a) questionably valid YANG leafref usage > > > > > > > > What does this mean? > > > > > > I'm referring to how the description statement explains that the > > > server may look to operational state in order to resolve the > > > leafref, which is to result in behavior similar to > > > pre-configuration in RFC 7223. > > > > Ok, I didn't pay close attention to the proposal in the quoted email. > > > > I would design this a bit differently. The config true leaf "dependency" > should > > have a leafref to the config false node name, with require-instance false. > The > > description should explain that the configuration item will be used > > by the > server > > if all dependencies exist. When the configuration item is used, it > > shows > up in the > > config false list. > > > > This way, the leafref usage is valid and straight forward. > > > > > >> b) complex server implementation (to handle require-instance > > > >> false) > > > > > > > >Can you elaborate on this one? > > > > > > This is primarily a reflection of the CON listed above, in that it > > > seems that a server would need to have special handling for when > > > dependencies transition from being present to not-present and vice > > > versa, much like the code to handle when a physical card is > > > plugged in or removed. > > > > Yes, but I think this is inherent to the problem at hand. Even with > > the > config true > > solution defined in the current draft, it is not clear how things > > that > were created > > by the server would be deleted (if there were references to them). > > > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > > >> solution, which would result in needing to also rewrite all > > > >> modules that have augmented it (e.g., ietf-te-topology). > > > >> d) leafref path expressions really only work for > > > >> configuration > data, > > > >> though a clever server could have a special ability to peak at > > > >> the opstate values when doing validations. Of course, with > > > >> require-instance is false, the value of leafref based validation > > > >> checking is negated anyway, even for config true nodes, so this > > > >> may not matter much. > > > >> > > > >> > > > >> > > > >> OPTION 2: explicit client-option to also return tagged opstate > > > >> data > > > >> --------------------------------------------------------------- > > > >> -- > > > >> -- > > > >> > > > >> This option takes a couple forms. The first is module-specific > > > >> and the second is generic. In both cases, the idea is modeled > > > >> after the with-defaults solution (RFC6243), wherein the client > > > >> passes a special flag into causing the server to > > > >> also return opstate data, having a special metadata flag set, > > > >> intermingled with the configuration data. > > > >> > > > >> > > > >> 2A: Module-specific version > > > >> > > > >> module foo { > > > >> import ietf-netconf { prefix nc; } > > > >> import ietf-yang-metadata { prefix md; } > > > >> md:annotation server-provided { > > > >> type boolean; > > > >> } > > > >> container nodes { > > > >> config true; > > > >> list node { > > > >> key "name"; > > > >> leaf name { type string; } > > > >> leaf dependency { > > > >> type leafref { > > > >> path "../node/name" > > > >> require-instance false; > > > >> } > > > >> } > > > >> } > > > >> } > > > >> augment /nc:get-config/nc:input { > > > >> leaf with-server-provided { > > > >> type boolean; > > > >> } > > > >> } > > > >> } > > > > > > > > I don't think this solution is substantially different from the > > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > > moved a config false leaf to a meta-data annotation. This > > > > solution suffers from the same problems as the solution in > > > > draft-ietf-i2rs-yang-network-topo-10. > > > > > > There are two primary differences: > > > > > > 1) It doesn't break legacy clients > > > > The solution in the draft doesn't break legacy clients either - > > there's a > config > > false leaf among the config true. No problem. > > > > > , because it requires the client to > > > explicitly pass a 'with-server-provided' flag in the > > > request in order to get back the extended response. Likewise, it > > > doesn't break backup/restore workflows, as the server can discard > > > any 'server-provided' nodes passed in an operation. > > > > Huh? This goes against the defined behavior of 6241 + 7950. This > > is the > main > > problem with the solution in the current draft. > > > > If a client sends a for data in running, the server > > cannot > send back > > data that is not in running. > > > > > Lastly, it doesn't break /, as there is no comingling > > > of opstate data in the 'running' datastore. > > > > > > 2) It doesn't say anything about how the opstate data is stored on the > > > server. The opstate data is not modeled at all. This approach > > > only defines a presentation-layer format for how opstate data can > > > be returned via an RPC. The server is free to persist the opstate > > > data anyway it wants, perhaps in an internal datastore called > > > 'operational-state' or in an uber-datastore with the opstate data > > > flagged with a datastore='oper-state' attribute. Regardless, it's > > > an implementation detail, and the conceptual datastore model is > > > preserved. > > > > You are essentially defining a new operation, but do it by modifying > > the semantics of an existing one. I don't think this is a good > > idea; it is > better to > > define a new rpc. > > [Xufeng] Is using a new rpc is acceptable? If so, this could be a > viable option. > > > > > > > /martin > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 12:49:19 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254CB1296A6 for ; Thu, 16 Feb 2017 12:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3A6yTD_2Mgp for ; Thu, 16 Feb 2017 12:49:16 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4C9129569 for ; Thu, 16 Feb 2017 12:49:16 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id c4so19577544wrd.2 for ; Thu, 16 Feb 2017 12:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iEwP9LXAfe8I4wmva2s0Nl68ixc31TsjUCzILtqSDyA=; b=OJhO2LD+ketJtB7IS1yMv5caDehdnMBHwU8XPmdw3WDLJzKxfLqVmHbUzkrsdS3ud9 4AARpW2TtBdY8kj3hldhMwn4loJR9gT9EjcGFAHVXPf+fW2diZVVWOzadu2Ib6mzAEH1 AkBnDrU/+Hdq67qxtdmp+7VsuxdpMkkYeY186IxyAloV50nxu/3S7FMvpg0YXCNHBT0y vh3P+9sswhCC1EFRClsIU/qqg7v4LGJIzodgtG2JCy1cnSSODYFTer6+ACyAUT0grKqe PiAAWIXp9AUCCA58I7FW5OZQN7zZkIQQlOCOjPOybZ6fYbRe1h6+b84NA3CeCCg1mAaK VuDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iEwP9LXAfe8I4wmva2s0Nl68ixc31TsjUCzILtqSDyA=; b=O5xSTWhRPYvf5dUCKbDF44Rr8/TBu382ggAjc+RVxUJ3KdAvMoWwP3rMlEAiR1ERNE aAn27m+CehK9RDvIHUY3cJ64F5vbOg6Mf1bEkovXj3rtvkYZDpDuV09Iodib74Nfihtw 4fmllgmx7FEHR5YzCPb3E7J+S2MbM5rRe/6bSmvvgJ9xdd/FCgebHa3Z7MB302V1lp3U svB1t0UfUSSKswV87jbbFLrVQwhmKr/TerNi7BNvmFk114fB5+W+m2ryohappI1VU4dC lzpPj5xE5Sha7e9dp5nC2U9m3L+39LCZ7thYzERbQtUqRHPQbdqlrNutELHnAXp045U5 jQHQ== X-Gm-Message-State: AMke39n+NAgXpcZTN2TlEZUpfSE9GP6sPz2fCLXJVRoTnuSVzBQJ3BymJhTTivREANfzJWBfFCeJEzX1jlPrNQ== X-Received: by 10.223.165.17 with SMTP id i17mr4431758wrb.62.1487278154490; Thu, 16 Feb 2017 12:49:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Thu, 16 Feb 2017 12:49:13 -0800 (PST) In-Reply-To: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> From: Andy Bierman Date: Thu, 16 Feb 2017 12:49:13 -0800 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=f403045f1fb014bb6a0548abee17 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:49:18 -0000 --f403045f1fb014bb6a0548abee17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am most concerned about getting the architecture right. We have ignored server-created nodes until now. I am glad I2RS WG is trying to deal with the problem. Just make sure we have a reusable solution. Also concerned about tool automation. There was some discussion of a 'server-created' extension at some point I think. This would help, because the server-created leaf is not really deterministic. It is just a convention. e.g. container networks { list network { i2rs:server-created; ... leaf server-created { ... } ... } } Andy On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares wrote: > Andy: > > > > > > AFAIK =E2=80=93 I believe the revised data store model is right approach.= It is > an important question to ask whether the ability to have a mixture of > =E2=80=9Cserver-provided=E2=80=9D and =E2=80=9Cconfigured=E2=80=9D is imp= ortant for all topology models. I > hope Xufeng and other topology models will comment on this point. > > > > > > Does the NETCONF data store in the revised data-store future include the > control plane data stores? I thought the answer was =E2=80=9Cno=E2=80=9D = it does not. > Here=E2=80=99s some text from draft-ietf-netconf-rfc6536bis that leads m= e to > believe that > > > > On NACM, draft-ietf-netconf-rfc6536bis it says: > > > > It is necessary to control access to specific nodes and subtrees > > within the NETCONF datastore, regardless of which protocol operation, > > standard or proprietary, was used to access the datastore. > > > 3.2 > . > Datastore Access > > The same access control rules apply to all datastores, for example, > > the candidate configuration datastore or the running configuration > > datastore. > > > > Only the standard NETCONF datastores (candidate, running, and > > startup) are controlled by NACM. Local or remote files or datastores > > accessed via the parameter are not controlled by NACM. A > > standalone RESTCONF server (i.e., not co-located with a NETCONF > > server) applies NACM rules to a conceptual datastore, since > > datastores are not supported in RESTCONF. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > The I2RS security environment actually looks at 3 policies on the server > > > > Network Access =C3=9F-=C3=A0 server =C3=9F-=C3=A0 routing-system access > > (aka I2RS agent) > > |=C3=9F=C3=A0 System access > > > > It also looks at application access to the client > > > > Network access=C3=9F=C3=A0 client =C3=9F=C3=A0 application-access > > > > > > The protocol only needs to consider the NACM Access, but the routing > infrastructure need to consider the server to/from routing system, and > server to/from system. My understanding is that the Routing system acces= s > control module (RACM) and the system access control module (SACM) functio= ns > were not in NACM. > > > > Thanks again for posting, > > > > Sue > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Thursday, February 16, 2017 2:00 PM > *To:* i2rs@ietf.org > *Subject:* [i2rs] topo model use of NACM > > > > Hi, > > > > The use of NACM for server-provided data is under-specified (at best) > > > > > > from sec. 4.1: > > > > Finally, there is an object "server-provided". This object is state > > that indicates how the network came into being. Network data can > > come into being in one of two ways. In one way, network data is > > configured by client applications, for example in case of overlay > > networks that are configured by an SDN Controller application. In > > annother way, it is populated by the server, in case of networks that > > can be discovered. > > > > If server-provided is set to false, the network was configured by a > > client application, for example in the case of an overlay network > > that is configured by a controller application. If server-provided > > is set to true, the network was populated by the server itself, > > respectively an application on the server that is able to discover > > the network. *Client applications SHOULD NOT modify configurations of= * > > * networks for which "server-provided" is true.* When they do, they > > need to be aware that any modifications they make are subject to be > > reverted by the server. For servers that support NACM (Netconf > > Access Control Model), *data node rules should ideally prevent* write > > access by other clients to network instances for which server- > > provided is set to true. > > > > The SHOULD NOT above is really odd, considering is not supported by YANG > > or the NC/RC protocols. > > > > "data node rules should ideally prevent" > > > > s/should/SHOULD/ > > > > Ideally prevent? > > Is that a new engineering term? > > Either this new usage of NACM works or it doesn't. > > > > Also, there is no guidance or examples of the NACM config that the > > server is supposed to magically create for server-provided topology data. > > There is nothing in NACM at all about server-created data rules. > > This is not supported by NACM. > > > > Does the I2RS text imply that the server-provided property extends > > to the NACM sub-trees? They are also subject to replacement by the server= ? > > The client SHOULD NOT change these NACM rules? > > > > IMO the way this server-provided property is being done is a short-sighte= d > > point solution, but this should be a fundamental part of the revised > datastores work. > > Is there something special about network topology such that > > server-provided data for a different module will require a different > > solution? If not, is the topo module solution reusable? > > > > > > Andy > > > > > > > --f403045f1fb014bb6a0548abee17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am most concerned about getting t= he architecture right.
We have ignored server-created nodes until= now.
I am glad I2RS WG is trying to deal with the problem.
=
Just make sure we have a reusable solution.

A= lso concerned about tool automation.
There was some discussion of= a 'server-created' extension at some point I think.
This= would help, because the server-created leaf is not really deterministic.
It is just a convention.

e.g.
<= div class=3D"gmail_extra">

=C2=A0 container networks {
=C2=A0 =C2=A0 =C2=A0list network {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs:server-created;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf server-created { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 }


Andy


On = Thu, Feb 16, 2017 at 11:47 AM, Susan Hares <shares@ndzh.com> w= rote:

Andy:

<chair hat off, individual contributor hat on>

=C2=A0=

AFAIK =E2=80=93 I believ= e the revised data store model is right approach. =C2=A0=C2=A0It is an impo= rtant question to ask whether the ability to have a mixture of =E2=80=9Cser= ver-provided=E2=80=9D and =E2=80=9Cconfigured=E2=80=9D is important for all= topology models.=C2=A0 I hope Xufeng and other topology models will commen= t on this point.

=C2=A0

=C2=A0

Does the NETCONF data store in the revised data-sto= re future include the control plane data stores? I thought the answer was = =E2=80=9Cno=E2=80=9D it does not.=C2=A0 =C2=A0Here=E2=80=99s some text from= draft-ietf-netconf-rfc6536bis that leads me to believe that =

=C2=A0<= /p>

On NACM, draft-ietf-netconf-rfc6536b= is it says:

=C2=A0

=C2=A0=C2=A0 It is necessary = to control access to specific nodes and subtrees

=C2=A0=C2=A0 within the NETCONF datastore, regardless of whi= ch protocol operation,

=C2=A0=C2= =A0 standard or proprietary, was used to access the datastore.

=C2=A0

3= .2.=C2=A0 Datastore Access

<=
span style=3D"color:black"> =C2=A0=C2=A0The same access control rules apply=
 to all datastores, for example,
=C2=A0=C2=A0 the candidate configuration datastore or the =
running configuration
=C2=A0=C2=A0 datastore.
=C2=A0
=C2=A0=C2=A0 Only the standard NETCONF datastores (candidate, running,=
 and
=C2=A0=C2=
=A0 startup) are controlled by NACM.=C2=A0 Local or remote files or datasto=
res
=C2=A0=C2=A0=
 accessed via the <url> parameter are not controlled by NACM.=C2=A0 A=

=C2=A0=C2=A0 st=
andalone RESTCONF server (i.e., not co-located with a NETCONF=

=C2=A0=C2=A0 server) applies =
NACM rules to a conceptual datastore, since
=
=C2=A0=C2=A0 datastores are not supported in RE=
STCONF.

=C2=A0

=C2=A0

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= =C2=A0

The I2RS security environment = actually looks at 3 policies on the server

=C2=A0

Network Access =C3=9F-= =C3=A0 server =C3=9F-=C3=A0 routing-system = access =C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(aka I2RS= agent)

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0|=C3=9F= =C3=A0 System access

=C2= =A0

It also looks at application access = to the client

=C2=A0<= /u>

=C2=A0 Network access=C3=9F=C3=A0 client =C3=9F=C3=A0 application-access =C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= u>

=C2=A0

The protocol only needs to consider the NACM Access, but the = routing infrastructure need to consider the server to/from routing system, = and server to/from system.=C2=A0 My understanding is that the Routing syste= m access control module (RACM) and the system access control module (SACM) = functions were not in NACM.

=C2=A0

Thanks again for posting,

=C2=A0

Sue =C2=A0

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Beh= alf Of Andy Bierman
Sent: Thursday, February 16, 2017 2:00 PM=
To: i2rs@ietf= .org
Subject: [i2rs] topo model use of NACM

=C2=A0

Hi,

=C2=A0

The use of NACM for server-provided = data is under-specified (at best)

=C2=A0

= =C2=A0

from sec. 4.1:=

=C2=A0

=C2=A0=C2=A0 Finally, there is an object "server-provided&=
quot;.=C2=A0 This object is state
=C2=A0=C2=A0 that indicates how the network came into bei=
ng.=C2=A0 Network data can
=C2=A0=C2=A0 come into being in one of two ways.=C2=A0 In one wa=
y, network data is
=C2=A0=C2=A0 configured by client applications, for example in case of o=
verlay
=C2=A0=C2=
=A0 networks that are configured by an SDN Controller application.=C2=A0 In=

=C2=A0=C2=A0 an=
nother way, it is populated by the server, in case of networks that<=
u>
=C2=A0=C2=A0 can be dis=
covered.
=
=C2=A0
=C2=A0=C2=A0 If =
server-provided is set to false, the network was configured by a<=
/u>
=C2=A0=C2=A0 client applic=
ation, for example in the case of an overlay network
=C2=A0=C2=A0 that is configured by a c=
ontroller application.=C2=A0 If server-provided
<=
pre>=C2=A0=C2=A0 is set to true, the network wa=
s populated by the server itself,
=C2=A0=C2=A0 respectively an application on the server th=
at is able to discover
=C2=A0=C2=A0 the network.=C2=A0 Client applications SHOULD NOT mo=
dify configurations of
=C2=A0=C2=A0 networks for which "server-provided" i=
s true.=C2=A0 When they do, they<=
/u>
=C2=A0=C2=A0 need t=
o be aware that any modifications they make are subject to be=

=C2=A0=C2=A0 reverted by the =
server.=C2=A0 For servers that support NACM (Netconf
=C2=A0=C2=A0 Access Control Model), data node rules should ideally prevent write
=C2=A0=C2=A0 access by other clients to n=
etwork instances for which server-
=C2=A0=C2=A0 provided is set to true.

=C2=A0

The SHOULD NOT above is really odd, considering is= not supported by YANG

o= r the NC/RC protocols.

<= u>=C2=A0

"data node rules should ideally prevent"=

=C2=A0

=

s/should/SHOULD/

=C2=A0

Ideally = prevent?

Is that a new engineering term?

Either this = new usage of NACM works or it doesn't.

=C2=A0

Also, there is no guidance or examples= of the NACM config that the

server is supposed to magically cre= ate for server-provided topology data.

<= p class=3D"MsoNormal">There is nothing in NACM = at all about server-created data rules.

=

This is not supported by= NACM.

=C2= =A0

Does the I2RS text imply that the server-provided property extends<= u>

to the NACM sub-trees? They are also subject to replacement by the serv= er?

The client SHOULD NOT change these NACM rules?

=C2=A0

IMO the way this = server-provided property is being done is a short-sighted<= /u>

point = solution, but this should be a fundamental part of the revised datastores w= ork.

Is there something special about network topology such tha= t

server-provided data for a different module will require a dif= ferent

solution? If not, is the topo module solution reusable? <= /span>

=C2=A0<= /u>

=C2=A0

Andy

=C2=A0

=

=C2=A0

=C2=A0

--f403045f1fb014bb6a0548abee17-- From nobody Thu Feb 16 13:14:27 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD52B1296C1 for ; Thu, 16 Feb 2017 13:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BvWVPfh8mJKS for ; Thu, 16 Feb 2017 13:14:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DE3BB1294F4 for ; Thu, 16 Feb 2017 13:14:14 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id CE8DE1AE033A; Thu, 16 Feb 2017 22:14:12 +0100 (CET) Date: Thu, 16 Feb 2017 22:14:12 +0100 (CET) Message-Id: <20170216.221412.2181707942833993110.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: i2rs@ietf.org, shares@ndzh.com Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:14:19 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBIaSwNCj4gDQo+IEkg YW0gbW9zdCBjb25jZXJuZWQgYWJvdXQgZ2V0dGluZyB0aGUgYXJjaGl0ZWN0dXJlIHJpZ2h0Lg0K PiBXZSBoYXZlIGlnbm9yZWQgc2VydmVyLWNyZWF0ZWQgbm9kZXMgdW50aWwgbm93Lg0KPiBJIGFt IGdsYWQgSTJSUyBXRyBpcyB0cnlpbmcgdG8gZGVhbCB3aXRoIHRoZSBwcm9ibGVtLg0KPiBKdXN0 IG1ha2Ugc3VyZSB3ZSBoYXZlIGEgcmV1c2FibGUgc29sdXRpb24uDQo+IA0KPiBBbHNvIGNvbmNl cm5lZCBhYm91dCB0b29sIGF1dG9tYXRpb24uDQo+IFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24g b2YgYSAnc2VydmVyLWNyZWF0ZWQnIGV4dGVuc2lvbiBhdCBzb21lIHBvaW50IEkNCj4gdGhpbmsu DQoNClRoYXQgb2xkIGRpc2N1c3Npb24gd2FzIGFib3V0IGEgZGlmZmVyZW50IChhbmQgc2ltcGxl cikgdXNlIGNhc2U7IGl0DQp3YXMgYWJvdXQgd2hlbiBhIHNlcnZlciB3b3VsZCBhZGQgc29tZSBu b2RlcyB0byB0aGUgY29uZmlndXJhdGlvbiBhcw0KcGFydCBvZiBhIGNsaWVudCdzIGNyZWF0aW9u IHJlcXVlc3QuICBGb3IgZXhhbXBsZSwgYSBzZXJ2ZXIgd291bGQNCmF1dG9tYXRpY2FsbHkgYXNz aWduIGEgJ3VpZCcgdG8gYSBuZXdseSBjcmVhdGVkIHVzZXIuDQoNClRoZSB0b3BvbG9neSB1c2Ug Y2FzZSBpcyBtb3JlIGNvbXBsaWNhdGVkLiAgVGhlIHNlcnZlciBjYW4gZGlzY292ZXIgYQ0KdG9w b2xvZ3kgYW5kIGluc3RhbnRpYXRlIGl0IHNvbWV3aGVyZSAtIG9yaWdpbmFsbHkgaXQgd2FzIGlu c3RhbnRpYXRlZA0KaW4gdGhlIGNvbmZpZ3VyYXRpb24sIGJ1dCB0aGF0IGlzIHF1ZXN0aW9uYWJs ZS4gIEkgc3RpbGwgZG9uJ3QgcmVhbGx5DQp1bmRlcnN0YW5kIHRoZSBleHBlY3RlZCBsaWZlY3lj bGUgb2YgdGhlc2Ugc2VydmVyIHByb3ZpZGVkIGluc3RhbmNlczsNCnNwZWNpZmljYWxseSwgY2Fu IHRoZXkgY29tZSBhbmQgZ28gY29tcGxldGVseSBkeW5hbWljYWxseSwgZXZlbiBpZg0KdGhlcmUg YXJlIG90aGVyIGluc3RhbmNlcyB0aGF0IHJlZmVyIHRvIHRoZW0/DQoNCg0KL21hcnRpbg0KDQoN Cg0KDQo+IFRoaXMgd291bGQgaGVscCwgYmVjYXVzZSB0aGUgc2VydmVyLWNyZWF0ZWQgbGVhZiBp cyBub3QgcmVhbGx5DQo+IGRldGVybWluaXN0aWMuDQo+IEl0IGlzIGp1c3QgYSBjb252ZW50aW9u Lg0KPiANCj4gZS5nLg0KPiANCj4gDQo+ICAgY29udGFpbmVyIG5ldHdvcmtzIHsNCj4gICAgICBs aXN0IG5ldHdvcmsgew0KPiAgICAgICAgICBpMnJzOnNlcnZlci1jcmVhdGVkOw0KPiAgICAgICAg ICAuLi4NCj4gICAgICAgICAgbGVhZiBzZXJ2ZXItY3JlYXRlZCB7IC4uLiB9DQo+ICAgICAgICAg IC4uLg0KPiAgICAgIH0NCj4gICB9DQo+IA0KPiANCj4gQW5keQ0KPiANCj4gDQo+IE9uIFRodSwg RmViIDE2LCAyMDE3IGF0IDExOjQ3IEFNLCBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPiB3 cm90ZToNCj4gDQo+ID4gQW5keToNCj4gPg0KPiA+IDxjaGFpciBoYXQgb2ZmLCBpbmRpdmlkdWFs IGNvbnRyaWJ1dG9yIGhhdCBvbj4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBRkFJSyDigJMgSSBiZWxp ZXZlIHRoZSByZXZpc2VkIGRhdGEgc3RvcmUgbW9kZWwgaXMgcmlnaHQgYXBwcm9hY2guICAgSXQg aXMNCj4gPiBhbiBpbXBvcnRhbnQgcXVlc3Rpb24gdG8gYXNrIHdoZXRoZXIgdGhlIGFiaWxpdHkg dG8gaGF2ZSBhIG1peHR1cmUgb2YNCj4gPiDigJxzZXJ2ZXItcHJvdmlkZWTigJ0gYW5kIOKAnGNv bmZpZ3VyZWTigJ0gaXMgaW1wb3J0YW50IGZvciBhbGwgdG9wb2xvZ3kgbW9kZWxzLiAgSQ0KPiA+ IGhvcGUgWHVmZW5nIGFuZCBvdGhlciB0b3BvbG9neSBtb2RlbHMgd2lsbCBjb21tZW50IG9uIHRo aXMgcG9pbnQuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IERvZXMgdGhlIE5FVENPTkYg ZGF0YSBzdG9yZSBpbiB0aGUgcmV2aXNlZCBkYXRhLXN0b3JlIGZ1dHVyZSBpbmNsdWRlIHRoZQ0K PiA+IGNvbnRyb2wgcGxhbmUgZGF0YSBzdG9yZXM/IEkgdGhvdWdodCB0aGUgYW5zd2VyIHdhcyDi gJxub+KAnSBpdCBkb2VzIG5vdC4NCj4gPiAgSGVyZeKAmXMgc29tZSB0ZXh0IGZyb20gZHJhZnQt aWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMgdGhhdCBsZWFkcyBtZSB0bw0KPiA+IGJlbGlldmUgdGhh dA0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIE5BQ00sIGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2 YmlzIGl0IHNheXM6DQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgSXQgaXMgbmVjZXNzYXJ5IHRvIGNv bnRyb2wgYWNjZXNzIHRvIHNwZWNpZmljIG5vZGVzIGFuZCBzdWJ0cmVlcw0KPiA+DQo+ID4gICAg d2l0aGluIHRoZSBORVRDT05GIGRhdGFzdG9yZSwgcmVnYXJkbGVzcyBvZiB3aGljaCBwcm90b2Nv bCBvcGVyYXRpb24sDQo+ID4NCj4gPiAgICBzdGFuZGFyZCBvciBwcm9wcmlldGFyeSwgd2FzIHVz ZWQgdG8gYWNjZXNzIHRoZSBkYXRhc3RvcmUuDQo+ID4NCj4gPg0KPiA+IDMuMg0KPiA+IDxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMtMDAj c2VjdGlvbi0zLjI+Lg0KPiA+IERhdGFzdG9yZSBBY2Nlc3MNCj4gPg0KPiA+ICAgIFRoZSBzYW1l IGFjY2VzcyBjb250cm9sIHJ1bGVzIGFwcGx5IHRvIGFsbCBkYXRhc3RvcmVzLCBmb3IgZXhhbXBs ZSwNCj4gPg0KPiA+ICAgIHRoZSBjYW5kaWRhdGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgb3Ig dGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbg0KPiA+DQo+ID4gICAgZGF0YXN0b3JlLg0KPiA+DQo+ ID4NCj4gPg0KPiA+ICAgIE9ubHkgdGhlIHN0YW5kYXJkIE5FVENPTkYgZGF0YXN0b3JlcyAoY2Fu ZGlkYXRlLCBydW5uaW5nLCBhbmQNCj4gPg0KPiA+ICAgIHN0YXJ0dXApIGFyZSBjb250cm9sbGVk IGJ5IE5BQ00uICBMb2NhbCBvciByZW1vdGUgZmlsZXMgb3IgZGF0YXN0b3Jlcw0KPiA+DQo+ID4g ICAgYWNjZXNzZWQgdmlhIHRoZSA8dXJsPiBwYXJhbWV0ZXIgYXJlIG5vdCBjb250cm9sbGVkIGJ5 IE5BQ00uICBBDQo+ID4NCj4gPiAgICBzdGFuZGFsb25lIFJFU1RDT05GIHNlcnZlciAoaS5lLiwg bm90IGNvLWxvY2F0ZWQgd2l0aCBhIE5FVENPTkYNCj4gPg0KPiA+ICAgIHNlcnZlcikgYXBwbGll cyBOQUNNIHJ1bGVzIHRvIGEgY29uY2VwdHVhbCBkYXRhc3RvcmUsIHNpbmNlDQo+ID4NCj4gPiAg ICBkYXRhc3RvcmVzIGFyZSBub3Qgc3VwcG9ydGVkIGluIFJFU1RDT05GLg0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPiA9PT09PT09PT09PQ0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoZSBJMlJT IHNlY3VyaXR5IGVudmlyb25tZW50IGFjdHVhbGx5IGxvb2tzIGF0IDMgcG9saWNpZXMgb24gdGhl IHNlcnZlcg0KPiA+DQo+ID4NCj4gPg0KPiA+IE5ldHdvcmsgQWNjZXNzIMOfLcOgIHNlcnZlciDD ny3DoCByb3V0aW5nLXN5c3RlbSBhY2Nlc3MNCj4gPg0KPiA+ICAgICAgICAgICAgICAgKGFrYSBJ MlJTIGFnZW50KQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICB8w5/DoCBTeXN0ZW0gYWNj ZXNzDQo+ID4NCj4gPg0KPiA+DQo+ID4gSXQgYWxzbyBsb29rcyBhdCBhcHBsaWNhdGlvbiBhY2Nl c3MgdG8gdGhlIGNsaWVudA0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgTmV0d29yayBhY2Nlc3PDn8Og IGNsaWVudCDDn8OgIGFwcGxpY2F0aW9uLWFjY2Vzcw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4N Cj4gPiBUaGUgcHJvdG9jb2wgb25seSBuZWVkcyB0byBjb25zaWRlciB0aGUgTkFDTSBBY2Nlc3Ms IGJ1dCB0aGUgcm91dGluZw0KPiA+IGluZnJhc3RydWN0dXJlIG5lZWQgdG8gY29uc2lkZXIgdGhl IHNlcnZlciB0by9mcm9tIHJvdXRpbmcgc3lzdGVtLCBhbmQNCj4gPiBzZXJ2ZXIgdG8vZnJvbSBz eXN0ZW0uICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIFJvdXRpbmcgc3lzdGVtIGFjY2Vz cw0KPiA+IGNvbnRyb2wgbW9kdWxlIChSQUNNKSBhbmQgdGhlIHN5c3RlbSBhY2Nlc3MgY29udHJv bCBtb2R1bGUgKFNBQ00pIGZ1bmN0aW9ucw0KPiA+IHdlcmUgbm90IGluIE5BQ00uDQo+ID4NCj4g Pg0KPiA+DQo+ID4gVGhhbmtzIGFnYWluIGZvciBwb3N0aW5nLA0KPiA+DQo+ID4NCj4gPg0KPiA+ IFN1ZQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICpGcm9tOiogaTJycyBbbWFpbHRvOmkycnMtYm91bmNl c0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqQW5keSBCaWVybWFuDQo+ID4gKlNlbnQ6KiBUaHVy c2RheSwgRmVicnVhcnkgMTYsIDIwMTcgMjowMCBQTQ0KPiA+ICpUbzoqIGkycnNAaWV0Zi5vcmcN Cj4gPiAqU3ViamVjdDoqIFtpMnJzXSB0b3BvIG1vZGVsIHVzZSBvZiBOQUNNDQo+ID4NCj4gPg0K PiA+DQo+ID4gSGksDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIHVzZSBvZiBOQUNNIGZvciBzZXJ2 ZXItcHJvdmlkZWQgZGF0YSBpcyB1bmRlci1zcGVjaWZpZWQgKGF0IGJlc3QpDQo+ID4NCj4gPg0K PiA+DQo+ID4NCj4gPg0KPiA+IGZyb20gc2VjLiA0LjE6DQo+ID4NCj4gPg0KPiA+DQo+ID4gICAg RmluYWxseSwgdGhlcmUgaXMgYW4gb2JqZWN0ICJzZXJ2ZXItcHJvdmlkZWQiLiAgVGhpcyBvYmpl Y3QgaXMgc3RhdGUNCj4gPg0KPiA+ICAgIHRoYXQgaW5kaWNhdGVzIGhvdyB0aGUgbmV0d29yayBj YW1lIGludG8gYmVpbmcuICBOZXR3b3JrIGRhdGEgY2FuDQo+ID4NCj4gPiAgICBjb21lIGludG8g YmVpbmcgaW4gb25lIG9mIHR3byB3YXlzLiAgSW4gb25lIHdheSwgbmV0d29yayBkYXRhIGlzDQo+ ID4NCj4gPiAgICBjb25maWd1cmVkIGJ5IGNsaWVudCBhcHBsaWNhdGlvbnMsIGZvciBleGFtcGxl IGluIGNhc2Ugb2Ygb3ZlcmxheQ0KPiA+DQo+ID4gICAgbmV0d29ya3MgdGhhdCBhcmUgY29uZmln dXJlZCBieSBhbiBTRE4gQ29udHJvbGxlciBhcHBsaWNhdGlvbi4gIEluDQo+ID4NCj4gPiAgICBh bm5vdGhlciB3YXksIGl0IGlzIHBvcHVsYXRlZCBieSB0aGUgc2VydmVyLCBpbiBjYXNlIG9mIG5l dHdvcmtzIHRoYXQNCj4gPg0KPiA+ICAgIGNhbiBiZSBkaXNjb3ZlcmVkLg0KPiA+DQo+ID4NCj4g Pg0KPiA+ICAgIElmIHNlcnZlci1wcm92aWRlZCBpcyBzZXQgdG8gZmFsc2UsIHRoZSBuZXR3b3Jr IHdhcyBjb25maWd1cmVkIGJ5IGENCj4gPg0KPiA+ICAgIGNsaWVudCBhcHBsaWNhdGlvbiwgZm9y IGV4YW1wbGUgaW4gdGhlIGNhc2Ugb2YgYW4gb3ZlcmxheSBuZXR3b3JrDQo+ID4NCj4gPiAgICB0 aGF0IGlzIGNvbmZpZ3VyZWQgYnkgYSBjb250cm9sbGVyIGFwcGxpY2F0aW9uLiAgSWYgc2VydmVy LXByb3ZpZGVkDQo+ID4NCj4gPiAgICBpcyBzZXQgdG8gdHJ1ZSwgdGhlIG5ldHdvcmsgd2FzIHBv cHVsYXRlZCBieSB0aGUgc2VydmVyIGl0c2VsZiwNCj4gPg0KPiA+ICAgIHJlc3BlY3RpdmVseSBh biBhcHBsaWNhdGlvbiBvbiB0aGUgc2VydmVyIHRoYXQgaXMgYWJsZSB0byBkaXNjb3Zlcg0KPiA+ DQo+ID4gICAgdGhlIG5ldHdvcmsuICAqQ2xpZW50IGFwcGxpY2F0aW9ucyBTSE9VTEQgTk9UIG1v ZGlmeSBjb25maWd1cmF0aW9ucyBvZioNCj4gPg0KPiA+ICogICBuZXR3b3JrcyBmb3Igd2hpY2gg InNlcnZlci1wcm92aWRlZCIgaXMgdHJ1ZS4qICBXaGVuIHRoZXkgZG8sIHRoZXkNCj4gPg0KPiA+ ICAgIG5lZWQgdG8gYmUgYXdhcmUgdGhhdCBhbnkgbW9kaWZpY2F0aW9ucyB0aGV5IG1ha2UgYXJl IHN1YmplY3QgdG8gYmUNCj4gPg0KPiA+ICAgIHJldmVydGVkIGJ5IHRoZSBzZXJ2ZXIuICBGb3Ig c2VydmVycyB0aGF0IHN1cHBvcnQgTkFDTSAoTmV0Y29uZg0KPiA+DQo+ID4gICAgQWNjZXNzIENv bnRyb2wgTW9kZWwpLCAqZGF0YSBub2RlIHJ1bGVzIHNob3VsZCBpZGVhbGx5IHByZXZlbnQqIHdy aXRlDQo+ID4NCj4gPiAgICBhY2Nlc3MgYnkgb3RoZXIgY2xpZW50cyB0byBuZXR3b3JrIGluc3Rh bmNlcyBmb3Igd2hpY2ggc2VydmVyLQ0KPiA+DQo+ID4gICAgcHJvdmlkZWQgaXMgc2V0IHRvIHRy dWUuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIFNIT1VMRCBOT1QgYWJvdmUgaXMgcmVhbGx5IG9k ZCwgY29uc2lkZXJpbmcgaXMgbm90IHN1cHBvcnRlZCBieSBZQU5HDQo+ID4NCj4gPiBvciB0aGUg TkMvUkMgcHJvdG9jb2xzLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICJkYXRhIG5vZGUgcnVsZXMgc2hv dWxkIGlkZWFsbHkgcHJldmVudCINCj4gPg0KPiA+DQo+ID4NCj4gPiBzL3Nob3VsZC9TSE9VTEQv DQo+ID4NCj4gPg0KPiA+DQo+ID4gSWRlYWxseSBwcmV2ZW50Pw0KPiA+DQo+ID4gSXMgdGhhdCBh IG5ldyBlbmdpbmVlcmluZyB0ZXJtPw0KPiA+DQo+ID4gRWl0aGVyIHRoaXMgbmV3IHVzYWdlIG9m IE5BQ00gd29ya3Mgb3IgaXQgZG9lc24ndC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBbHNvLCB0aGVy ZSBpcyBubyBndWlkYW5jZSBvciBleGFtcGxlcyBvZiB0aGUgTkFDTSBjb25maWcgdGhhdCB0aGUN Cj4gPg0KPiA+IHNlcnZlciBpcyBzdXBwb3NlZCB0byBtYWdpY2FsbHkgY3JlYXRlIGZvciBzZXJ2 ZXItcHJvdmlkZWQgdG9wb2xvZ3kgZGF0YS4NCj4gPg0KPiA+IFRoZXJlIGlzIG5vdGhpbmcgaW4g TkFDTSBhdCBhbGwgYWJvdXQgc2VydmVyLWNyZWF0ZWQgZGF0YSBydWxlcy4NCj4gPg0KPiA+IFRo aXMgaXMgbm90IHN1cHBvcnRlZCBieSBOQUNNLg0KPiA+DQo+ID4NCj4gPg0KPiA+IERvZXMgdGhl IEkyUlMgdGV4dCBpbXBseSB0aGF0IHRoZSBzZXJ2ZXItcHJvdmlkZWQgcHJvcGVydHkgZXh0ZW5k cw0KPiA+DQo+ID4gdG8gdGhlIE5BQ00gc3ViLXRyZWVzPyBUaGV5IGFyZSBhbHNvIHN1YmplY3Qg dG8gcmVwbGFjZW1lbnQgYnkgdGhlIHNlcnZlcj8NCj4gPg0KPiA+IFRoZSBjbGllbnQgU0hPVUxE IE5PVCBjaGFuZ2UgdGhlc2UgTkFDTSBydWxlcz8NCj4gPg0KPiA+DQo+ID4NCj4gPiBJTU8gdGhl IHdheSB0aGlzIHNlcnZlci1wcm92aWRlZCBwcm9wZXJ0eSBpcyBiZWluZyBkb25lIGlzIGEgc2hv cnQtc2lnaHRlZA0KPiA+DQo+ID4gcG9pbnQgc29sdXRpb24sIGJ1dCB0aGlzIHNob3VsZCBiZSBh IGZ1bmRhbWVudGFsIHBhcnQgb2YgdGhlIHJldmlzZWQNCj4gPiBkYXRhc3RvcmVzIHdvcmsuDQo+ ID4NCj4gPiBJcyB0aGVyZSBzb21ldGhpbmcgc3BlY2lhbCBhYm91dCBuZXR3b3JrIHRvcG9sb2d5 IHN1Y2ggdGhhdA0KPiA+DQo+ID4gc2VydmVyLXByb3ZpZGVkIGRhdGEgZm9yIGEgZGlmZmVyZW50 IG1vZHVsZSB3aWxsIHJlcXVpcmUgYSBkaWZmZXJlbnQNCj4gPg0KPiA+IHNvbHV0aW9uPyBJZiBu b3QsIGlzIHRoZSB0b3BvIG1vZHVsZSBzb2x1dGlvbiByZXVzYWJsZT8NCj4gPg0KPiA+DQo+ID4N Cj4gPg0KPiA+DQo+ID4gQW5keQ0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo= From nobody Thu Feb 16 13:16:34 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CC51296B1 for ; Thu, 16 Feb 2017 13:16:32 -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, 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 9IJOd7V8g7L6 for ; Thu, 16 Feb 2017 13:16:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 26996129426 for ; Thu, 16 Feb 2017 13:16:31 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 59A421AE033A; Thu, 16 Feb 2017 22:16:30 +0100 (CET) Date: Thu, 16 Feb 2017 22:16:30 +0100 (CET) Message-Id: <20170216.221630.1932559842832143485.mbj@tail-f.com> To: xufeng.liu.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <007501d28869$e81639c0$b842ad40$@gmail.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80493@SJCEML703-CHM.china.huawei.com> <20170215.194126.118198588680956999.mbj@tail-f.com> <007501d28869$e81639c0$b842ad40$@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, kwatsen@juniper.net, alexander.clemm@huawei.com Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:16:33 -0000 "Xufeng Liu" wrote: > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > > Sent: Wednesday, February 15, 2017 1:41 PM > > To: alexander.clemm@huawei.com > > Cc: i2rs@ietf.org; kwatsen@juniper.net > > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > > > Alexander Clemm wrote: > > > Hello Martin, > > > Thank you. Your first explanation is clear. Regarding the expression > > > of constraints, see inline, below (thread is pruned for clarity) > > > --- Alex > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Wednesday, February 15, 2017 12:12 AM > > > To: Alexander Clemm > > > Cc: kwatsen@juniper.net; i2rs@ietf.org > > > Subject: Re: [i2rs] modeling options for > > > draft-ietf-i2rs-yang-network-topo > > > > > > > > > > > > ................. > > > I mean that the server will consider a configured item, and decide if > > > it can be used or not. If the configured item has a reference to > > > something that doesn't (yet) exist (weak reference; require-instance > > > false), the server leaves the item in the config, and moves on. At > > > some later time, suppose the weak reference is fulfilled; at this > > > point the server decides that the configured item can be used, and it > > > instantiates the item in the /-state list. Once it is there, maybe > > > some other configured item has a reference to this one, and it can > > > also be instantiated etc. > > > > > > And it goes the other way as well; suppose a server provided item is > > > removed by the server; at this point the server would also remove > > > items in the state list that originated in the configuration - however > > > they are not removed from the config, just the state. > > > (Server provided items would only show up in the state in this > > > solution). > > > > > > The state subtree works exactly like the operational-state datastore > > > in draft-ietf-netmod-revised-datastores. > > > > > > > > > Thank you, this clarifies the earlier statement > > > > > > > One of the issues that we are facing is that a configured topology > > > > might refer to a configured topology or a server-provided topology, > > > > and we would like to avoid making a case distinction as to which > > > > category we are referring to. > > > > > > I believe my proposed solution handles this. > > > > > > > At the same time, we are making use of leafrefs to express a number > > > > of integrity constraints which are part of the model: as a node is > > > > part of a topology, and a topology has an underlay topology, we make > > > > sure that the underlay node is part of the underlay topology (and > > > > not just any arbitrary node). > > > > > > Can you point me to the place in the model where this is specified? > > > > > > Or did you mean that today you have to mention this in plain text, but > > > it would be nice if it could be captured formally in the model? > > > > > > It is covered in the model today. E.g.: > > > > Ok. Here the model uses require-instance false, so if these ponts to the > state > > tree instead, you'd get the same effect. > > > > [Xufeng] Does the leafref point to the "state tree" only? If we do so, we > will miss the other half - the possible dependency to the config tree. If we > let the leafref point to both, we will get the unmanageable complications. The idea was that the leafref would point to state only. You will not really miss the dependency to the config tree; see my description above. /martin > > > > > /martin > > > > > > > > > > In networks/network/node/supporting-node > > > leaf network-ref { > > > type leafref { > > > path "../../../supporting-network/network-ref"; > > > require-instance false; > > > } > > > (supporting node is contained in supporting network) > > > > > > Supporting link: > > > +--rw supporting-link* [network-ref link-ref] > > > +--rw network-ref -> > ../../../nd:supporting-network/network-ref > > > +--rw link-ref -> > > > > > > /nd:networks/network[nd:network-id=current()/../network-ref]/link/link > > > -id > > > > > > (supporting link is a link contained in the supporting network) > > > > > > Supporting termination point: > > > +--rw supporting-termination-point* [network-ref node-ref tp-ref] > > > +--rw network-ref -> ../../../nd:supporting-node/network-ref > > > +--rw node-ref -> ../../../nd:supporting-node/node-ref > > > +--rw tp-ref -> > > > > > > /nd:networks/network[nd:network-id=current()/../network-ref]/node[nd:n > > > ode-id=current()/../node-ref]/termination-point/tp-id > > > > > > (supporting termination point is contained in supporting network and > > > supporting node) > > > > > > It is those leafrefs whose transposition in the split subtree model > > > (where we encounter alternative paths) I am concerned will be > > > problematic. > > > > > > > > > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Feb 16 13:16:53 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598F41296B1 for ; Thu, 16 Feb 2017 13:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xVXtgXi0ibK for ; Thu, 16 Feb 2017 13:16:50 -0800 (PST) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A961296CB for ; Thu, 16 Feb 2017 13:16:43 -0800 (PST) Received: by mail-lf0-x244.google.com with SMTP id q89so2398954lfi.1 for ; Thu, 16 Feb 2017 13:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=TU7mZPSR9RJV01t+bw/8cQuABiHIAiUM6buNOgcwpyY=; b=kA3APcApk7rAYkTnYnn2AHqOwpwLT3q2S1aFSc9jqE2f9Q4fgK3V01S0Yn6UOnZjO/ npk18D+DFnGh9avPahaNlgebaYIzHBC8nBcisfhf0N9/mU0Hq5Nkkvfhi4Rhn/tBSqzX gYf1xIJTeXdKutWbsh/5riHn0MqWCC+dZMW0Qcli0NztXButmRpe1RnqclC+1yLWnl5l e6t8ouid/NBV0VOimakcEnfdWj3GdYAo3kylqv8E24e7QXy1oxthR3QHv0IGatJrAwGU stRNqw06Vr285Cnhmu++YvwowABIi59ZTShtirCaCwttwqEzMiZWMW/RES/jmcHahq+R KhxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=TU7mZPSR9RJV01t+bw/8cQuABiHIAiUM6buNOgcwpyY=; b=DAVIuvXx0K4Y/rElUVXdSDkpOkUp6xA7VRetHAeMSaCuAIRwiTaP2Ig2N9QfF3alm3 KIJeu8mW8T95C1SL4taU6PkCogEX8AT0StsIcTKQcxw6QRiMJFwoe5C8eH53AudQt+9c wiO7HfJd+deQ9rB7l+pWS8/4WUqZBaZq3skwSJ3Z32irLmi9bI4eRMljdi8IA44QTLee jZM1nHs37q9oqNDIkiaueTVq7WKSviUeg9jIV15Sk2YbCZPrDn84tBBTk7wqR2I4B7r2 zdaZpYhF0MuVowzwtUYBbwQAQqhG6xvBlPDCWzAjjokfUN+k9ASh5sgR2CfDNp6/NS+n 4QPA== X-Gm-Message-State: AMke39lAJa/1DBpNsgIWkzGnesjgw2N/m7AaUH6t5+tanFIxPPFnURgqGBVqNteO7biYGg== X-Received: by 10.46.20.4 with SMTP id u4mr1130967ljd.89.1487279802175; Thu, 16 Feb 2017 13:16:42 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id v2sm1970856ljb.22.2017.02.16.13.16.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 13:16:41 -0800 (PST) From: "Xufeng Liu" To: "'Susan Hares'" , "'Martin Bjorklund'" , References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <050901d28887$25a887d0$70f99770$@ndzh.com> <00bd01d2888d$9fe53290$dfaf97b0$@gmail.com> <055801d2888e$50276ba0$f07642e0$@ndzh.com> In-Reply-To: <055801d2888e$50276ba0$f07642e0$@ndzh.com> Date: Thu, 16 Feb 2017 16:16:38 -0500 Message-ID: <00e801d28899$f7b231b0$e7169510$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQx8r72RrckYMhXWnaB0v1b2P4ZAEWoFNQAqHHXJ0B1BTo7AGVrx3gAjEJjgcB0cJWuwIlsb4Dn4VKLjA= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:16:52 -0000 Hi Sue, I agree that the revised data stores solutions is the long term solution, but it may take a year to complete because it covers a much broader scope. Are we ok with delaying all these models for another year? This could be the decision of the Chairs and ADs. Also, this approach seems to be a sub-set of the long term solution, and they are compatible. If the details can be worked out, it would be good to have such an interim solution immediately, which does not need to solve all the problems, but hopefully can migrate to the long term solution smoothly. Thanks, - Xufeng > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, February 16, 2017 2:53 PM > To: 'Xufeng Liu' ; 'Martin Bjorklund' f.com>; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: RE: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > Xufeng: > > I suspect 2 rpcs will be needed, but Martin and Kent are the experts. Do > you think trying to accelerate the revised data stores solutions is a better way to > go? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > Sent: Thursday, February 16, 2017 2:48 PM > To: 'Susan Hares'; 'Martin Bjorklund'; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > Hi Sue, > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, February 16, 2017 2:02 PM > > To: 'Xufeng Liu' ; 'Martin Bjorklund' > > f.com>; kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: RE: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > To Xufeng: > > > > Clarifying question - Are you asking about I2RS topology as a generic > > yang model for any configuration or are you asking about I2RS topology > > model as > an > > ephemeral topology model. > > [Xufeng] I was talking about I2RS topology as a generic yang model for any > configuration, but I think that the same solution can be applied to ephemeral > case, though a separate rpc might be needed. > > Thanks, > - Xufeng > > > > > To Martin: > > Clarifying questions: > > > > 1) Is your rpc suggest target toward the I2RS topology model as a > > generic topology model or an I2RS ephemeral state model or both? > > > > 2) Could we define rpcs now that operate as Alex desired for generic > topology > > models that could be replaced by more generic mechanisms later? > > For example, the I2RS RIB has defined rpcs for all major functions > (add/delete rib, > > add/delete route, add/delete nexhop) plus notifications for changes. > > Is > this the > > best approach here? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > > Sent: Thursday, February 16, 2017 10:39 AM > > To: 'Martin Bjorklund'; kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > > > Bjorklund > > > Sent: Tuesday, February 14, 2017 11:41 AM > > > To: kwatsen@juniper.net > > > Cc: i2rs@ietf.org > > > Subject: Re: [i2rs] modeling options for > > > draft-ietf-i2rs-yang-network-topo > > > > > > Kent Watsen wrote: > > > > > > > > > > > > [moving yang-doctors to BCC] > > > > > > > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > > > >> -------------------------------------------- > > > > >> > > > > >> This option was/is described here: > > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > > > >> > > > > >> PROS: > > > > >> a) does NOT break legacy clients (how we got here) > > > > >> b) consistent with convention used in many IETF modules > > > > >> c) able to show if/how opstate may differ from configured > > > > >> values > > > > >> > > > > >> CONS: > > > > >> a) questionably valid YANG leafref usage > > > > > > > > > > What does this mean? > > > > > > > > I'm referring to how the description statement explains that the > > > > server may look to operational state in order to resolve the > > > > leafref, which is to result in behavior similar to > > > > pre-configuration in RFC 7223. > > > > > > Ok, I didn't pay close attention to the proposal in the quoted email. > > > > > > I would design this a bit differently. The config true leaf > "dependency" > > should > > > have a leafref to the config false node name, with require-instance > false. > > The > > > description should explain that the configuration item will be used > > > by the > > server > > > if all dependencies exist. When the configuration item is used, it > > > shows > > up in the > > > config false list. > > > > > > This way, the leafref usage is valid and straight forward. > > > > > > > >> b) complex server implementation (to handle require-instance > > > > >> false) > > > > > > > > > >Can you elaborate on this one? > > > > > > > > This is primarily a reflection of the CON listed above, in that it > > > > seems that a server would need to have special handling for when > > > > dependencies transition from being present to not-present and vice > > > > versa, much like the code to handle when a physical card is > > > > plugged in or removed. > > > > > > Yes, but I think this is inherent to the problem at hand. Even with > > > the > > config true > > > solution defined in the current draft, it is not clear how things > > > that > > were created > > > by the server would be deleted (if there were references to them). > > > > > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > > > >> solution, which would result in needing to also rewrite all > > > > >> modules that have augmented it (e.g., ietf-te-topology). > > > > >> d) leafref path expressions really only work for > > > > >> configuration > > data, > > > > >> though a clever server could have a special ability to peak at > > > > >> the opstate values when doing validations. Of course, with > > > > >> require-instance is false, the value of leafref based > validation > > > > >> checking is negated anyway, even for config true nodes, so > this > > > > >> may not matter much. > > > > >> > > > > >> > > > > >> > > > > >> OPTION 2: explicit client-option to also return tagged opstate > > > > >> data > > > > >> --------------------------------------------------------------- > > > > >> -- > > > > >> -- > > > > >> > > > > >> This option takes a couple forms. The first is module-specific > > > > >> and the second is generic. In both cases, the idea is modeled > > > > >> after the with-defaults solution (RFC6243), wherein the client > > > > >> passes a special flag into causing the server to > > > > >> also return opstate data, having a special metadata flag set, > > > > >> intermingled with the configuration data. > > > > >> > > > > >> > > > > >> 2A: Module-specific version > > > > >> > > > > >> module foo { > > > > >> import ietf-netconf { prefix nc; } > > > > >> import ietf-yang-metadata { prefix md; } > > > > >> md:annotation server-provided { > > > > >> type boolean; > > > > >> } > > > > >> container nodes { > > > > >> config true; > > > > >> list node { > > > > >> key "name"; > > > > >> leaf name { type string; } > > > > >> leaf dependency { > > > > >> type leafref { > > > > >> path "../node/name" > > > > >> require-instance false; > > > > >> } > > > > >> } > > > > >> } > > > > >> } > > > > >> augment /nc:get-config/nc:input { > > > > >> leaf with-server-provided { > > > > >> type boolean; > > > > >> } > > > > >> } > > > > >> } > > > > > > > > > > I don't think this solution is substantially different from the > > > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > > > moved a config false leaf to a meta-data annotation. This > > > > > solution suffers from the same problems as the solution in > > > > > draft-ietf-i2rs-yang-network-topo-10. > > > > > > > > There are two primary differences: > > > > > > > > 1) It doesn't break legacy clients > > > > > > The solution in the draft doesn't break legacy clients either - > > > there's a > > config > > > false leaf among the config true. No problem. > > > > > > > , because it requires the client to > > > > explicitly pass a 'with-server-provided' flag in the > > > > request in order to get back the extended response. Likewise, it > > > > doesn't break backup/restore workflows, as the server can discard > > > > any 'server-provided' nodes passed in an operation. > > > > > > Huh? This goes against the defined behavior of 6241 + 7950. This > > > is the > > main > > > problem with the solution in the current draft. > > > > > > If a client sends a for data in running, the server > > > cannot > > send back > > > data that is not in running. > > > > > > > Lastly, it doesn't break /, as there is no comingling > > > > of opstate data in the 'running' datastore. > > > > > > > > 2) It doesn't say anything about how the opstate data is stored on the > > > > server. The opstate data is not modeled at all. This approach > > > > only defines a presentation-layer format for how opstate data can > > > > be returned via an RPC. The server is free to persist the opstate > > > > data anyway it wants, perhaps in an internal datastore called > > > > 'operational-state' or in an uber-datastore with the opstate data > > > > flagged with a datastore='oper-state' attribute. Regardless, it's > > > > an implementation detail, and the conceptual datastore model is > > > > preserved. > > > > > > You are essentially defining a new operation, but do it by modifying > > > the semantics of an existing one. I don't think this is a good > > > idea; it is > > better to > > > define a new rpc. > > > > [Xufeng] Is using a new rpc is acceptable? If so, this could be a > > viable > option. > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 13:18:58 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E29129470 for ; Thu, 16 Feb 2017 13:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-E-MupZgAyF for ; Thu, 16 Feb 2017 13:18:54 -0800 (PST) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0068C1296C1 for ; Thu, 16 Feb 2017 13:18:53 -0800 (PST) Received: by mail-lf0-x241.google.com with SMTP id q89so2402607lfi.1 for ; Thu, 16 Feb 2017 13:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=9JhjmE1JWUTJpO6Zzd95g41Cyaq7Lgbt5Zc9SwPWLHA=; b=D8pUc8Ti855BBEICS0RotYscS4RJbXVVmxdFmHw9xICmOFF0PmbWPpuWDpgwgB3uIm Og5pAxwBYdJoCaPq9NWSat2+WSKD2tilqD1hiTzXA49dp2savD8YXKFpM0P2rohCIQRM y/jmOdNnZfWMyw7j4sJSbpmdrfFKoi6amQd5Bg6PpSQzq/9khVKlmTsYYhPP3VnVX+As 4LqhEEX8rgT3r1TUsR1wRB9mSU+TaAtAc8Rk3jYVhn6Ue5+6zm9e6K5FampKPCjHflVr SGjupOjHbRlIihBiKfYT3XMBZtaON6hupOtF1zGdcYQZ0oei20T0eZlkn/xbffMFTLgs EKeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=9JhjmE1JWUTJpO6Zzd95g41Cyaq7Lgbt5Zc9SwPWLHA=; b=ipkoSQo2leR/bMfY8ZwW7RRaGL4RHXdcWgxThPba37ASai1WDA0rIfHWqYyWOpLglq vb/bU9j0DCMcAIvzML/j93Ya72SgDKoAHPI997w5qWd8Eq2FeZzkDnnKio0M+8GmNX/o fJFdUOYOHvY+PgiDevUaNxLxSSMctzTRLpyBqX1ic5uPhw+2Q/MqDFi/b1k8OnfaW60f G8912PCX6liboC4YqKu3xRRgoUp5ruJadtbwQ33KqaxCgM4OGDTrp4kiGtzIaMBMHND7 ZRuRTkdA0cCGfczzjIA+nha5kS8E2BIefDXRbdjxj9ZYEK07Z7geiu1BHMG0r42HxXh0 wFgQ== X-Gm-Message-State: AMke39mjHgj77OaA1JMI3bsKuO9507dJpXh1A2YdGgLvDnGobGlv24ZYNq9ayIhooTkiaQ== X-Received: by 10.46.80.29 with SMTP id e29mr1194416ljb.125.1487279932205; Thu, 16 Feb 2017 13:18:52 -0800 (PST) Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id h9sm1991065ljb.51.2017.02.16.13.18.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 13:18:51 -0800 (PST) From: "Xufeng Liu" To: "'Susan Hares'" , "'Martin Bjorklund'" , References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <050901d28887$25a887d0$70f99770$@ndzh.com> <00bd01d2888d$9fe53290$dfaf97b0$@gmail.com> <055801d2888e$50276ba0$f07642e0$@ndzh.com> In-Reply-To: <055801d2888e$50276ba0$f07642e0$@ndzh.com> Date: Thu, 16 Feb 2017 16:18:49 -0500 Message-ID: <00e901d2889a$453d92d0$cfb8b870$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKQx8r72RrckYMhXWnaB0v1b2P4ZAEWoFNQAqHHXJ0B1BTo7AGVrx3gAjEJjgcB0cJWuwIlsb4DAsHPjyo= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:18:56 -0000 Hi Sue, I agree that the revised data stores solutions is the long term solution, but it may take a year to complete because it covers a much broader scope. Are we ok with delaying all these models for another year? This could be the decision of the Chairs and ADs. Also, this approach seems to be a sub-set of the long term solution, and they are compatible. If the details can be worked out, it would be good to have such an interim solution immediately, which does not need to solve all the problems, but hopefully can migrate to the long term solution smoothly. > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, February 16, 2017 2:53 PM > To: 'Xufeng Liu' ; 'Martin Bjorklund' f.com>; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: RE: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > Xufeng: > > I suspect 2 rpcs will be needed, but Martin and Kent are the experts. Do > you think trying to accelerate the revised data stores solutions is a better way to > go? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > Sent: Thursday, February 16, 2017 2:48 PM > To: 'Susan Hares'; 'Martin Bjorklund'; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > Hi Sue, > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, February 16, 2017 2:02 PM > > To: 'Xufeng Liu' ; 'Martin Bjorklund' > > f.com>; kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: RE: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > To Xufeng: > > > > Clarifying question - Are you asking about I2RS topology as a generic > > yang model for any configuration or are you asking about I2RS topology > > model as > an > > ephemeral topology model. > > [Xufeng] I was talking about I2RS topology as a generic yang model for any > configuration, but I think that the same solution can be applied to ephemeral > case, though a separate rpc might be needed. > > Thanks, > - Xufeng > > > > > To Martin: > > Clarifying questions: > > > > 1) Is your rpc suggest target toward the I2RS topology model as a > > generic topology model or an I2RS ephemeral state model or both? > > > > 2) Could we define rpcs now that operate as Alex desired for generic > topology > > models that could be replaced by more generic mechanisms later? > > For example, the I2RS RIB has defined rpcs for all major functions > (add/delete rib, > > add/delete route, add/delete nexhop) plus notifications for changes. > > Is > this the > > best approach here? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > > Sent: Thursday, February 16, 2017 10:39 AM > > To: 'Martin Bjorklund'; kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > > > Bjorklund > > > Sent: Tuesday, February 14, 2017 11:41 AM > > > To: kwatsen@juniper.net > > > Cc: i2rs@ietf.org > > > Subject: Re: [i2rs] modeling options for > > > draft-ietf-i2rs-yang-network-topo > > > > > > Kent Watsen wrote: > > > > > > > > > > > > [moving yang-doctors to BCC] > > > > > > > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > > > >> -------------------------------------------- > > > > >> > > > > >> This option was/is described here: > > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > > > >> > > > > >> PROS: > > > > >> a) does NOT break legacy clients (how we got here) > > > > >> b) consistent with convention used in many IETF modules > > > > >> c) able to show if/how opstate may differ from configured > > > > >> values > > > > >> > > > > >> CONS: > > > > >> a) questionably valid YANG leafref usage > > > > > > > > > > What does this mean? > > > > > > > > I'm referring to how the description statement explains that the > > > > server may look to operational state in order to resolve the > > > > leafref, which is to result in behavior similar to > > > > pre-configuration in RFC 7223. > > > > > > Ok, I didn't pay close attention to the proposal in the quoted email. > > > > > > I would design this a bit differently. The config true leaf > "dependency" > > should > > > have a leafref to the config false node name, with require-instance > false. > > The > > > description should explain that the configuration item will be used > > > by the > > server > > > if all dependencies exist. When the configuration item is used, it > > > shows > > up in the > > > config false list. > > > > > > This way, the leafref usage is valid and straight forward. > > > > > > > >> b) complex server implementation (to handle require-instance > > > > >> false) > > > > > > > > > >Can you elaborate on this one? > > > > > > > > This is primarily a reflection of the CON listed above, in that it > > > > seems that a server would need to have special handling for when > > > > dependencies transition from being present to not-present and vice > > > > versa, much like the code to handle when a physical card is > > > > plugged in or removed. > > > > > > Yes, but I think this is inherent to the problem at hand. Even with > > > the > > config true > > > solution defined in the current draft, it is not clear how things > > > that > > were created > > > by the server would be deleted (if there were references to them). > > > > > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > > > >> solution, which would result in needing to also rewrite all > > > > >> modules that have augmented it (e.g., ietf-te-topology). > > > > >> d) leafref path expressions really only work for > > > > >> configuration > > data, > > > > >> though a clever server could have a special ability to peak at > > > > >> the opstate values when doing validations. Of course, with > > > > >> require-instance is false, the value of leafref based > validation > > > > >> checking is negated anyway, even for config true nodes, so > this > > > > >> may not matter much. > > > > >> > > > > >> > > > > >> > > > > >> OPTION 2: explicit client-option to also return tagged opstate > > > > >> data > > > > >> --------------------------------------------------------------- > > > > >> -- > > > > >> -- > > > > >> > > > > >> This option takes a couple forms. The first is module-specific > > > > >> and the second is generic. In both cases, the idea is modeled > > > > >> after the with-defaults solution (RFC6243), wherein the client > > > > >> passes a special flag into causing the server to > > > > >> also return opstate data, having a special metadata flag set, > > > > >> intermingled with the configuration data. > > > > >> > > > > >> > > > > >> 2A: Module-specific version > > > > >> > > > > >> module foo { > > > > >> import ietf-netconf { prefix nc; } > > > > >> import ietf-yang-metadata { prefix md; } > > > > >> md:annotation server-provided { > > > > >> type boolean; > > > > >> } > > > > >> container nodes { > > > > >> config true; > > > > >> list node { > > > > >> key "name"; > > > > >> leaf name { type string; } > > > > >> leaf dependency { > > > > >> type leafref { > > > > >> path "../node/name" > > > > >> require-instance false; > > > > >> } > > > > >> } > > > > >> } > > > > >> } > > > > >> augment /nc:get-config/nc:input { > > > > >> leaf with-server-provided { > > > > >> type boolean; > > > > >> } > > > > >> } > > > > >> } > > > > > > > > > > I don't think this solution is substantially different from the > > > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > > > moved a config false leaf to a meta-data annotation. This > > > > > solution suffers from the same problems as the solution in > > > > > draft-ietf-i2rs-yang-network-topo-10. > > > > > > > > There are two primary differences: > > > > > > > > 1) It doesn't break legacy clients > > > > > > The solution in the draft doesn't break legacy clients either - > > > there's a > > config > > > false leaf among the config true. No problem. > > > > > > > , because it requires the client to > > > > explicitly pass a 'with-server-provided' flag in the > > > > request in order to get back the extended response. Likewise, it > > > > doesn't break backup/restore workflows, as the server can discard > > > > any 'server-provided' nodes passed in an operation. > > > > > > Huh? This goes against the defined behavior of 6241 + 7950. This > > > is the > > main > > > problem with the solution in the current draft. > > > > > > If a client sends a for data in running, the server > > > cannot > > send back > > > data that is not in running. > > > > > > > Lastly, it doesn't break /, as there is no comingling > > > > of opstate data in the 'running' datastore. > > > > > > > > 2) It doesn't say anything about how the opstate data is stored on the > > > > server. The opstate data is not modeled at all. This approach > > > > only defines a presentation-layer format for how opstate data can > > > > be returned via an RPC. The server is free to persist the opstate > > > > data anyway it wants, perhaps in an internal datastore called > > > > 'operational-state' or in an uber-datastore with the opstate data > > > > flagged with a datastore='oper-state' attribute. Regardless, it's > > > > an implementation detail, and the conceptual datastore model is > > > > preserved. > > > > > > You are essentially defining a new operation, but do it by modifying > > > the semantics of an existing one. I don't think this is a good > > > idea; it is > > better to > > > define a new rpc. > > > > [Xufeng] Is using a new rpc is acceptable? If so, this could be a > > viable > option. > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 16 13:19:53 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC059129470 for ; Thu, 16 Feb 2017 13:19:51 -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, 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 QzwP3ZdqgwQE for ; Thu, 16 Feb 2017 13:19:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E636129426 for ; Thu, 16 Feb 2017 13:19:50 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B30E1AE033A; Thu, 16 Feb 2017 22:19:49 +0100 (CET) Date: Thu, 16 Feb 2017 22:19:49 +0100 (CET) Message-Id: <20170216.221949.1797970554181706414.mbj@tail-f.com> To: xufeng.liu.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <007601d2886a$bf085170$3d18f450$@gmail.com> References: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, kwatsen@juniper.net Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:19:52 -0000 "Xufeng Liu" wrote: > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > > Sent: Tuesday, February 14, 2017 11:41 AM > > To: kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo > > > > Kent Watsen wrote: > > > > > > > > > [moving yang-doctors to BCC] > > > > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > > >> -------------------------------------------- > > > >> > > > >> This option was/is described here: > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > > >> > > > >> PROS: > > > >> a) does NOT break legacy clients (how we got here) > > > >> b) consistent with convention used in many IETF modules > > > >> c) able to show if/how opstate may differ from configured values > > > >> > > > >> CONS: > > > >> a) questionably valid YANG leafref usage > > > > > > > > What does this mean? > > > > > > I'm referring to how the description statement explains that the > > > server may look to operational state in order to resolve the leafref, > > > which is to result in behavior similar to pre-configuration in RFC > > > 7223. > > > > Ok, I didn't pay close attention to the proposal in the quoted email. > > > > I would design this a bit differently. The config true leaf "dependency" > should > > have a leafref to the config false node name, with require-instance false. > The > > description should explain that the configuration item will be used by the > server > > if all dependencies exist. When the configuration item is used, it shows > up in the > > config false list. > > > > This way, the leafref usage is valid and straight forward. > > > > > >> b) complex server implementation (to handle require-instance > > > >> false) > > > > > > > >Can you elaborate on this one? > > > > > > This is primarily a reflection of the CON listed above, in that it > > > seems that a server would need to have special handling for when > > > dependencies transition from being present to not-present and vice > > > versa, much like the code to handle when a physical card is plugged in > > > or removed. > > > > Yes, but I think this is inherent to the problem at hand. Even with the > config true > > solution defined in the current draft, it is not clear how things that > were created > > by the server would be deleted (if there were references to them). > > > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > > >> solution, which would result in needing to also rewrite all > > > >> modules that have augmented it (e.g., ietf-te-topology). > > > >> d) leafref path expressions really only work for configuration > data, > > > >> though a clever server could have a special ability to peak at > > > >> the opstate values when doing validations. Of course, with > > > >> require-instance is false, the value of leafref based validation > > > >> checking is negated anyway, even for config true nodes, so this > > > >> may not matter much. > > > >> > > > >> > > > >> > > > >> OPTION 2: explicit client-option to also return tagged opstate data > > > >> ------------------------------------------------------------------- > > > >> > > > >> This option takes a couple forms. The first is module-specific and > > > >> the second is generic. In both cases, the idea is modeled after > > > >> the with-defaults solution (RFC6243), wherein the client passes a > > > >> special flag into causing the server to also return > > > >> opstate data, having a special metadata flag set, intermingled with > > > >> the configuration data. > > > >> > > > >> > > > >> 2A: Module-specific version > > > >> > > > >> module foo { > > > >> import ietf-netconf { prefix nc; } > > > >> import ietf-yang-metadata { prefix md; } > > > >> md:annotation server-provided { > > > >> type boolean; > > > >> } > > > >> container nodes { > > > >> config true; > > > >> list node { > > > >> key "name"; > > > >> leaf name { type string; } > > > >> leaf dependency { > > > >> type leafref { > > > >> path "../node/name" > > > >> require-instance false; > > > >> } > > > >> } > > > >> } > > > >> } > > > >> augment /nc:get-config/nc:input { > > > >> leaf with-server-provided { > > > >> type boolean; > > > >> } > > > >> } > > > >> } > > > > > > > > I don't think this solution is substantially different from the > > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > > moved a config false leaf to a meta-data annotation. This solution > > > > suffers from the same problems as the solution in > > > > draft-ietf-i2rs-yang-network-topo-10. > > > > > > There are two primary differences: > > > > > > 1) It doesn't break legacy clients > > > > The solution in the draft doesn't break legacy clients either - there's a > config > > false leaf among the config true. No problem. > > > > > , because it requires the client to > > > explicitly pass a 'with-server-provided' flag in the > > > request in order to get back the extended response. Likewise, it > > > doesn't break backup/restore workflows, as the server can discard > > > any 'server-provided' nodes passed in an operation. > > > > Huh? This goes against the defined behavior of 6241 + 7950. This is the > main > > problem with the solution in the current draft. > > > > If a client sends a for data in running, the server cannot > send back > > data that is not in running. > > > > > Lastly, it doesn't break /, as there is no comingling > > > of opstate data in the 'running' datastore. > > > > > > 2) It doesn't say anything about how the opstate data is stored on the > > > server. The opstate data is not modeled at all. This approach > > > only defines a presentation-layer format for how opstate data can > > > be returned via an RPC. The server is free to persist the opstate > > > data anyway it wants, perhaps in an internal datastore called > > > 'operational-state' or in an uber-datastore with the opstate data > > > flagged with a datastore='oper-state' attribute. Regardless, it's > > > an implementation detail, and the conceptual datastore model is > > > preserved. > > > > You are essentially defining a new operation, but do it by modifying the > > semantics of an existing one. I don't think this is a good idea; it is > better to > > define a new rpc. > > [Xufeng] Is using a new rpc is acceptable? If so, this could be a viable > option. The draft-ietf-netmod-revised-datastores proposes a new rpc (maybe ) to return data from the new operational-state datastore. This is IMO better than adding opstate nodes to the reply to a request. /martin From nobody Thu Feb 16 14:18:33 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CB01294CF for ; Thu, 16 Feb 2017 14:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 I3sZllNwOAqz for ; Thu, 16 Feb 2017 14:18:26 -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 96B69129457 for ; Thu, 16 Feb 2017 14:18:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAT30617; Thu, 16 Feb 2017 22:18:22 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 16 Feb 2017 22:18:21 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Thu, 16 Feb 2017 14:18:15 -0800 From: Alexander Clemm To: Andy Bierman , Susan Hares Thread-Topic: [i2rs] topo model use of NACM Thread-Index: AQHSiIcFMhe2D11fUkesxuPxtpMzeKFskAEAgAART4D//4okMA== Date: Thu, 16 Feb 2017 22:18:13 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1@SJCEML703-CHM.china.huawei.com> References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.18] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.58A6252F.00F8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2f658c86a068ad87196968b60352e9e9 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:18:30 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1SJCEML703CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGFjdHVhbGx5IGEgbnVtYmVyIG9mIGludGVyZXN0aW5nIGltcGxpY2F0aW9ucyB3 aXRoIHJlZ2FyZHMgdG8gTkFDTS4gIE5BQ00gY291bGQgaW5kZWVkIGJlIGEga2V5IHRvIHRoZSBz b2x1dGlvbiBpZiBpdCBwcm92aWRlcyBzdWZmaWNpZW50IGZsZXhpYmlsaXR5IHdpdGggcmVnYXJk cyB0byBhcnRpY3VsYXRpbmcgYW5kIGVuZm9yY2luZyBhdXRob3JpemF0aW9uIHJ1bGVzLiAgUmVn YXJkaW5nIHRoaXMsIEkgaGF2ZSBhIG51bWJlciBvZiBxdWVzdGlvbnMvY29tbWVudHM6DQoNCg0K LSAgICAgICAgICBJZiBhIHN1YnRyZWUgY29udGFpbnMgb2JqZWN0cyB0aGF0IGEgY2xpZW50IGRv ZXMgbm90IGhhdmUgd3JpdGUgcHJpdmlsZWdlcyBmb3IsIHdpbGwgdGhlIGNsaWVudCBiZSBwcmV2 ZW50ZWQgZnJvbSBsb2NraW5nIHRoZSBzdWJ0cmVlPyBIb3cgYWJvdXQgdGhlIGNhc2Ugd2hlbiB0 aGUgY2xpZW50IGRvZXMgbm90IGV2ZW4gaGF2ZSByZWFkIHByaXZpbGVnZXM/DQoNClRoZSBjdXJy ZW50IE5BQ00tYmlzIGRyYWZ0IHN0YXRlcyBpbiBzZWN0aW9uIDMuNy4yIHRoYXQgdGhpcyBpcyBu b3QgdGhlIGNhc2Ug4oCTIGkuZS4gYSBjbGllbnQgaXMgYWJsZSB0byBsb2NrIGFuIGVudGlyZSBz dWJ0cmVlLCBldmVuIGluIGNhc2VzIHdoZW4gdGhlcmUgaXMgbm90IGEgc2luZ2xlIG9iamVjdCBp biB0aGF0IHN1YnRyZWUgdGhhdCB0aGUgY2xpZW50IGFjdHVhbGx5IGhhcyBhY2Nlc3MgcHJpdmls ZWdlcyB0by4NCg0KVG8gbWUsIHRoaXMgZG9lcyBub3Qgc2VlbSByaWdodC4gIEl0IGp1c3QgaW52 aXRlcyBhYnVzZS4NCg0KTm93LCB0aGVyZSBpcyBzdGlsbCB0aGUgcG9zc2liaWxpdHkgdG8gcmVz dHJpY3QgYWNjZXNzIHRvIHRoZSBvcGVyYXRpb24gb3ZlcmFsbC4gIEJ1dCBhZ2FpbiwgdGhpcyBt ZWFucyB0aGF0IHlvdSBoYXZlIHRvIGdpdmUgYSB1c2VycyBhbiBhbGwtb3Itbm90aGluZyBjaG9p Y2UuICBUb28gaW5mbGV4aWJsZS4gIEJ5IHRoZSBzYW1lIHRva2VuIHRoYXQgcGFydGlhbCBsb2Nr cyB3ZXJlIHN1cHBvcnRlZCB0byBhdm9pZCByZXF1aXJpbmcgYW55b25lIHdobyBuZWVkcyB0aGUg YWJpbGl0eSB0byBjb25kdWN0IGEgdHJhbnNhY3Rpb24gdG8gbG9jayBkb3duIHRoZSBlbnRpcmUg c2VydmVyLCB0aGVyZSBzaG91bGQgYmUgdGhlIGFiaWxpdHkgdG8gcmVzdHJpY3QgYWNjZXNzIHRv IHRoZSBsb2NrIGFuZCBwYXJ0aWFsLWxvY2sgb3BlcmF0aW9uIGJ5IHRhcmdldGVkIHN1YnRyZWUu ICBIb3dldmVyLCB0aGlzIGNhcGFiaWxpdHkgaXMgY3VycmVudGx5IG1pc3NpbmcuDQoNCg0KLSAg ICAgICAgICBXaGVyZSBjYW4gTkFDTSBydWxlcyBvcmlnaW5hdGUgZnJvbT8gICBUaGUgY3VycmVu dCBtb2RlbCBzZWVtcyB0byBhc3N1bWUgdGhhdCBydWxlcyB3aWxsIGFsd2F5cyBiZSBleHBsaWNp dGx5IGNvbmZpZ3VyZWQgZnJvbSBhbiBleHRlcm5hbCBjbGllbnQgYW5kIGNvbnN0aXR1dGUgcGFy dCBvZiBjb25maWd1cmF0aW9uLiBOb3csIHdoYXQgYWJvdXQgdGhlIGNhc2Ugd2hlbiBydWxlcyBh cmUgdG8gYmUgZW5mb3JjZWQgYXV0b21hdGljYWxseSBieSB0aGUgc2VydmVyPyAgIEkgdGhpbmsg TkFDTSBzaG91bGQgYWxsb3cgZm9yIHRoYXQsIGFuZCBoYXZpbmcgYSBtaXggb2YgYm90aC4gIChU aGUgc2VydmVyLXByb3ZpZGVkIHRvcG9sb2dpZXMgYXJlIG9uZSBwb3RlbnRpYWwgZXhhbXBsZSB3 aGVyZSB0aGlzIHdvdWxkIGJlIHZlcnkgdXNlZnVsLiAgSW4gZmFjdCwgaWYgdGhpcyBjYXBhYmls aXR5IHdlcmUgc3VwcG9ydGVkLCBJIGRvbuKAmXQgdGhpbmsgd2Ugd291bGQgYmUgaGF2aW5nIHRo ZSBzZXJ2ZXItcHJvdmlkZWQgZGlzY3Vzc2lvbiBpbiB0aGUgdG9wb2xvZ3kgY29udGV4dCDigJMg TkFDTSB3b3VsZCBiZSBhbGwgd2UgbmVlZC4gIEhvd2V2ZXIsIHRoZXJlIGFyZSBvdGhlciB1c2Ug Y2FzZXMgZm9yIHRoaXMuICBUaGluayBlLmcuIGFuIGludHJ1c2lvbiBwcm90ZWN0aW9uIGNvbXBv bmVudCBvbiB0aGUgc2VydmVyLCB0aGF0IHlvdSB3b3VsZCBub3Qgd2FudCB0byBvdmVycmlkZSBi eSBhbiBleHRlcm5hbCB1c2VyIGFkbWluaXN0cmF0aW9uIGNsaWVudCBhcHBsaWNhdGlvbiB0aGF0 IHlvdSB3b3VsZCBzdGlsbCB3YW50IHRvIGFsbG93IGFzIHdlbGwuICBPciBjYXNlcyB3aGVuIHNv bWUgYXV0aG9yaXphdGlvbnMgZ2V0IHNpZ25hbGVkLCBlLmcuIGluIHRoZSBjYXNlIG9mIGF1dG9u b21pYyBwZWVyLXRvLXBlZXIgdHlwZSBvZiBhcHBsaWNhdGlvbnMuKQ0KDQotLS0gQWxleA0KDQpG cm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5k eSBCaWVybWFuDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcgMTI6NDkgUE0NClRv OiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPg0KQ2M6IGkycnNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbaTJyc10gdG9wbyBtb2RlbCB1c2Ugb2YgTkFDTQ0KDQpIaSwNCg0KSSBhbSBtb3N0 IGNvbmNlcm5lZCBhYm91dCBnZXR0aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmlnaHQuDQpXZSBoYXZl IGlnbm9yZWQgc2VydmVyLWNyZWF0ZWQgbm9kZXMgdW50aWwgbm93Lg0KSSBhbSBnbGFkIEkyUlMg V0cgaXMgdHJ5aW5nIHRvIGRlYWwgd2l0aCB0aGUgcHJvYmxlbS4NCkp1c3QgbWFrZSBzdXJlIHdl IGhhdmUgYSByZXVzYWJsZSBzb2x1dGlvbi4NCg0KQWxzbyBjb25jZXJuZWQgYWJvdXQgdG9vbCBh dXRvbWF0aW9uLg0KVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBvZiBhICdzZXJ2ZXItY3JlYXRl ZCcgZXh0ZW5zaW9uIGF0IHNvbWUgcG9pbnQgSSB0aGluay4NClRoaXMgd291bGQgaGVscCwgYmVj YXVzZSB0aGUgc2VydmVyLWNyZWF0ZWQgbGVhZiBpcyBub3QgcmVhbGx5IGRldGVybWluaXN0aWMu DQpJdCBpcyBqdXN0IGEgY29udmVudGlvbi4NCg0KZS5nLg0KDQoNCiAgY29udGFpbmVyIG5ldHdv cmtzIHsNCiAgICAgbGlzdCBuZXR3b3JrIHsNCiAgICAgICAgIGkycnM6c2VydmVyLWNyZWF0ZWQ7 DQogICAgICAgICAuLi4NCiAgICAgICAgIGxlYWYgc2VydmVyLWNyZWF0ZWQgeyAuLi4gfQ0KICAg ICAgICAgLi4uDQogICAgIH0NCiAgfQ0KDQoNCkFuZHkNCg0KDQpPbiBUaHUsIEZlYiAxNiwgMjAx NyBhdCAxMTo0NyBBTSwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVz QG5kemguY29tPj4gd3JvdGU6DQpBbmR5Og0KPGNoYWlyIGhhdCBvZmYsIGluZGl2aWR1YWwgY29u dHJpYnV0b3IgaGF0IG9uPg0KDQpBRkFJSyDigJMgSSBiZWxpZXZlIHRoZSByZXZpc2VkIGRhdGEg c3RvcmUgbW9kZWwgaXMgcmlnaHQgYXBwcm9hY2guICAgSXQgaXMgYW4gaW1wb3J0YW50IHF1ZXN0 aW9uIHRvIGFzayB3aGV0aGVyIHRoZSBhYmlsaXR5IHRvIGhhdmUgYSBtaXh0dXJlIG9mIOKAnHNl cnZlci1wcm92aWRlZOKAnSBhbmQg4oCcY29uZmlndXJlZOKAnSBpcyBpbXBvcnRhbnQgZm9yIGFs bCB0b3BvbG9neSBtb2RlbHMuICBJIGhvcGUgWHVmZW5nIGFuZCBvdGhlciB0b3BvbG9neSBtb2Rl bHMgd2lsbCBjb21tZW50IG9uIHRoaXMgcG9pbnQuDQoNCg0KRG9lcyB0aGUgTkVUQ09ORiBkYXRh IHN0b3JlIGluIHRoZSByZXZpc2VkIGRhdGEtc3RvcmUgZnV0dXJlIGluY2x1ZGUgdGhlIGNvbnRy b2wgcGxhbmUgZGF0YSBzdG9yZXM/IEkgdGhvdWdodCB0aGUgYW5zd2VyIHdhcyDigJxub+KAnSBp dCBkb2VzIG5vdC4gICBIZXJl4oCZcyBzb21lIHRleHQgZnJvbSBkcmFmdC1pZXRmLW5ldGNvbmYt cmZjNjUzNmJpcyB0aGF0IGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdA0KDQpPbiBOQUNNLCBkcmFm dC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcyBpdCBzYXlzOg0KDQogICBJdCBpcyBuZWNlc3Nhcnkg dG8gY29udHJvbCBhY2Nlc3MgdG8gc3BlY2lmaWMgbm9kZXMgYW5kIHN1YnRyZWVzDQogICB3aXRo aW4gdGhlIE5FVENPTkYgZGF0YXN0b3JlLCByZWdhcmRsZXNzIG9mIHdoaWNoIHByb3RvY29sIG9w ZXJhdGlvbiwNCiAgIHN0YW5kYXJkIG9yIHByb3ByaWV0YXJ5LCB3YXMgdXNlZCB0byBhY2Nlc3Mg dGhlIGRhdGFzdG9yZS4NCg0KMy4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldGNvbmYtcmZjNjUzNmJpcy0wMCNzZWN0aW9uLTMuMj4uICBEYXRhc3RvcmUgQWNjZXNz DQoNCiAgIFRoZSBzYW1lIGFjY2VzcyBjb250cm9sIHJ1bGVzIGFwcGx5IHRvIGFsbCBkYXRhc3Rv cmVzLCBmb3IgZXhhbXBsZSwNCg0KICAgdGhlIGNhbmRpZGF0ZSBjb25maWd1cmF0aW9uIGRhdGFz dG9yZSBvciB0aGUgcnVubmluZyBjb25maWd1cmF0aW9uDQoNCiAgIGRhdGFzdG9yZS4NCg0KDQoN CiAgIE9ubHkgdGhlIHN0YW5kYXJkIE5FVENPTkYgZGF0YXN0b3JlcyAoY2FuZGlkYXRlLCBydW5u aW5nLCBhbmQNCg0KICAgc3RhcnR1cCkgYXJlIGNvbnRyb2xsZWQgYnkgTkFDTS4gIExvY2FsIG9y IHJlbW90ZSBmaWxlcyBvciBkYXRhc3RvcmVzDQoNCiAgIGFjY2Vzc2VkIHZpYSB0aGUgPHVybD4g cGFyYW1ldGVyIGFyZSBub3QgY29udHJvbGxlZCBieSBOQUNNLiAgQQ0KDQogICBzdGFuZGFsb25l IFJFU1RDT05GIHNlcnZlciAoaS5lLiwgbm90IGNvLWxvY2F0ZWQgd2l0aCBhIE5FVENPTkYNCg0K ICAgc2VydmVyKSBhcHBsaWVzIE5BQ00gcnVsZXMgdG8gYSBjb25jZXB0dWFsIGRhdGFzdG9yZSwg c2luY2UNCg0KICAgZGF0YXN0b3JlcyBhcmUgbm90IHN1cHBvcnRlZCBpbiBSRVNUQ09ORi4NCg0K DQo9PT09PT09PT09PQ0KDQpUaGUgSTJSUyBzZWN1cml0eSBlbnZpcm9ubWVudCBhY3R1YWxseSBs b29rcyBhdCAzIHBvbGljaWVzIG9uIHRoZSBzZXJ2ZXINCg0KTmV0d29yayBBY2Nlc3MgPC0tLS0t PiBzZXJ2ZXIgPC0tLS0tPiByb3V0aW5nLXN5c3RlbSBhY2Nlc3MNCiAgICAgICAgICAgICAgKGFr YSBJMlJTIGFnZW50KQ0KICAgICAgICAgICAgICAgICAgICB8PC0tLS0+IFN5c3RlbSBhY2Nlc3MN Cg0KSXQgYWxzbyBsb29rcyBhdCBhcHBsaWNhdGlvbiBhY2Nlc3MgdG8gdGhlIGNsaWVudA0KDQog IE5ldHdvcmsgYWNjZXNzPC0tLS0+IGNsaWVudCA8LS0tLT4gYXBwbGljYXRpb24tYWNjZXNzDQoN Cg0KVGhlIHByb3RvY29sIG9ubHkgbmVlZHMgdG8gY29uc2lkZXIgdGhlIE5BQ00gQWNjZXNzLCBi dXQgdGhlIHJvdXRpbmcgaW5mcmFzdHJ1Y3R1cmUgbmVlZCB0byBjb25zaWRlciB0aGUgc2VydmVy IHRvL2Zyb20gcm91dGluZyBzeXN0ZW0sIGFuZCBzZXJ2ZXIgdG8vZnJvbSBzeXN0ZW0uICBNeSB1 bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIFJvdXRpbmcgc3lzdGVtIGFjY2VzcyBjb250cm9sIG1v ZHVsZSAoUkFDTSkgYW5kIHRoZSBzeXN0ZW0gYWNjZXNzIGNvbnRyb2wgbW9kdWxlIChTQUNNKSBm dW5jdGlvbnMgd2VyZSBub3QgaW4gTkFDTS4NCg0KVGhhbmtzIGFnYWluIGZvciBwb3N0aW5nLA0K DQpTdWUNCg0KRnJvbTogaTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 aTJycy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDog VGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDI6MDAgUE0NClRvOiBpMnJzQGlldGYub3JnPG1h aWx0bzppMnJzQGlldGYub3JnPg0KU3ViamVjdDogW2kycnNdIHRvcG8gbW9kZWwgdXNlIG9mIE5B Q00NCg0KSGksDQoNClRoZSB1c2Ugb2YgTkFDTSBmb3Igc2VydmVyLXByb3ZpZGVkIGRhdGEgaXMg dW5kZXItc3BlY2lmaWVkIChhdCBiZXN0KQ0KDQoNCmZyb20gc2VjLiA0LjE6DQoNCg0KICAgRmlu YWxseSwgdGhlcmUgaXMgYW4gb2JqZWN0ICJzZXJ2ZXItcHJvdmlkZWQiLiAgVGhpcyBvYmplY3Qg aXMgc3RhdGUNCg0KICAgdGhhdCBpbmRpY2F0ZXMgaG93IHRoZSBuZXR3b3JrIGNhbWUgaW50byBi ZWluZy4gIE5ldHdvcmsgZGF0YSBjYW4NCg0KICAgY29tZSBpbnRvIGJlaW5nIGluIG9uZSBvZiB0 d28gd2F5cy4gIEluIG9uZSB3YXksIG5ldHdvcmsgZGF0YSBpcw0KDQogICBjb25maWd1cmVkIGJ5 IGNsaWVudCBhcHBsaWNhdGlvbnMsIGZvciBleGFtcGxlIGluIGNhc2Ugb2Ygb3ZlcmxheQ0KDQog ICBuZXR3b3JrcyB0aGF0IGFyZSBjb25maWd1cmVkIGJ5IGFuIFNETiBDb250cm9sbGVyIGFwcGxp Y2F0aW9uLiAgSW4NCg0KICAgYW5ub3RoZXIgd2F5LCBpdCBpcyBwb3B1bGF0ZWQgYnkgdGhlIHNl cnZlciwgaW4gY2FzZSBvZiBuZXR3b3JrcyB0aGF0DQoNCiAgIGNhbiBiZSBkaXNjb3ZlcmVkLg0K DQoNCg0KICAgSWYgc2VydmVyLXByb3ZpZGVkIGlzIHNldCB0byBmYWxzZSwgdGhlIG5ldHdvcmsg d2FzIGNvbmZpZ3VyZWQgYnkgYQ0KDQogICBjbGllbnQgYXBwbGljYXRpb24sIGZvciBleGFtcGxl IGluIHRoZSBjYXNlIG9mIGFuIG92ZXJsYXkgbmV0d29yaw0KDQogICB0aGF0IGlzIGNvbmZpZ3Vy ZWQgYnkgYSBjb250cm9sbGVyIGFwcGxpY2F0aW9uLiAgSWYgc2VydmVyLXByb3ZpZGVkDQoNCiAg IGlzIHNldCB0byB0cnVlLCB0aGUgbmV0d29yayB3YXMgcG9wdWxhdGVkIGJ5IHRoZSBzZXJ2ZXIg aXRzZWxmLA0KDQogICByZXNwZWN0aXZlbHkgYW4gYXBwbGljYXRpb24gb24gdGhlIHNlcnZlciB0 aGF0IGlzIGFibGUgdG8gZGlzY292ZXINCg0KICAgdGhlIG5ldHdvcmsuICBDbGllbnQgYXBwbGlj YXRpb25zIFNIT1VMRCBOT1QgbW9kaWZ5IGNvbmZpZ3VyYXRpb25zIG9mDQoNCiAgIG5ldHdvcmtz IGZvciB3aGljaCAic2VydmVyLXByb3ZpZGVkIiBpcyB0cnVlLiAgV2hlbiB0aGV5IGRvLCB0aGV5 DQoNCiAgIG5lZWQgdG8gYmUgYXdhcmUgdGhhdCBhbnkgbW9kaWZpY2F0aW9ucyB0aGV5IG1ha2Ug YXJlIHN1YmplY3QgdG8gYmUNCg0KICAgcmV2ZXJ0ZWQgYnkgdGhlIHNlcnZlci4gIEZvciBzZXJ2 ZXJzIHRoYXQgc3VwcG9ydCBOQUNNIChOZXRjb25mDQoNCiAgIEFjY2VzcyBDb250cm9sIE1vZGVs KSwgZGF0YSBub2RlIHJ1bGVzIHNob3VsZCBpZGVhbGx5IHByZXZlbnQgd3JpdGUNCg0KICAgYWNj ZXNzIGJ5IG90aGVyIGNsaWVudHMgdG8gbmV0d29yayBpbnN0YW5jZXMgZm9yIHdoaWNoIHNlcnZl ci0NCg0KICAgcHJvdmlkZWQgaXMgc2V0IHRvIHRydWUuDQoNClRoZSBTSE9VTEQgTk9UIGFib3Zl IGlzIHJlYWxseSBvZGQsIGNvbnNpZGVyaW5nIGlzIG5vdCBzdXBwb3J0ZWQgYnkgWUFORw0Kb3Ig dGhlIE5DL1JDIHByb3RvY29scy4NCg0KImRhdGEgbm9kZSBydWxlcyBzaG91bGQgaWRlYWxseSBw cmV2ZW50Ig0KDQpzL3Nob3VsZC9TSE9VTEQvDQoNCklkZWFsbHkgcHJldmVudD8NCklzIHRoYXQg YSBuZXcgZW5naW5lZXJpbmcgdGVybT8NCkVpdGhlciB0aGlzIG5ldyB1c2FnZSBvZiBOQUNNIHdv cmtzIG9yIGl0IGRvZXNuJ3QuDQoNCkFsc28sIHRoZXJlIGlzIG5vIGd1aWRhbmNlIG9yIGV4YW1w bGVzIG9mIHRoZSBOQUNNIGNvbmZpZyB0aGF0IHRoZQ0Kc2VydmVyIGlzIHN1cHBvc2VkIHRvIG1h Z2ljYWxseSBjcmVhdGUgZm9yIHNlcnZlci1wcm92aWRlZCB0b3BvbG9neSBkYXRhLg0KVGhlcmUg aXMgbm90aGluZyBpbiBOQUNNIGF0IGFsbCBhYm91dCBzZXJ2ZXItY3JlYXRlZCBkYXRhIHJ1bGVz Lg0KVGhpcyBpcyBub3Qgc3VwcG9ydGVkIGJ5IE5BQ00uDQoNCkRvZXMgdGhlIEkyUlMgdGV4dCBp bXBseSB0aGF0IHRoZSBzZXJ2ZXItcHJvdmlkZWQgcHJvcGVydHkgZXh0ZW5kcw0KdG8gdGhlIE5B Q00gc3ViLXRyZWVzPyBUaGV5IGFyZSBhbHNvIHN1YmplY3QgdG8gcmVwbGFjZW1lbnQgYnkgdGhl IHNlcnZlcj8NClRoZSBjbGllbnQgU0hPVUxEIE5PVCBjaGFuZ2UgdGhlc2UgTkFDTSBydWxlcz8N Cg0KSU1PIHRoZSB3YXkgdGhpcyBzZXJ2ZXItcHJvdmlkZWQgcHJvcGVydHkgaXMgYmVpbmcgZG9u ZSBpcyBhIHNob3J0LXNpZ2h0ZWQNCnBvaW50IHNvbHV0aW9uLCBidXQgdGhpcyBzaG91bGQgYmUg YSBmdW5kYW1lbnRhbCBwYXJ0IG9mIHRoZSByZXZpc2VkIGRhdGFzdG9yZXMgd29yay4NCklzIHRo ZXJlIHNvbWV0aGluZyBzcGVjaWFsIGFib3V0IG5ldHdvcmsgdG9wb2xvZ3kgc3VjaCB0aGF0DQpz ZXJ2ZXItcHJvdmlkZWQgZGF0YSBmb3IgYSBkaWZmZXJlbnQgbW9kdWxlIHdpbGwgcmVxdWlyZSBh IGRpZmZlcmVudA0Kc29sdXRpb24/IElmIG5vdCwgaXMgdGhlIHRvcG8gbW9kdWxlIHNvbHV0aW9u IHJldXNhYmxlPw0KDQoNCkFuZHkNCg0KDQoNCg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1SJCEML703CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28t c3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0RDc4O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDU1NzExMjczOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDY4NDA2MjUyIC04Mjc5NjEzMDYgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGFyZSBhY3R1YWxseSBhIG51bWJlciBvZiBpbnRl cmVzdGluZyBpbXBsaWNhdGlvbnMgd2l0aCByZWdhcmRzIHRvIE5BQ00uJm5ic3A7IE5BQ00gY291 bGQgaW5kZWVkIGJlIGEga2V5IHRvIHRoZSBzb2x1dGlvbiBpZiBpdCBwcm92aWRlcyBzdWZmaWNp ZW50IGZsZXhpYmlsaXR5DQogd2l0aCByZWdhcmRzIHRvIGFydGljdWxhdGluZyBhbmQgZW5mb3Jj aW5nIGF1dGhvcml6YXRpb24gcnVsZXMuJm5ic3A7IFJlZ2FyZGluZyB0aGlzLCBJIGhhdmUgYSBu dW1iZXIgb2YgcXVlc3Rpb25zL2NvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JZiBhIHN1YnRyZWUgY29udGFpbnMgb2JqZWN0cyB0aGF0IGEgY2xpZW50IGRv ZXMgbm90IGhhdmUgd3JpdGUgcHJpdmlsZWdlcyBmb3IsIHdpbGwgdGhlIGNsaWVudCBiZSBwcmV2 ZW50ZWQgZnJvbSBsb2NraW5nIHRoZSBzdWJ0cmVlPyBIb3cgYWJvdXQgdGhlDQogY2FzZSB3aGVu IHRoZSBjbGllbnQgZG9lcyBub3QgZXZlbiBoYXZlIHJlYWQgcHJpdmlsZWdlcz8mbmJzcDsgPGJy Pg0KPGJyPg0KVGhlIGN1cnJlbnQgTkFDTS1iaXMgZHJhZnQgc3RhdGVzIGluIHNlY3Rpb24gMy43 LjIgdGhhdCB0aGlzIGlzIG5vdCB0aGUgY2FzZSDigJMgaS5lLiBhIGNsaWVudCBpcyBhYmxlIHRv IGxvY2sgYW4gZW50aXJlIHN1YnRyZWUsIGV2ZW4gaW4gY2FzZXMgd2hlbiB0aGVyZSBpcyBub3Qg YSBzaW5nbGUgb2JqZWN0IGluIHRoYXQgc3VidHJlZSB0aGF0IHRoZSBjbGllbnQgYWN0dWFsbHkg aGFzIGFjY2VzcyBwcml2aWxlZ2VzIHRvLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbWUsIHRoaXMg ZG9lcyBub3Qgc2VlbSByaWdodC4mbmJzcDsgSXQganVzdCBpbnZpdGVzIGFidXNlLiZuYnNwOw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5vdywgdGhlcmUgaXMgc3RpbGwg dGhlIHBvc3NpYmlsaXR5IHRvIHJlc3RyaWN0IGFjY2VzcyB0byB0aGUgb3BlcmF0aW9uIG92ZXJh bGwuJm5ic3A7IEJ1dCBhZ2FpbiwgdGhpcyBtZWFucyB0aGF0IHlvdSBoYXZlIHRvIGdpdmUgYSB1 c2Vycw0KIGFuIGFsbC1vci1ub3RoaW5nIGNob2ljZS4mbmJzcDsgVG9vIGluZmxleGlibGUuJm5i c3A7IEJ5IHRoZSBzYW1lIHRva2VuIHRoYXQgcGFydGlhbCBsb2NrcyB3ZXJlIHN1cHBvcnRlZCB0 byBhdm9pZCByZXF1aXJpbmcgYW55b25lIHdobyBuZWVkcyB0aGUgYWJpbGl0eSB0byBjb25kdWN0 IGEgdHJhbnNhY3Rpb24gdG8gbG9jayBkb3duIHRoZSBlbnRpcmUgc2VydmVyLCB0aGVyZSBzaG91 bGQgYmUgdGhlIGFiaWxpdHkgdG8gcmVzdHJpY3QgYWNjZXNzIHRvIHRoZSBsb2NrDQogYW5kIHBh cnRpYWwtbG9jayBvcGVyYXRpb24gYnkgdGFyZ2V0ZWQgc3VidHJlZS4mbmJzcDsgSG93ZXZlciwg dGhpcyBjYXBhYmlsaXR5IGlzIGN1cnJlbnRseSBtaXNzaW5nLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGVy ZSBjYW4gTkFDTSBydWxlcyBvcmlnaW5hdGUgZnJvbT8mbmJzcDsgJm5ic3A7VGhlIGN1cnJlbnQg bW9kZWwgc2VlbXMgdG8gYXNzdW1lIHRoYXQgcnVsZXMgd2lsbCBhbHdheXMgYmUgZXhwbGljaXRs eSBjb25maWd1cmVkIGZyb20gYW4gZXh0ZXJuYWwgY2xpZW50IGFuZA0KIGNvbnN0aXR1dGUgcGFy dCBvZiBjb25maWd1cmF0aW9uLiBOb3csIHdoYXQgYWJvdXQgdGhlIGNhc2Ugd2hlbiBydWxlcyBh cmUgdG8gYmUgZW5mb3JjZWQgYXV0b21hdGljYWxseSBieSB0aGUgc2VydmVyPyAmbmJzcDsmbmJz cDtJIHRoaW5rIE5BQ00gc2hvdWxkIGFsbG93IGZvciB0aGF0LCBhbmQgaGF2aW5nIGEgbWl4IG9m IGJvdGguICZuYnNwOyhUaGUgc2VydmVyLXByb3ZpZGVkIHRvcG9sb2dpZXMgYXJlIG9uZSBwb3Rl bnRpYWwgZXhhbXBsZSB3aGVyZSB0aGlzIHdvdWxkDQogYmUgdmVyeSB1c2VmdWwuJm5ic3A7IElu IGZhY3QsIGlmIHRoaXMgY2FwYWJpbGl0eSB3ZXJlIHN1cHBvcnRlZCwgSSBkb27igJl0IHRoaW5r IHdlIHdvdWxkIGJlIGhhdmluZyB0aGUgc2VydmVyLXByb3ZpZGVkIGRpc2N1c3Npb24gaW4gdGhl IHRvcG9sb2d5IGNvbnRleHQg4oCTIE5BQ00gd291bGQgYmUgYWxsIHdlIG5lZWQuJm5ic3A7IEhv d2V2ZXIsIHRoZXJlIGFyZSBvdGhlciB1c2UgY2FzZXMgZm9yIHRoaXMuJm5ic3A7IFRoaW5rIGUu Zy4gYW4gaW50cnVzaW9uIHByb3RlY3Rpb24NCiBjb21wb25lbnQgb24gdGhlIHNlcnZlciwgdGhh dCB5b3Ugd291bGQgbm90IHdhbnQgdG8gb3ZlcnJpZGUgYnkgYW4gZXh0ZXJuYWwgdXNlciBhZG1p bmlzdHJhdGlvbiBjbGllbnQgYXBwbGljYXRpb24gdGhhdCB5b3Ugd291bGQgc3RpbGwgd2FudCB0 byBhbGxvdyBhcyB3ZWxsLiZuYnNwOyBPciBjYXNlcyB3aGVuIHNvbWUgYXV0aG9yaXphdGlvbnMg Z2V0IHNpZ25hbGVkLCBlLmcuIGluIHRoZSBjYXNlIG9mIGF1dG9ub21pYyBwZWVyLXRvLXBlZXIg dHlwZQ0KIG9mIGFwcGxpY2F0aW9ucy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4tLS0gQWxleCZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGkycnMgW21haWx0bzppMnJzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcgMTI6NDkgUE08YnI+DQo8Yj5U bzo8L2I+IFN1c2FuIEhhcmVzICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBpMnJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaTJyc10gdG9wbyBtb2Rl bCB1c2Ugb2YgTkFDTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBtb3N0IGNv bmNlcm5lZCBhYm91dCBnZXR0aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmlnaHQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGlnbm9yZWQg c2VydmVyLWNyZWF0ZWQgbm9kZXMgdW50aWwgbm93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBnbGFkIEkyUlMgV0cgaXMgdHJ5aW5nIHRv IGRlYWwgd2l0aCB0aGUgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgbWFrZSBzdXJlIHdlIGhhdmUgYSByZXVzYWJsZSBzb2x1 dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxzbyBjb25jZXJuZWQgYWJvdXQgdG9vbCBhdXRvbWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgd2FzIHNvbWUgZGlzY3Vz c2lvbiBvZiBhICdzZXJ2ZXItY3JlYXRlZCcgZXh0ZW5zaW9uIGF0IHNvbWUgcG9pbnQgSSB0aGlu ay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgd291bGQgaGVscCwgYmVjYXVzZSB0aGUgc2VydmVyLWNyZWF0ZWQgbGVhZiBpcyBub3QgcmVh bGx5IGRldGVybWluaXN0aWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JdCBpcyBqdXN0IGEgY29udmVudGlvbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZS5nLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgY29u dGFpbmVyIG5ldHdvcmtzIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7bGlzdCBuZXR3b3JrIHs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpMnJzOnNlcnZlci1jcmVhdGVkOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgc2VydmVy LWNyZWF0ZWQgeyAuLi4gfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy4uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBGZWIgMTYsIDIwMTcgYXQgMTE6NDcgQU0sIFN1c2FuIEhhcmVzICZs dDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIiB0YXJnZXQ9Il9ibGFuayI+c2hhcmVz QG5kemguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5keToN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbHQ7Y2hhaXIgaGF0IG9mZiwgaW5kaXZpZHVhbCBjb250cmlidXRvciBoYXQgb24m Z3Q7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFGQUlLIOKAkyBJIGJlbGlldmUgdGhlIHJldmlzZWQg ZGF0YSBzdG9yZSBtb2RlbCBpcyByaWdodCBhcHByb2FjaC4gJm5ic3A7Jm5ic3A7SXQgaXMgYW4g aW1wb3J0YW50IHF1ZXN0aW9uIHRvIGFzayB3aGV0aGVyIHRoZQ0KIGFiaWxpdHkgdG8gaGF2ZSBh IG1peHR1cmUgb2Yg4oCcc2VydmVyLXByb3ZpZGVk4oCdIGFuZCDigJxjb25maWd1cmVk4oCdIGlz IGltcG9ydGFudCBmb3IgYWxsIHRvcG9sb2d5IG1vZGVscy4mbmJzcDsgSSBob3BlIFh1ZmVuZyBh bmQgb3RoZXIgdG9wb2xvZ3kgbW9kZWxzIHdpbGwgY29tbWVudCBvbiB0aGlzIHBvaW50Lg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkRvZXMgdGhlIE5FVENPTkYgZGF0YSBzdG9yZSBpbiB0aGUgcmV2aXNl ZCBkYXRhLXN0b3JlIGZ1dHVyZSBpbmNsdWRlIHRoZSBjb250cm9sIHBsYW5lIGRhdGEgc3RvcmVz PyBJIHRob3VnaHQgdGhlIGFuc3dlcg0KIHdhcyDigJxub+KAnSBpdCBkb2VzIG5vdC4mbmJzcDsg Jm5ic3A7SGVyZeKAmXMgc29tZSB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZi aXMgdGhhdCBsZWFkcyBtZSB0byBiZWxpZXZlIHRoYXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T24g TkFDTSwgZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZiaXMgaXQgc2F5czoNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgSXQgaXMgbmVjZXNzYXJ5IHRvIGNvbnRyb2wgYWNjZXNzIHRvIHNwZWNp ZmljIG5vZGVzIGFuZCBzdWJ0cmVlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aXRoaW4gdGhlIE5FVENPTkYgZGF0 YXN0b3JlLCByZWdhcmRsZXNzIG9mIHdoaWNoIHByb3RvY29sIG9wZXJhdGlvbiw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgc3RhbmRhcmQgb3IgcHJvcHJpZXRhcnksIHdhcyB1c2VkIHRvIGFjY2VzcyB0aGUgZGF0YXN0 b3JlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxoMz48YSBuYW1lPSJtXy02NDY4MjY3 MzQyODYyMDYzNTA2X3NlY3Rpb24tMy4yIj48L2E+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2YmlzLTAwI3NlY3Rpb24tMy4yIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjMuMjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPi4mbmJzcDsNCiBEYXRhc3RvcmUgQWNjZXNzPC9zcGFuPjxvOnA+PC9v OnA+PC9oMz4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gJm5ic3A7Jm5ic3A7VGhl IHNhbWUgYWNjZXNzIGNvbnRyb2wgcnVsZXMgYXBwbHkgdG8gYWxsIGRhdGFzdG9yZXMsIGZvciBl eGFtcGxlLDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgY2FuZGlkYXRlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl IG9yIHRoZSBydW5uaW5nIGNvbmZpZ3VyYXRpb248L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZGF0YXN0b3JlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBPbmx5IHRoZSBzdGFuZGFyZCBORVRDT05GIGRhdGFzdG9yZXMgKGNhbmRp ZGF0ZSwgcnVubmluZywgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN0YXJ0dXApIGFyZSBjb250cm9sbGVkIGJ5 IE5BQ00uJm5ic3A7IExvY2FsIG9yIHJlbW90ZSBmaWxlcyBvciBkYXRhc3RvcmVzPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGFjY2Vzc2VkIHZpYSB0aGUgJmx0O3VybCZndDsgcGFyYW1ldGVyIGFyZSBub3QgY29udHJv bGxlZCBieSBOQUNNLiZuYnNwOyBBPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN0YW5kYWxvbmUgUkVTVENPTkYgc2Vy dmVyIChpLmUuLCBub3QgY28tbG9jYXRlZCB3aXRoIGEgTkVUQ09ORjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzZXJ2 ZXIpIGFwcGxpZXMgTkFDTSBydWxlcyB0byBhIGNvbmNlcHR1YWwgZGF0YXN0b3JlLCBzaW5jZTwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBkYXRhc3RvcmVzIGFyZSBub3Qgc3VwcG9ydGVkIGluIFJFU1RDT05GLjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PT09PT09PT09PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgSTJSUyBzZWN1cml0eSBlbnZpcm9ubWVudCBh Y3R1YWxseSBsb29rcyBhdCAzIHBvbGljaWVzIG9uIHRoZSBzZXJ2ZXINCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk5ldHdvcmsg QWNjZXNzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzIj7Dnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPsOgPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gc2Vy dmVyDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzIj7Dnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPsOgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gcm91dGlu Zy1zeXN0ZW0NCiBhY2Nlc3MgJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KGFrYSBJ MlJTIGFnZW50KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncyI+w5/DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQogU3lzdGVtIGFjY2VzcyA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5JdCBhbHNvIGxvb2tzIGF0IGFwcGxpY2F0aW9uIGFjY2VzcyB0byB0aGUgY2xpZW50DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgTmV0d29yayBhY2Nlc3M8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj7Dn8OgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCiBjbGllbnQg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cyI+w5/DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IGFwcGxpY2F0aW9uLWFjY2VzcyAmbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgcHJvdG9jb2wgb25seSBuZWVkcyB0byBjb25zaWRlciB0 aGUgTkFDTSBBY2Nlc3MsIGJ1dCB0aGUgcm91dGluZyBpbmZyYXN0cnVjdHVyZSBuZWVkIHRvIGNv bnNpZGVyIHRoZSBzZXJ2ZXIgdG8vZnJvbQ0KIHJvdXRpbmcgc3lzdGVtLCBhbmQgc2VydmVyIHRv L2Zyb20gc3lzdGVtLiZuYnNwOyBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIFJvdXRpbmcg c3lzdGVtIGFjY2VzcyBjb250cm9sIG1vZHVsZSAoUkFDTSkgYW5kIHRoZSBzeXN0ZW0gYWNjZXNz IGNvbnRyb2wgbW9kdWxlIChTQUNNKSBmdW5jdGlvbnMgd2VyZSBub3QgaW4gTkFDTS4NCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlRoYW5rcyBhZ2FpbiBmb3IgcG9zdGluZywNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlN1ZSAmbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBp MnJzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmkycnMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIw MTcgMjowMCBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pMnJzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBb aTJyc10gdG9wbyBtb2RlbCB1c2Ugb2YgTkFDTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgdXNlIG9mIE5BQ00gZm9yIHNlcnZlci1wcm92aWRlZCBkYXRhIGlzIHVu ZGVyLXNwZWNpZmllZCAoYXQgYmVzdCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5mcm9tIHNlYy4gNC4xOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3do aXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBGaW5hbGx5LCB0aGVyZSBpcyBhbiBvYmplY3QgJnF1b3Q7c2VydmVyLXByb3ZpZGVkJnF1b3Q7 LiZuYnNwOyBUaGlzIG9iamVjdCBpcyBzdGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGF0IGluZGljYXRlcyBo b3cgdGhlIG5ldHdvcmsgY2FtZSBpbnRvIGJlaW5nLiZuYnNwOyBOZXR3b3JrIGRhdGEgY2FuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGNvbWUgaW50byBiZWluZyBpbiBvbmUgb2YgdHdvIHdheXMuJm5ic3A7IEluIG9u ZSB3YXksIG5ldHdvcmsgZGF0YSBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjb25maWd1cmVkIGJ5IGNsaWVudCBh cHBsaWNhdGlvbnMsIGZvciBleGFtcGxlIGluIGNhc2Ugb2Ygb3ZlcmxheTwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBu ZXR3b3JrcyB0aGF0IGFyZSBjb25maWd1cmVkIGJ5IGFuIFNETiBDb250cm9sbGVyIGFwcGxpY2F0 aW9uLiZuYnNwOyBJbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbm5vdGhlciB3YXksIGl0IGlzIHBvcHVsYXRlZCBi eSB0aGUgc2VydmVyLCBpbiBjYXNlIG9mIG5ldHdvcmtzIHRoYXQ8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2FuIGJl IGRpc2NvdmVyZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IElmIHNlcnZlci1wcm92aWRlZCBpcyBzZXQg dG8gZmFsc2UsIHRoZSBuZXR3b3JrIHdhcyBjb25maWd1cmVkIGJ5IGE8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2xp ZW50IGFwcGxpY2F0aW9uLCBmb3IgZXhhbXBsZSBpbiB0aGUgY2FzZSBvZiBhbiBvdmVybGF5IG5l dHdvcms8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgdGhhdCBpcyBjb25maWd1cmVkIGJ5IGEgY29udHJvbGxlciBhcHBs aWNhdGlvbi4mbmJzcDsgSWYgc2VydmVyLXByb3ZpZGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlzIHNldCB0byB0 cnVlLCB0aGUgbmV0d29yayB3YXMgcG9wdWxhdGVkIGJ5IHRoZSBzZXJ2ZXIgaXRzZWxmLDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyByZXNwZWN0aXZlbHkgYW4gYXBwbGljYXRpb24gb24gdGhlIHNlcnZlciB0aGF0IGlz IGFibGUgdG8gZGlzY292ZXI8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIG5ldHdvcmsuJm5ic3A7IDxiPkNsaWVu dCBhcHBsaWNhdGlvbnMgU0hPVUxEIE5PVCBtb2RpZnkgY29uZmlndXJhdGlvbnMgb2Y8L2I+PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IG5ldHdvcmtzIGZvciB3aGljaCAmcXVvdDtzZXJ2ZXItcHJvdmlkZWQmcXVv dDsgaXMgdHJ1ZS48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IFdo ZW4gdGhleSBkbywgdGhleTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBuZWVkIHRvIGJlIGF3YXJlIHRoYXQgYW55IG1v ZGlmaWNhdGlvbnMgdGhleSBtYWtlIGFyZSBzdWJqZWN0IHRvIGJlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJldmVy dGVkIGJ5IHRoZSBzZXJ2ZXIuJm5ic3A7IEZvciBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCBOQUNNIChO ZXRjb25mPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IEFjY2VzcyBDb250cm9sIE1vZGVsKSwgPGI+ZGF0YSBub2RlIHJ1 bGVzIHNob3VsZCBpZGVhbGx5IHByZXZlbnQ8L2I+IHdyaXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFjY2VzcyBi eSBvdGhlciBjbGllbnRzIHRvIG5ldHdvcmsgaW5zdGFuY2VzIGZvciB3aGljaCBzZXJ2ZXItPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IHByb3ZpZGVkIGlzIHNldCB0byB0cnVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFNIT1VMRCBO T1QgYWJvdmUgaXMgcmVhbGx5IG9kZCwgY29uc2lkZXJpbmcgaXMgbm90IHN1cHBvcnRlZCBieSBZ QU5HPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pm9yIHRoZSBOQy9SQyBwcm90b2NvbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PmRhdGEgbm9kZSBydWxlcyBzaG91bGQgaWRlYWxseSBwcmV2ZW50JnF1b3Q7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zL3Nob3VsZC9TSE9VTEQvPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5JZGVhbGx5IHByZXZlbnQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPklzIHRoYXQgYSBuZXcgZW5naW5lZXJpbmcgdGVybT88L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+RWl0aGVyIHRoaXMgbmV3IHVzYWdlIG9mIE5BQ00gd29ya3Mgb3IgaXQgZG9l c24ndC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFsc28sIHRoZXJlIGlzIG5v IGd1aWRhbmNlIG9yIGV4YW1wbGVzIG9mIHRoZSBOQUNNIGNvbmZpZyB0aGF0IHRoZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zZXJ2ZXIgaXMgc3VwcG9zZWQgdG8gbWFnaWNhbGx5IGNy ZWF0ZSBmb3Igc2VydmVyLXByb3ZpZGVkIHRvcG9sb2d5IGRhdGEuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRoZXJlIGlzIG5vdGhpbmcgaW4gTkFDTSBhdCBhbGwgYWJvdXQgc2VydmVy LWNyZWF0ZWQgZGF0YSBydWxlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBp cyBub3Qgc3VwcG9ydGVkIGJ5IE5BQ00uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5Eb2VzIHRoZSBJMlJTIHRleHQgaW1wbHkgdGhhdCB0aGUgc2VydmVyLXByb3ZpZGVkIHByb3Bl cnR5IGV4dGVuZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+dG8gdGhlIE5BQ00gc3Vi LXRyZWVzPyBUaGV5IGFyZSBhbHNvIHN1YmplY3QgdG8gcmVwbGFjZW1lbnQgYnkgdGhlIHNlcnZl cj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGNsaWVudCBTSE9VTEQgTk9UIGNo YW5nZSB0aGVzZSBOQUNNIHJ1bGVzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ SU1PIHRoZSB3YXkgdGhpcyBzZXJ2ZXItcHJvdmlkZWQgcHJvcGVydHkgaXMgYmVpbmcgZG9uZSBp cyBhIHNob3J0LXNpZ2h0ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+cG9pbnQgc29s dXRpb24sIGJ1dCB0aGlzIHNob3VsZCBiZSBhIGZ1bmRhbWVudGFsIHBhcnQgb2YgdGhlIHJldmlz ZWQgZGF0YXN0b3JlcyB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JcyB0aGVy ZSBzb21ldGhpbmcgc3BlY2lhbCBhYm91dCBuZXR3b3JrIHRvcG9sb2d5IHN1Y2ggdGhhdDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zZXJ2ZXItcHJvdmlkZWQgZGF0YSBmb3IgYSBkaWZm ZXJlbnQgbW9kdWxlIHdpbGwgcmVxdWlyZSBhIGRpZmZlcmVudDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5zb2x1dGlvbj8gSWYgbm90LCBpcyB0aGUgdG9wbyBtb2R1bGUgc29sdXRpb24g cmV1c2FibGU/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbmR5PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1SJCEML703CHMchi_-- From nobody Thu Feb 16 14:36:44 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184E6124281 for ; Thu, 16 Feb 2017 14:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve-2wXNhJrUp for ; Thu, 16 Feb 2017 14:36:37 -0800 (PST) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5CB129556 for ; Thu, 16 Feb 2017 14:36:36 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id z61so20735592wrc.1 for ; Thu, 16 Feb 2017 14:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pGJB1xHT/b5UOOdmWMHjajJSeAxBFE43V45PIQOFG1Y=; b=YOskBybUtVTYERa4/OnKCGshm0K5fXpXuynvKl5z3hHsOnxvjalc827QO85mtICHNl ycu/Q6IqWu5QcscKXVSNPd8QMLqtc35khcRWmu0E6oj+IldbNHKIwMlD5LdSvRpKStId GH2gcaHw4eesdHCIc6AmpaXSJFm4IYNGwIUMcOAyV8kl/7CURq25bLyEJ9krm99h6Xec 1/XunpP35d9VIUsFjla8svYu+D6S1Fz3oSBRChLPA9tqn4I32ohoURa78S5sAU2qzrZ2 GZIgcVmZQ24RZuORmFzZpjz2xex3d6oI+Bj8b75Fk9FHII1dHqiRjRgYPA5NWacNlMaC 1v3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pGJB1xHT/b5UOOdmWMHjajJSeAxBFE43V45PIQOFG1Y=; b=sXfZeNWuiYCjTd/oKW1Utnw4IoXipJW6q9OzmF2K/NgFEtFdmbeMbmAqdkKMzH3DjZ NFW7TeXZqTqaDzSCIUA2yEdtr/gZfos1VRHqLek0zZQfMyXHixhAuHDmDCDW9lME/AbK VYdiI52DOKZ9l7r+HvJOi2rFNme2MnsqGD8D2nQ3jOHdpebYY5aNOWc0cz6JEYO3QL8J cJNb9MLf5iq1i+a4bxB7k4bBdPa8zLRVz4/Cc6R6Z0oSsDE+vGbz4Q+PaCBJHQEvdLLz 4gb4C+YT90sR5z++5vXLUeBG0wsm0N/MrwVXO2QMdYk1XHh3wdHX07Z8WCax5l9YxjWo cPMg== X-Gm-Message-State: AMke39kGE4axiClZe9cW39M5AO9m7CZ6BLE/tmvfuj+AqvzSHcbBiYk9YD+LSit8c3jNinOOql62jVKmTu9ilw== X-Received: by 10.223.165.17 with SMTP id i17mr4685962wrb.62.1487284594997; Thu, 16 Feb 2017 14:36:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Thu, 16 Feb 2017 14:36:34 -0800 (PST) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1@SJCEML703-CHM.china.huawei.com> References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1@SJCEML703-CHM.china.huawei.com> From: Andy Bierman Date: Thu, 16 Feb 2017 14:36:34 -0800 Message-ID: To: Alexander Clemm Content-Type: multipart/alternative; boundary=f403045f1fb0f72e860548ad6d33 Archived-At: Cc: "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:36:40 -0000 --f403045f1fb0f72e860548ad6d33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm wrote: > There are actually a number of interesting implications with regards to > NACM. NACM could indeed be a key to the solution if it provides sufficie= nt > flexibility with regards to articulating and enforcing authorization > rules. Regarding this, I have a number of questions/comments: > > > > - If a subtree contains objects that a client does not have > write privileges for, will the client be prevented from locking the > subtree? How about the case when the client does not even have read > privileges? > locking and NACM are 2 different things. NETCONF has datastore (global) locks and subtree (partial) locks. There is no mechanism in NACM or elsewhere that constrains the values that a particular client can use. (NACM controls access to the rpc, with no control over specific input paramters). > > The current NACM-bis draft states in section 3.7.2 that this is not the > case =E2=80=93 i.e. a client is able to lock an entire subtree, even in c= ases when > there is not a single object in that subtree that the client actually has > access privileges to. > > > > To me, this does not seem right. It just invites abuse. > > > > Now, there is still the possibility to restrict access to the operation > overall. But again, this means that you have to give a users an > all-or-nothing choice. Too inflexible. By the same token that partial > locks were supported to avoid requiring anyone who needs the ability to > conduct a transaction to lock down the entire server, there should be the > ability to restrict access to the lock and partial-lock operation by > targeted subtree. However, this capability is currently missing. > NACM was designed to be simple to implement. Some complex features that were in VACM were intentionally left out of NACM= . NETCONF locking is also intentionally simple. I would rather have NETCONF 2.0 use a mandatory implicit, optimistic concurrent locking model, rather than more band-aids on the optional explicit, pessimistic serialized locking model we have now. > > - Where can NACM rules originate from? The current model seems > to assume that rules will always be explicitly configured from an externa= l > client and constitute part of configuration. Now, what about the case whe= n > rules are to be enforced automatically by the server? I think NACM shou= ld > allow for that, and having a mix of both. (The server-provided topologie= s > are one potential example where this would be very useful. In fact, if > this capability were supported, I don=E2=80=99t think we would be having = the > server-provided discussion in the topology context =E2=80=93 NACM would b= e all we > need. However, there are other use cases for this. Think e.g. an > intrusion protection component on the server, that you would not want to > override by an external user administration client application that you > would still want to allow as well. Or cases when some authorizations get > signaled, e.g. in the case of autonomic peer-to-peer type of applications= .) > > I don't think any YANG configuration module precludes server-created entries. The configuration is created somehow. The YANG module discusses the data model instances without saying how they got there. > > > --- Alex > Andy > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Thursday, February 16, 2017 12:49 PM > *To:* Susan Hares > *Cc:* i2rs@ietf.org > *Subject:* Re: [i2rs] topo model use of NACM > > > > Hi, > > > > I am most concerned about getting the architecture right. > > We have ignored server-created nodes until now. > > I am glad I2RS WG is trying to deal with the problem. > > Just make sure we have a reusable solution. > > > > Also concerned about tool automation. > > There was some discussion of a 'server-created' extension at some point I > think. > > This would help, because the server-created leaf is not really > deterministic. > > It is just a convention. > > > > e.g. > > > > > > container networks { > > list network { > > i2rs:server-created; > > ... > > leaf server-created { ... } > > ... > > } > > } > > > > > > Andy > > > > > > On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares wrote: > > Andy: > > > > > > AFAIK =E2=80=93 I believe the revised data store model is right approach.= It is > an important question to ask whether the ability to have a mixture of > =E2=80=9Cserver-provided=E2=80=9D and =E2=80=9Cconfigured=E2=80=9D is imp= ortant for all topology models. I > hope Xufeng and other topology models will comment on this point. > > > > > > Does the NETCONF data store in the revised data-store future include the > control plane data stores? I thought the answer was =E2=80=9Cno=E2=80=9D = it does not. > Here=E2=80=99s some text from draft-ietf-netconf-rfc6536bis that leads m= e to > believe that > > > > On NACM, draft-ietf-netconf-rfc6536bis it says: > > > > It is necessary to control access to specific nodes and subtrees > > within the NETCONF datastore, regardless of which protocol operation, > > standard or proprietary, was used to access the datastore. > > > 3.2 > . > Datastore Access > > The same access control rules apply to all datastores, for example, > > the candidate configuration datastore or the running configuration > > datastore. > > > > Only the standard NETCONF datastores (candidate, running, and > > startup) are controlled by NACM. Local or remote files or datastores > > accessed via the parameter are not controlled by NACM. A > > standalone RESTCONF server (i.e., not co-located with a NETCONF > > server) applies NACM rules to a conceptual datastore, since > > datastores are not supported in RESTCONF. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > The I2RS security environment actually looks at 3 policies on the server > > > > Network Access =C3=9F-=C3=A0 server =C3=9F-=C3=A0 routing-system access > > (aka I2RS agent) > > |=C3=9F=C3=A0 System access > > > > It also looks at application access to the client > > > > Network access=C3=9F=C3=A0 client =C3=9F=C3=A0 application-access > > > > > > The protocol only needs to consider the NACM Access, but the routing > infrastructure need to consider the server to/from routing system, and > server to/from system. My understanding is that the Routing system acces= s > control module (RACM) and the system access control module (SACM) functio= ns > were not in NACM. > > > > Thanks again for posting, > > > > Sue > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Thursday, February 16, 2017 2:00 PM > *To:* i2rs@ietf.org > *Subject:* [i2rs] topo model use of NACM > > > > Hi, > > > > The use of NACM for server-provided data is under-specified (at best) > > > > > > from sec. 4.1: > > > > Finally, there is an object "server-provided". This object is state > > that indicates how the network came into being. Network data can > > come into being in one of two ways. In one way, network data is > > configured by client applications, for example in case of overlay > > networks that are configured by an SDN Controller application. In > > annother way, it is populated by the server, in case of networks that > > can be discovered. > > > > If server-provided is set to false, the network was configured by a > > client application, for example in the case of an overlay network > > that is configured by a controller application. If server-provided > > is set to true, the network was populated by the server itself, > > respectively an application on the server that is able to discover > > the network. *Client applications SHOULD NOT modify configurations of= * > > * networks for which "server-provided" is true.* When they do, they > > need to be aware that any modifications they make are subject to be > > reverted by the server. For servers that support NACM (Netconf > > Access Control Model), *data node rules should ideally prevent* write > > access by other clients to network instances for which server- > > provided is set to true. > > > > The SHOULD NOT above is really odd, considering is not supported by YANG > > or the NC/RC protocols. > > > > "data node rules should ideally prevent" > > > > s/should/SHOULD/ > > > > Ideally prevent? > > Is that a new engineering term? > > Either this new usage of NACM works or it doesn't. > > > > Also, there is no guidance or examples of the NACM config that the > > server is supposed to magically create for server-provided topology data. > > There is nothing in NACM at all about server-created data rules. > > This is not supported by NACM. > > > > Does the I2RS text imply that the server-provided property extends > > to the NACM sub-trees? They are also subject to replacement by the server= ? > > The client SHOULD NOT change these NACM rules? > > > > IMO the way this server-provided property is being done is a short-sighte= d > > point solution, but this should be a fundamental part of the revised > datastores work. > > Is there something special about network topology such that > > server-provided data for a different module will require a different > > solution? If not, is the topo module solution reusable? > > > > > > Andy > > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --f403045f1fb0f72e860548ad6d33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <= alexander.c= lemm@huawei.com> wrote:

There are actually a number of intere= sting implications with regards to NACM.=C2=A0 NACM could indeed be a key t= o the solution if it provides sufficient flexibility with regards to articulating and enforcing authorization rules.=C2=A0 Rega= rding this, I have a number of questions/comments:

=C2=A0

<= span>-=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a subtree contains objects th= at a client does not have write privileges for, will the client be prevente= d from locking the subtree? How about the case when the client does not even have read privileges?=C2=A0

<= /div>

locking and NACM are 2 differen= t things.
NETCONF has datastore (global) locks and subtree (parti= al) locks.
There is no mechanism in NACM or elsewhere that constr= ains the values
that a particular client can use. (NACM controls = access to the rpc, with no
control over specific input paramters)= .




The current NACM-bis draft states in section 3.7.2 that this is not the cas= e =E2=80=93 i.e. a client is able to lock an entire subtree, even in cases = when there is not a single object in that subtree that the client actually = has access privileges to.=C2=A0

=C2=A0

To me, thi= s does not seem right.=C2=A0 It just invites abuse.=C2=A0

=C2= =A0

Now, there= is still the possibility to restrict access to the operation overall.=C2= =A0 But again, this means that you have to give a users an all-or-nothing choice.=C2=A0 Too inflexible.=C2=A0 By the same token th= at partial locks were supported to avoid requiring anyone who needs the abi= lity to conduct a transaction to lock down the entire server, there should = be the ability to restrict access to the lock and partial-lock operation by targeted subtree.=C2=A0 However, this capabi= lity is currently missing.=C2=A0


NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out= of NACM.
NETCONF locking is also intentionally simple.

I would rather have NETCONF 2.0 use a mandatory implicit, o= ptimistic concurrent
locking model, rather than more band-aids on= the optional explicit, pessimistic
serialized locking model we h= ave now.


=

=C2= =A0

<= span>-=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Where can NACM rules originate f= rom?=C2=A0 =C2=A0The current model seems to assume that rules will always b= e explicitly configured from an external client and constitute part of configuration. Now, what about the case when rules are = to be enforced automatically by the server? =C2=A0=C2=A0I think NACM should= allow for that, and having a mix of both. =C2=A0(The server-provided topol= ogies are one potential example where this would be very useful.=C2=A0 In fact, if this capability were supported, I don=E2= =80=99t think we would be having the server-provided discussion in the topo= logy context =E2=80=93 NACM would be all we need.=C2=A0 However, there are = other use cases for this.=C2=A0 Think e.g. an intrusion protection component on the server, that you would not want to override by an externa= l user administration client application that you would still want to allow= as well.=C2=A0 Or cases when some authorizations get signaled, e.g. in the= case of autonomic peer-to-peer type of applications.)


I don't think any YANG configuration module p= recludes server-created entries.
The configuration is created som= ehow.=C2=A0 The YANG module discusses the data model
instances wi= thout saying how they got there.

=C2=A0

= =C2=A0

--- Alex=C2=A0

=


Andy
=C2=A0
=

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, February 16, 2017 12:49 PM
To: Susan Hares <shares@ndzh.com>
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] topo model use of NACM

=C2=A0

Hi,

=C2=A0

I am most concerned about getting the architecture r= ight.

We have ignored server-created nodes until now.

I am glad I2RS WG is trying to deal with the problem= .

Just make sure we have a reusable solution.

=C2=A0

Also concerned about tool automation.<= /p>

There was some discussion of a 'server-created&#= 39; extension at some point I think.

This would help, because the server-created leaf is = not really deterministic.

It is just a convention.

=C2=A0

e.g.

=C2=A0

=C2=A0

=C2=A0 container networks {

=C2=A0 =C2=A0 =C2=A0list network {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs:server-create= d;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= /p>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf server-create= d { ... }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= /p>

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 }

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

<chair hat off, individual contributor hat on>= ;

=C2=A0

AFAIK =E2=80=93 I believe the revised data store mo= del is right approach. =C2=A0=C2=A0It is an important question to ask wheth= er the ability to have a mixture of =E2=80=9Cserver-provided=E2=80=9D and =E2=80= =9Cconfigured=E2=80=9D is important for all topology models.=C2=A0 I hope X= ufeng and other topology models will comment on this point.

=C2=A0

=C2=A0

Does the NETCONF data store in the revised data-store futu= re include the control plane data stores? I thought the answer was =E2=80=9Cno=E2=80=9D it does not.=C2=A0 =C2=A0Here=E2=80=99s some text= from draft-ietf-netconf-rfc6536bis that leads me to believe that

=C2=A0

On NACM, draft-ietf-netconf-rfc6536bis it says:

=C2=A0

=C2=A0=C2=A0 It is necessary to control access to specific= nodes and subtrees

=C2=A0=C2=A0 within the NETCONF datastore, regardless of w= hich protocol operation,

=C2=A0=C2=A0 standard or proprietary, was used to access t= he datastore.

=C2=A0

<= /a>3.2.=C2=A0 Datastore Access

 =C2=A0=C2=A0The same access control rules=
 apply to all datastores, for example,
=C2=A0=C2=A0 the candidate configuration d=
atastore or the running configuration
=C2=A0=C2=A0 datastore.
=C2=A0
=C2=A0=C2=A0 Only the standard NETCONF dat=
astores (candidate, running, and
=C2=A0=C2=A0 startup) are controlled by NA=
CM.=C2=A0 Local or remote files or datastores
=C2=A0=C2=A0 accessed via the <url> =
parameter are not controlled by NACM.=C2=A0 A
=C2=A0=C2=A0 standalone RESTCONF server (i=
.e., not co-located with a NETCONF
=C2=A0=C2=A0 server) applies NACM rules to=
 a conceptual datastore, since
=C2=A0=C2=A0 datastores are not supported =
in RESTCONF.

=C2=A0

=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0

The I2RS security environment actually looks at 3 policies= on the server

=C2=A0

Network Access =C3=9F= -=C3=A0 server =C3=9F= -=C3=A0 routing-sy= stem access =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0(aka I2RS agent)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C3=9F=C3=A0 System access

=C2=A0

It also looks at application access to the client

=C2=A0

=C2=A0 Network access=C3=9F=C3=A0 client =C3= =9F=C3=A0 application-access =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

=C2=A0

The protocol only needs to consider the NACM Access, but t= he routing infrastructure need to consider the server to/from routing system, and server to/from system.=C2=A0 My understanding is that = the Routing system access control module (RACM) and the system access contr= ol module (SACM) functions were not in NACM.

=C2=A0

Thanks again for posting,

=C2=A0

Sue =C2=A0

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, February 16, 2017 2:00 PM
To: i2rs@ietf.org=
Subject: [i2rs] topo model use of NACM

=C2=A0

Hi,

=C2=A0

The use of NACM for server-provided data is under-sp= ecified (at best)

=C2=A0

=C2=A0

from sec. 4.1:

=C2=A0

=C2=A0=C2=A0 Finally, there is an object "server-provided&qu=
ot;.=C2=A0 This object is state
=C2=A0=C2=A0 that indicates how the networ=
k came into being.=C2=A0 Network data can
=C2=A0=C2=A0 come into being in one of two=
 ways.=C2=A0 In one way, network data is
=C2=A0=C2=A0 configured by client applicat=
ions, for example in case of overlay
=C2=A0=C2=A0 networks that are configured =
by an SDN Controller application.=C2=A0 In
=C2=A0=C2=A0 annother way, it is populated=
 by the server, in case of networks that
=C2=A0=C2=A0 can be discovered.<=
/u>
=C2=A0
=C2=A0=C2=A0 If server-provided is set to =
false, the network was configured by a
=C2=A0=C2=A0 client application, for examp=
le in the case of an overlay network
=C2=A0=C2=A0 that is configured by a contr=
oller application.=C2=A0 If server-provided
=C2=A0=C2=A0 is set to true, the network w=
as populated by the server itself,
=C2=A0=C2=A0 respectively an application o=
n the server that is able to discover
=C2=A0=C2=A0 the network.=C2=A0 Client =
applications SHOULD NOT modify configurations of

=C2=A0=C2=A0 networks for which "s=
erver-provided" is true.=C2=A0 =
When they do, they


=C2=A0=C2=A0 need to be aware that any mod=
ifications they make are subject to be


=C2=A0=C2=A0 reverted by the server.=C2=A0=
 For servers that support NACM (Netconf


=C2=A0=C2=A0 Access Control Model), dat=
a node rules should ideally prevent write


=C2=A0=C2=A0 access by other clients to ne=
twork instances for which server-


=C2=A0=C2=A0 provided is set to true.

=C2=A0

The SHOULD NOT above is really odd, considering is n= ot supported by YANG

or the NC/RC protocols.

=C2=A0

"data node rules sh= ould ideally prevent"

=C2=A0

s/should/SHOULD/<= u>

=C2=A0

Ideally prevent?<= u>

Is that a new engineerin= g term?

Either this new usage of= NACM works or it doesn't.

=C2=A0

Also, there is no guidan= ce or examples of the NACM config that the

server is supposed to ma= gically create for server-provided topology data.

There is nothing in NACM= at all about server-created data rules.

This is not supported by= NACM.

=C2=A0

Does the I2RS text imply= that the server-provided property extends

to the NACM sub-trees? T= hey are also subject to replacement by the server?

The client SHOULD NOT ch= ange these NACM rules?

=C2=A0

IMO the way this server-= provided property is being done is a short-sighted

point solution, but this= should be a fundamental part of the revised datastores work.=

Is there something speci= al about network topology such that

server-provided data for= a different module will require a different

solution? If not, is the= topo module solution reusable?

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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


--f403045f1fb0f72e860548ad6d33-- From nobody Thu Feb 16 15:03:12 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB56129455 for ; Thu, 16 Feb 2017 15:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 i2EGdSBrO-qb for ; Thu, 16 Feb 2017 15:03:05 -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 0FF9D124281 for ; Thu, 16 Feb 2017 15:03:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAT33842; Thu, 16 Feb 2017 23:03:01 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 16 Feb 2017 22:59:06 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Thu, 16 Feb 2017 14:59:03 -0800 From: Alexander Clemm To: Andy Bierman Thread-Topic: [i2rs] topo model use of NACM Thread-Index: AQHSiIcFMhe2D11fUkesxuPxtpMzeKFskAEAgAART4D//4okMIAAk9oA//98OVA= Date: Thu, 16 Feb 2017 22:59:01 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF80A52@SJCEML703-CHM.china.huawei.com> References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1@SJCEML703-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.18] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF80A52SJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58A62FA6.0037, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2f658c86a068ad87196968b60352e9e9 Archived-At: Cc: "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:03:08 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF80A52SJCEML703CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGlubGluZSwgPEFMRVg+DQotLS0gQWxleA0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcg MjozNyBQTQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+ DQpDYzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT47IGkycnNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbaTJyc10gdG9wbyBtb2RlbCB1c2Ugb2YgTkFDTQ0KDQoNCg0KT24gVGh1LCBGZWIg MTYsIDIwMTcgYXQgMjoxOCBQTSwgQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVh d2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PiB3cm90ZToNClRoZXJl IGFyZSBhY3R1YWxseSBhIG51bWJlciBvZiBpbnRlcmVzdGluZyBpbXBsaWNhdGlvbnMgd2l0aCBy ZWdhcmRzIHRvIE5BQ00uICBOQUNNIGNvdWxkIGluZGVlZCBiZSBhIGtleSB0byB0aGUgc29sdXRp b24gaWYgaXQgcHJvdmlkZXMgc3VmZmljaWVudCBmbGV4aWJpbGl0eSB3aXRoIHJlZ2FyZHMgdG8g YXJ0aWN1bGF0aW5nIGFuZCBlbmZvcmNpbmcgYXV0aG9yaXphdGlvbiBydWxlcy4gIFJlZ2FyZGlu ZyB0aGlzLCBJIGhhdmUgYSBudW1iZXIgb2YgcXVlc3Rpb25zL2NvbW1lbnRzOg0KDQoNCi0gICAg ICAgICAgSWYgYSBzdWJ0cmVlIGNvbnRhaW5zIG9iamVjdHMgdGhhdCBhIGNsaWVudCBkb2VzIG5v dCBoYXZlIHdyaXRlIHByaXZpbGVnZXMgZm9yLCB3aWxsIHRoZSBjbGllbnQgYmUgcHJldmVudGVk IGZyb20gbG9ja2luZyB0aGUgc3VidHJlZT8gSG93IGFib3V0IHRoZSBjYXNlIHdoZW4gdGhlIGNs aWVudCBkb2VzIG5vdCBldmVuIGhhdmUgcmVhZCBwcml2aWxlZ2VzPw0KDQpsb2NraW5nIGFuZCBO QUNNIGFyZSAyIGRpZmZlcmVudCB0aGluZ3MuDQpORVRDT05GIGhhcyBkYXRhc3RvcmUgKGdsb2Jh bCkgbG9ja3MgYW5kIHN1YnRyZWUgKHBhcnRpYWwpIGxvY2tzLg0KVGhlcmUgaXMgbm8gbWVjaGFu aXNtIGluIE5BQ00gb3IgZWxzZXdoZXJlIHRoYXQgY29uc3RyYWlucyB0aGUgdmFsdWVzDQp0aGF0 IGEgcGFydGljdWxhciBjbGllbnQgY2FuIHVzZS4gKE5BQ00gY29udHJvbHMgYWNjZXNzIHRvIHRo ZSBycGMsIHdpdGggbm8NCmNvbnRyb2wgb3ZlciBzcGVjaWZpYyBpbnB1dCBwYXJhbXRlcnMpLg0K DQoNCg0KDQpUaGUgY3VycmVudCBOQUNNLWJpcyBkcmFmdCBzdGF0ZXMgaW4gc2VjdGlvbiAzLjcu MiB0aGF0IHRoaXMgaXMgbm90IHRoZSBjYXNlIOKAkyBpLmUuIGEgY2xpZW50IGlzIGFibGUgdG8g bG9jayBhbiBlbnRpcmUgc3VidHJlZSwgZXZlbiBpbiBjYXNlcyB3aGVuIHRoZXJlIGlzIG5vdCBh IHNpbmdsZSBvYmplY3QgaW4gdGhhdCBzdWJ0cmVlIHRoYXQgdGhlIGNsaWVudCBhY3R1YWxseSBo YXMgYWNjZXNzIHByaXZpbGVnZXMgdG8uDQoNClRvIG1lLCB0aGlzIGRvZXMgbm90IHNlZW0gcmln aHQuICBJdCBqdXN0IGludml0ZXMgYWJ1c2UuDQoNCk5vdywgdGhlcmUgaXMgc3RpbGwgdGhlIHBv c3NpYmlsaXR5IHRvIHJlc3RyaWN0IGFjY2VzcyB0byB0aGUgb3BlcmF0aW9uIG92ZXJhbGwuICBC dXQgYWdhaW4sIHRoaXMgbWVhbnMgdGhhdCB5b3UgaGF2ZSB0byBnaXZlIGEgdXNlcnMgYW4gYWxs LW9yLW5vdGhpbmcgY2hvaWNlLiAgVG9vIGluZmxleGlibGUuICBCeSB0aGUgc2FtZSB0b2tlbiB0 aGF0IHBhcnRpYWwgbG9ja3Mgd2VyZSBzdXBwb3J0ZWQgdG8gYXZvaWQgcmVxdWlyaW5nIGFueW9u ZSB3aG8gbmVlZHMgdGhlIGFiaWxpdHkgdG8gY29uZHVjdCBhIHRyYW5zYWN0aW9uIHRvIGxvY2sg ZG93biB0aGUgZW50aXJlIHNlcnZlciwgdGhlcmUgc2hvdWxkIGJlIHRoZSBhYmlsaXR5IHRvIHJl c3RyaWN0IGFjY2VzcyB0byB0aGUgbG9jayBhbmQgcGFydGlhbC1sb2NrIG9wZXJhdGlvbiBieSB0 YXJnZXRlZCBzdWJ0cmVlLiAgSG93ZXZlciwgdGhpcyBjYXBhYmlsaXR5IGlzIGN1cnJlbnRseSBt aXNzaW5nLg0KDQoNCk5BQ00gd2FzIGRlc2lnbmVkIHRvIGJlIHNpbXBsZSB0byBpbXBsZW1lbnQu DQpTb21lIGNvbXBsZXggZmVhdHVyZXMgdGhhdCB3ZXJlIGluIFZBQ00gd2VyZSBpbnRlbnRpb25h bGx5IGxlZnQgb3V0IG9mIE5BQ00uDQpORVRDT05GIGxvY2tpbmcgaXMgYWxzbyBpbnRlbnRpb25h bGx5IHNpbXBsZS4NCg0KSSB3b3VsZCByYXRoZXIgaGF2ZSBORVRDT05GIDIuMCB1c2UgYSBtYW5k YXRvcnkgaW1wbGljaXQsIG9wdGltaXN0aWMgY29uY3VycmVudA0KbG9ja2luZyBtb2RlbCwgcmF0 aGVyIHRoYW4gbW9yZSBiYW5kLWFpZHMgb24gdGhlIG9wdGlvbmFsIGV4cGxpY2l0LCBwZXNzaW1p c3RpYw0Kc2VyaWFsaXplZCBsb2NraW5nIG1vZGVsIHdlIGhhdmUgbm93Lg0KDQo8QUxFWD4gU2lt cGxlIGlzIGdvb2QsIGJ1dCBpdCBwdXRzIHRoZSBvbnVzIG9uIGFwcGxpY2F0aW9ucyBpZiB0aGV5 IHdhbnQgdG8gYWNjb21wbGlzaCBzb21ldGhpbmcgbW9yZSBwb3dlcmZ1bC4gIEFuZCwgdGhlcmUg aXMgdGhlIHF1ZXN0aW9uIGlmIGl0IGlzIG5vdCB0b28gc2ltcGxlLiAgVGhlICBjYXNlIG9mIGFs bG93aW5nIGFueSBjbGllbnQgKHdobyBuZWVkcyB0byBiZSBncmFudGVkIF9zb21lXyBhY2Nlc3Mp IGZyb20gbG9ja2luZyBkb3duIGVudGlyZSBjb25maWd1cmF0aW9ucyB0byBtZSBzZWVtcyBhdCBs ZWFzdCBxdWVzdGlvbmFibGU7IHRoaXMgZG9lcyBhcHBlYXIgdG8gYmUgYSBjYXNlIHdoZXJlIGl0 IHNob3VsZCBiZSBwb3NzaWJsZSB0byBkaWZmZXJlbnRpYXRlIHByaXZpbGVnZXMuDQoNCldlIGFy ZSBoYXZpbmcgdGhlIGRpc2N1c3Npb24gaW4gdGhlIGNvbnRleHQgb2YgdGhlIHRvcG9sb2d5IGRp c2N1c3Npb24uICBXaGF0IHN0YXJ0ZWQgaXQgd2FzIHRoZSBjYXNlIG9mIHRoZSBiYWNrdXAvcmVz dG9yZSBhcHBsaWNhdGlvbiB0aGF0IHdhbnRzIHRvIGJlIGFnbm9zdGljIHdpdGggcmVnYXJkcyB0 byB0aGUgZGF0YSwgeWV0IHRoYXQgY2Fubm90IGJlIGRlbmllZCBhY2Nlc3MgdG8gY2VydGFpbiBk YXRhIHRoYXQgc2hvdWxkIG5vdCBiZSBzdWJqZWN0ZWQgdG8gdGhpcyBhcHBsaWNhdGlvbi4gIElm IG5vdCBmb3IgdGhpcywgdG9wb2xvZ3kgbWlnaHQgYmUgZG9uZSBieSBub3cuICBJbiB0aGlzIGNh c2UsIHRoZSBzaW1wbGljaXR5IG9mIHRoZSBmcmFtZXdvcmsgZG9lcyBjYXVzZSBzaWduaWZpY2Fu dCBjb21wbGV4aXR5IGVsc2V3aGVyZS4NCjwvQUxFWD4NCg0KDQotICAgICAgICAgIFdoZXJlIGNh biBOQUNNIHJ1bGVzIG9yaWdpbmF0ZSBmcm9tPyAgIFRoZSBjdXJyZW50IG1vZGVsIHNlZW1zIHRv IGFzc3VtZSB0aGF0IHJ1bGVzIHdpbGwgYWx3YXlzIGJlIGV4cGxpY2l0bHkgY29uZmlndXJlZCBm cm9tIGFuIGV4dGVybmFsIGNsaWVudCBhbmQgY29uc3RpdHV0ZSBwYXJ0IG9mIGNvbmZpZ3VyYXRp b24uIE5vdywgd2hhdCBhYm91dCB0aGUgY2FzZSB3aGVuIHJ1bGVzIGFyZSB0byBiZSBlbmZvcmNl ZCBhdXRvbWF0aWNhbGx5IGJ5IHRoZSBzZXJ2ZXI/ICAgSSB0aGluayBOQUNNIHNob3VsZCBhbGxv dyBmb3IgdGhhdCwgYW5kIGhhdmluZyBhIG1peCBvZiBib3RoLiAgKFRoZSBzZXJ2ZXItcHJvdmlk ZWQgdG9wb2xvZ2llcyBhcmUgb25lIHBvdGVudGlhbCBleGFtcGxlIHdoZXJlIHRoaXMgd291bGQg YmUgdmVyeSB1c2VmdWwuICBJbiBmYWN0LCBpZiB0aGlzIGNhcGFiaWxpdHkgd2VyZSBzdXBwb3J0 ZWQsIEkgZG9u4oCZdCB0aGluayB3ZSB3b3VsZCBiZSBoYXZpbmcgdGhlIHNlcnZlci1wcm92aWRl ZCBkaXNjdXNzaW9uIGluIHRoZSB0b3BvbG9neSBjb250ZXh0IOKAkyBOQUNNIHdvdWxkIGJlIGFs bCB3ZSBuZWVkLiAgSG93ZXZlciwgdGhlcmUgYXJlIG90aGVyIHVzZSBjYXNlcyBmb3IgdGhpcy4g IFRoaW5rIGUuZy4gYW4gaW50cnVzaW9uIHByb3RlY3Rpb24gY29tcG9uZW50IG9uIHRoZSBzZXJ2 ZXIsIHRoYXQgeW91IHdvdWxkIG5vdCB3YW50IHRvIG92ZXJyaWRlIGJ5IGFuIGV4dGVybmFsIHVz ZXIgYWRtaW5pc3RyYXRpb24gY2xpZW50IGFwcGxpY2F0aW9uIHRoYXQgeW91IHdvdWxkIHN0aWxs IHdhbnQgdG8gYWxsb3cgYXMgd2VsbC4gIE9yIGNhc2VzIHdoZW4gc29tZSBhdXRob3JpemF0aW9u cyBnZXQgc2lnbmFsZWQsIGUuZy4gaW4gdGhlIGNhc2Ugb2YgYXV0b25vbWljIHBlZXItdG8tcGVl ciB0eXBlIG9mIGFwcGxpY2F0aW9ucy4pDQoNCkkgZG9uJ3QgdGhpbmsgYW55IFlBTkcgY29uZmln dXJhdGlvbiBtb2R1bGUgcHJlY2x1ZGVzIHNlcnZlci1jcmVhdGVkIGVudHJpZXMuDQpUaGUgY29u ZmlndXJhdGlvbiBpcyBjcmVhdGVkIHNvbWVob3cuICBUaGUgWUFORyBtb2R1bGUgZGlzY3Vzc2Vz IHRoZSBkYXRhIG1vZGVsDQppbnN0YW5jZXMgd2l0aG91dCBzYXlpbmcgaG93IHRoZXkgZ290IHRo ZXJlLg0KDQogPEFMRVg+IFRoZW4gd2h5IGFyZSB3ZSBjb25jZXJuZWQgaW4gdGhlIHRvcG9sb2d5 IG1vZGVsIGFib3V0IGhvdyB0aGUgZW50cmllcyBnb3QgdGhlcmU/DQo8L0FMRVg+DQoNCi0tLSBB bGV4DQoNCg0KQW5keQ0KDQoNCkZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJt YW4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAxMjo0OSBQTQ0KVG86IFN1c2Fu IEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpDYzogaTJy c0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbaTJyc10gdG9w byBtb2RlbCB1c2Ugb2YgTkFDTQ0KDQpIaSwNCg0KSSBhbSBtb3N0IGNvbmNlcm5lZCBhYm91dCBn ZXR0aW5nIHRoZSBhcmNoaXRlY3R1cmUgcmlnaHQuDQpXZSBoYXZlIGlnbm9yZWQgc2VydmVyLWNy ZWF0ZWQgbm9kZXMgdW50aWwgbm93Lg0KSSBhbSBnbGFkIEkyUlMgV0cgaXMgdHJ5aW5nIHRvIGRl YWwgd2l0aCB0aGUgcHJvYmxlbS4NCkp1c3QgbWFrZSBzdXJlIHdlIGhhdmUgYSByZXVzYWJsZSBz b2x1dGlvbi4NCg0KQWxzbyBjb25jZXJuZWQgYWJvdXQgdG9vbCBhdXRvbWF0aW9uLg0KVGhlcmUg d2FzIHNvbWUgZGlzY3Vzc2lvbiBvZiBhICdzZXJ2ZXItY3JlYXRlZCcgZXh0ZW5zaW9uIGF0IHNv bWUgcG9pbnQgSSB0aGluay4NClRoaXMgd291bGQgaGVscCwgYmVjYXVzZSB0aGUgc2VydmVyLWNy ZWF0ZWQgbGVhZiBpcyBub3QgcmVhbGx5IGRldGVybWluaXN0aWMuDQpJdCBpcyBqdXN0IGEgY29u dmVudGlvbi4NCg0KZS5nLg0KDQoNCiAgY29udGFpbmVyIG5ldHdvcmtzIHsNCiAgICAgbGlzdCBu ZXR3b3JrIHsNCiAgICAgICAgIGkycnM6c2VydmVyLWNyZWF0ZWQ7DQogICAgICAgICAuLi4NCiAg ICAgICAgIGxlYWYgc2VydmVyLWNyZWF0ZWQgeyAuLi4gfQ0KICAgICAgICAgLi4uDQogICAgIH0N CiAgfQ0KDQoNCkFuZHkNCg0KDQpPbiBUaHUsIEZlYiAxNiwgMjAxNyBhdCAxMTo0NyBBTSwgU3Vz YW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4gd3JvdGU6 DQpBbmR5Og0KPGNoYWlyIGhhdCBvZmYsIGluZGl2aWR1YWwgY29udHJpYnV0b3IgaGF0IG9uPg0K DQpBRkFJSyDigJMgSSBiZWxpZXZlIHRoZSByZXZpc2VkIGRhdGEgc3RvcmUgbW9kZWwgaXMgcmln aHQgYXBwcm9hY2guICAgSXQgaXMgYW4gaW1wb3J0YW50IHF1ZXN0aW9uIHRvIGFzayB3aGV0aGVy IHRoZSBhYmlsaXR5IHRvIGhhdmUgYSBtaXh0dXJlIG9mIOKAnHNlcnZlci1wcm92aWRlZOKAnSBh bmQg4oCcY29uZmlndXJlZOKAnSBpcyBpbXBvcnRhbnQgZm9yIGFsbCB0b3BvbG9neSBtb2RlbHMu ICBJIGhvcGUgWHVmZW5nIGFuZCBvdGhlciB0b3BvbG9neSBtb2RlbHMgd2lsbCBjb21tZW50IG9u IHRoaXMgcG9pbnQuDQoNCg0KRG9lcyB0aGUgTkVUQ09ORiBkYXRhIHN0b3JlIGluIHRoZSByZXZp c2VkIGRhdGEtc3RvcmUgZnV0dXJlIGluY2x1ZGUgdGhlIGNvbnRyb2wgcGxhbmUgZGF0YSBzdG9y ZXM/IEkgdGhvdWdodCB0aGUgYW5zd2VyIHdhcyDigJxub+KAnSBpdCBkb2VzIG5vdC4gICBIZXJl 4oCZcyBzb21lIHRleHQgZnJvbSBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcyB0aGF0IGxl YWRzIG1lIHRvIGJlbGlldmUgdGhhdA0KDQpPbiBOQUNNLCBkcmFmdC1pZXRmLW5ldGNvbmYtcmZj NjUzNmJpcyBpdCBzYXlzOg0KDQogICBJdCBpcyBuZWNlc3NhcnkgdG8gY29udHJvbCBhY2Nlc3Mg dG8gc3BlY2lmaWMgbm9kZXMgYW5kIHN1YnRyZWVzDQogICB3aXRoaW4gdGhlIE5FVENPTkYgZGF0 YXN0b3JlLCByZWdhcmRsZXNzIG9mIHdoaWNoIHByb3RvY29sIG9wZXJhdGlvbiwNCiAgIHN0YW5k YXJkIG9yIHByb3ByaWV0YXJ5LCB3YXMgdXNlZCB0byBhY2Nlc3MgdGhlIGRhdGFzdG9yZS4NCg0K My4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUz NmJpcy0wMCNzZWN0aW9uLTMuMj4uICBEYXRhc3RvcmUgQWNjZXNzDQoNCiAgIFRoZSBzYW1lIGFj Y2VzcyBjb250cm9sIHJ1bGVzIGFwcGx5IHRvIGFsbCBkYXRhc3RvcmVzLCBmb3IgZXhhbXBsZSwN Cg0KICAgdGhlIGNhbmRpZGF0ZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBvciB0aGUgcnVubmlu ZyBjb25maWd1cmF0aW9uDQoNCiAgIGRhdGFzdG9yZS4NCg0KDQoNCiAgIE9ubHkgdGhlIHN0YW5k YXJkIE5FVENPTkYgZGF0YXN0b3JlcyAoY2FuZGlkYXRlLCBydW5uaW5nLCBhbmQNCg0KICAgc3Rh cnR1cCkgYXJlIGNvbnRyb2xsZWQgYnkgTkFDTS4gIExvY2FsIG9yIHJlbW90ZSBmaWxlcyBvciBk YXRhc3RvcmVzDQoNCiAgIGFjY2Vzc2VkIHZpYSB0aGUgPHVybD4gcGFyYW1ldGVyIGFyZSBub3Qg Y29udHJvbGxlZCBieSBOQUNNLiAgQQ0KDQogICBzdGFuZGFsb25lIFJFU1RDT05GIHNlcnZlciAo aS5lLiwgbm90IGNvLWxvY2F0ZWQgd2l0aCBhIE5FVENPTkYNCg0KICAgc2VydmVyKSBhcHBsaWVz IE5BQ00gcnVsZXMgdG8gYSBjb25jZXB0dWFsIGRhdGFzdG9yZSwgc2luY2UNCg0KICAgZGF0YXN0 b3JlcyBhcmUgbm90IHN1cHBvcnRlZCBpbiBSRVNUQ09ORi4NCg0KDQo9PT09PT09PT09PQ0KDQpU aGUgSTJSUyBzZWN1cml0eSBlbnZpcm9ubWVudCBhY3R1YWxseSBsb29rcyBhdCAzIHBvbGljaWVz IG9uIHRoZSBzZXJ2ZXINCg0KTmV0d29yayBBY2Nlc3MgPC0tLS0tPiBzZXJ2ZXIgPC0tLS0tPiBy b3V0aW5nLXN5c3RlbSBhY2Nlc3MNCiAgICAgICAgICAgICAgKGFrYSBJMlJTIGFnZW50KQ0KICAg ICAgICAgICAgICAgICAgICB8PC0tLS0+IFN5c3RlbSBhY2Nlc3MNCg0KSXQgYWxzbyBsb29rcyBh dCBhcHBsaWNhdGlvbiBhY2Nlc3MgdG8gdGhlIGNsaWVudA0KDQogIE5ldHdvcmsgYWNjZXNzPC0t LS0+IGNsaWVudCA8LS0tLT4gYXBwbGljYXRpb24tYWNjZXNzDQoNCg0KVGhlIHByb3RvY29sIG9u bHkgbmVlZHMgdG8gY29uc2lkZXIgdGhlIE5BQ00gQWNjZXNzLCBidXQgdGhlIHJvdXRpbmcgaW5m cmFzdHJ1Y3R1cmUgbmVlZCB0byBjb25zaWRlciB0aGUgc2VydmVyIHRvL2Zyb20gcm91dGluZyBz eXN0ZW0sIGFuZCBzZXJ2ZXIgdG8vZnJvbSBzeXN0ZW0uICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRo YXQgdGhlIFJvdXRpbmcgc3lzdGVtIGFjY2VzcyBjb250cm9sIG1vZHVsZSAoUkFDTSkgYW5kIHRo ZSBzeXN0ZW0gYWNjZXNzIGNvbnRyb2wgbW9kdWxlIChTQUNNKSBmdW5jdGlvbnMgd2VyZSBub3Qg aW4gTkFDTS4NCg0KVGhhbmtzIGFnYWluIGZvciBwb3N0aW5nLA0KDQpTdWUNCg0KRnJvbTogaTJy cyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aTJycy1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5 IDE2LCAyMDE3IDI6MDAgUE0NClRvOiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3Jn Pg0KU3ViamVjdDogW2kycnNdIHRvcG8gbW9kZWwgdXNlIG9mIE5BQ00NCg0KSGksDQoNClRoZSB1 c2Ugb2YgTkFDTSBmb3Igc2VydmVyLXByb3ZpZGVkIGRhdGEgaXMgdW5kZXItc3BlY2lmaWVkIChh dCBiZXN0KQ0KDQoNCmZyb20gc2VjLiA0LjE6DQoNCg0KICAgRmluYWxseSwgdGhlcmUgaXMgYW4g b2JqZWN0ICJzZXJ2ZXItcHJvdmlkZWQiLiAgVGhpcyBvYmplY3QgaXMgc3RhdGUNCg0KICAgdGhh dCBpbmRpY2F0ZXMgaG93IHRoZSBuZXR3b3JrIGNhbWUgaW50byBiZWluZy4gIE5ldHdvcmsgZGF0 YSBjYW4NCg0KICAgY29tZSBpbnRvIGJlaW5nIGluIG9uZSBvZiB0d28gd2F5cy4gIEluIG9uZSB3 YXksIG5ldHdvcmsgZGF0YSBpcw0KDQogICBjb25maWd1cmVkIGJ5IGNsaWVudCBhcHBsaWNhdGlv bnMsIGZvciBleGFtcGxlIGluIGNhc2Ugb2Ygb3ZlcmxheQ0KDQogICBuZXR3b3JrcyB0aGF0IGFy ZSBjb25maWd1cmVkIGJ5IGFuIFNETiBDb250cm9sbGVyIGFwcGxpY2F0aW9uLiAgSW4NCg0KICAg YW5ub3RoZXIgd2F5LCBpdCBpcyBwb3B1bGF0ZWQgYnkgdGhlIHNlcnZlciwgaW4gY2FzZSBvZiBu ZXR3b3JrcyB0aGF0DQoNCiAgIGNhbiBiZSBkaXNjb3ZlcmVkLg0KDQoNCg0KICAgSWYgc2VydmVy LXByb3ZpZGVkIGlzIHNldCB0byBmYWxzZSwgdGhlIG5ldHdvcmsgd2FzIGNvbmZpZ3VyZWQgYnkg YQ0KDQogICBjbGllbnQgYXBwbGljYXRpb24sIGZvciBleGFtcGxlIGluIHRoZSBjYXNlIG9mIGFu IG92ZXJsYXkgbmV0d29yaw0KDQogICB0aGF0IGlzIGNvbmZpZ3VyZWQgYnkgYSBjb250cm9sbGVy IGFwcGxpY2F0aW9uLiAgSWYgc2VydmVyLXByb3ZpZGVkDQoNCiAgIGlzIHNldCB0byB0cnVlLCB0 aGUgbmV0d29yayB3YXMgcG9wdWxhdGVkIGJ5IHRoZSBzZXJ2ZXIgaXRzZWxmLA0KDQogICByZXNw ZWN0aXZlbHkgYW4gYXBwbGljYXRpb24gb24gdGhlIHNlcnZlciB0aGF0IGlzIGFibGUgdG8gZGlz Y292ZXINCg0KICAgdGhlIG5ldHdvcmsuICBDbGllbnQgYXBwbGljYXRpb25zIFNIT1VMRCBOT1Qg bW9kaWZ5IGNvbmZpZ3VyYXRpb25zIG9mDQoNCiAgIG5ldHdvcmtzIGZvciB3aGljaCAic2VydmVy LXByb3ZpZGVkIiBpcyB0cnVlLiAgV2hlbiB0aGV5IGRvLCB0aGV5DQoNCiAgIG5lZWQgdG8gYmUg YXdhcmUgdGhhdCBhbnkgbW9kaWZpY2F0aW9ucyB0aGV5IG1ha2UgYXJlIHN1YmplY3QgdG8gYmUN Cg0KICAgcmV2ZXJ0ZWQgYnkgdGhlIHNlcnZlci4gIEZvciBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCBO QUNNIChOZXRjb25mDQoNCiAgIEFjY2VzcyBDb250cm9sIE1vZGVsKSwgZGF0YSBub2RlIHJ1bGVz IHNob3VsZCBpZGVhbGx5IHByZXZlbnQgd3JpdGUNCg0KICAgYWNjZXNzIGJ5IG90aGVyIGNsaWVu dHMgdG8gbmV0d29yayBpbnN0YW5jZXMgZm9yIHdoaWNoIHNlcnZlci0NCg0KICAgcHJvdmlkZWQg aXMgc2V0IHRvIHRydWUuDQoNClRoZSBTSE9VTEQgTk9UIGFib3ZlIGlzIHJlYWxseSBvZGQsIGNv bnNpZGVyaW5nIGlzIG5vdCBzdXBwb3J0ZWQgYnkgWUFORw0Kb3IgdGhlIE5DL1JDIHByb3RvY29s cy4NCg0KImRhdGEgbm9kZSBydWxlcyBzaG91bGQgaWRlYWxseSBwcmV2ZW50Ig0KDQpzL3Nob3Vs ZC9TSE9VTEQvDQoNCklkZWFsbHkgcHJldmVudD8NCklzIHRoYXQgYSBuZXcgZW5naW5lZXJpbmcg dGVybT8NCkVpdGhlciB0aGlzIG5ldyB1c2FnZSBvZiBOQUNNIHdvcmtzIG9yIGl0IGRvZXNuJ3Qu DQoNCkFsc28sIHRoZXJlIGlzIG5vIGd1aWRhbmNlIG9yIGV4YW1wbGVzIG9mIHRoZSBOQUNNIGNv bmZpZyB0aGF0IHRoZQ0Kc2VydmVyIGlzIHN1cHBvc2VkIHRvIG1hZ2ljYWxseSBjcmVhdGUgZm9y IHNlcnZlci1wcm92aWRlZCB0b3BvbG9neSBkYXRhLg0KVGhlcmUgaXMgbm90aGluZyBpbiBOQUNN IGF0IGFsbCBhYm91dCBzZXJ2ZXItY3JlYXRlZCBkYXRhIHJ1bGVzLg0KVGhpcyBpcyBub3Qgc3Vw cG9ydGVkIGJ5IE5BQ00uDQoNCkRvZXMgdGhlIEkyUlMgdGV4dCBpbXBseSB0aGF0IHRoZSBzZXJ2 ZXItcHJvdmlkZWQgcHJvcGVydHkgZXh0ZW5kcw0KdG8gdGhlIE5BQ00gc3ViLXRyZWVzPyBUaGV5 IGFyZSBhbHNvIHN1YmplY3QgdG8gcmVwbGFjZW1lbnQgYnkgdGhlIHNlcnZlcj8NClRoZSBjbGll bnQgU0hPVUxEIE5PVCBjaGFuZ2UgdGhlc2UgTkFDTSBydWxlcz8NCg0KSU1PIHRoZSB3YXkgdGhp cyBzZXJ2ZXItcHJvdmlkZWQgcHJvcGVydHkgaXMgYmVpbmcgZG9uZSBpcyBhIHNob3J0LXNpZ2h0 ZWQNCnBvaW50IHNvbHV0aW9uLCBidXQgdGhpcyBzaG91bGQgYmUgYSBmdW5kYW1lbnRhbCBwYXJ0 IG9mIHRoZSByZXZpc2VkIGRhdGFzdG9yZXMgd29yay4NCklzIHRoZXJlIHNvbWV0aGluZyBzcGVj aWFsIGFib3V0IG5ldHdvcmsgdG9wb2xvZ3kgc3VjaCB0aGF0DQpzZXJ2ZXItcHJvdmlkZWQgZGF0 YSBmb3IgYSBkaWZmZXJlbnQgbW9kdWxlIHdpbGwgcmVxdWlyZSBhIGRpZmZlcmVudA0Kc29sdXRp b24/IElmIG5vdCwgaXMgdGhlIHRvcG8gbW9kdWxlIHNvbHV0aW9uIHJldXNhYmxlPw0KDQoNCkFu ZHkNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KaTJycyBtYWlsaW5nIGxpc3QNCmkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF80A52SJCEML703CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwLm0tMTU4NDE2NzI5ODM4MDQ3MzY2MW1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tMTU4NDE2 NzI5ODM4MDQ3MzY2MW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTE1ODQxNjcyOTgzODA0NzM2NjFt c29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTE1ODQxNjcyOTgzODA0NzM2NjFt c29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglm b250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0RDc4O30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLCBpbmxpbmUsDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPiZsdDtBTEVYJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tLSBBbGV4PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFu ZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcgMjozNyBQTTxicj4NCjxiPlRvOjwvYj4gQWxl eGFuZGVyIENsZW1tICZsdDthbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IFN1c2FuIEhhcmVzICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7OyBpMnJzQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaTJyc10gdG9wbyBtb2RlbCB1c2Ugb2YgTkFDTTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRmViIDE2LCAyMDE3IGF0IDI6MTggUE0s IEFsZXhhbmRlciBDbGVtbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3 ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGFy ZSBhY3R1YWxseSBhIG51bWJlciBvZiBpbnRlcmVzdGluZyBpbXBsaWNhdGlvbnMgd2l0aCByZWdh cmRzIHRvIE5BQ00uJm5ic3A7IE5BQ00gY291bGQgaW5kZWVkIGJlDQogYSBrZXkgdG8gdGhlIHNv bHV0aW9uIGlmIGl0IHByb3ZpZGVzIHN1ZmZpY2llbnQgZmxleGliaWxpdHkgd2l0aCByZWdhcmRz IHRvIGFydGljdWxhdGluZyBhbmQgZW5mb3JjaW5nIGF1dGhvcml6YXRpb24gcnVsZXMuJm5ic3A7 IFJlZ2FyZGluZyB0aGlzLCBJIGhhdmUgYSBudW1iZXIgb2YgcXVlc3Rpb25zL2NvbW1lbnRzOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTE1ODQxNjcyOTgzODA0NzM2NjFtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBhIHN1YnRy ZWUgY29udGFpbnMgb2JqZWN0cyB0aGF0IGEgY2xpZW50IGRvZXMgbm90IGhhdmUgd3JpdGUgcHJp dmlsZWdlcyBmb3IsIHdpbGwgdGhlIGNsaWVudCBiZSBwcmV2ZW50ZWQgZnJvbSBsb2NraW5nIHRo ZSBzdWJ0cmVlPyBIb3cgYWJvdXQgdGhlIGNhc2Ugd2hlbiB0aGUgY2xpZW50IGRvZXMNCiBub3Qg ZXZlbiBoYXZlIHJlYWQgcHJpdmlsZWdlcz8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+bG9ja2luZyBhbmQgTkFDTSBhcmUgMiBkaWZmZXJlbnQgdGhpbmdzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TkVUQ09ORiBoYXMgZGF0YXN0 b3JlIChnbG9iYWwpIGxvY2tzIGFuZCBzdWJ0cmVlIChwYXJ0aWFsKSBsb2Nrcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG5vIG1l Y2hhbmlzbSBpbiBOQUNNIG9yIGVsc2V3aGVyZSB0aGF0IGNvbnN0cmFpbnMgdGhlIHZhbHVlczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCBh IHBhcnRpY3VsYXIgY2xpZW50IGNhbiB1c2UuIChOQUNNIGNvbnRyb2xzIGFjY2VzcyB0byB0aGUg cnBjLCB3aXRoIG5vPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5jb250cm9sIG92ZXIgc3BlY2lmaWMgaW5wdXQgcGFyYW10ZXJzKS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJt LTE1ODQxNjcyOTgzODA0NzM2NjFtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PGJyPg0KPGJyPg0KVGhlIGN1cnJlbnQgTkFDTS1iaXMgZHJhZnQgc3RhdGVz IGluIHNlY3Rpb24gMy43LjIgdGhhdCB0aGlzIGlzIG5vdCB0aGUgY2FzZSDigJMgaS5lLiBhIGNs aWVudCBpcyBhYmxlIHRvIGxvY2sgYW4gZW50aXJlIHN1YnRyZWUsIGV2ZW4gaW4gY2FzZXMgd2hl biB0aGVyZSBpcyBub3QgYSBzaW5nbGUgb2JqZWN0IGluIHRoYXQgc3VidHJlZSB0aGF0IHRoZSBj bGllbnQgYWN0dWFsbHkgaGFzIGFjY2VzcyBwcml2aWxlZ2VzIHRvLiZuYnNwOw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRvIG1lLCB0aGlzIGRvZXMgbm90IHNlZW0gcmlnaHQuJm5ic3A7IEl0IGp1c3QgaW52aXRlcyBh YnVzZS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm93LCB0aGVyZSBpcyBz dGlsbCB0aGUgcG9zc2liaWxpdHkgdG8gcmVzdHJpY3QgYWNjZXNzIHRvIHRoZSBvcGVyYXRpb24g b3ZlcmFsbC4mbmJzcDsgQnV0IGFnYWluLCB0aGlzIG1lYW5zIHRoYXQgeW91IGhhdmUgdG8gZ2l2 ZSBhIHVzZXJzIGFuIGFsbC1vci1ub3RoaW5nIGNob2ljZS4mbmJzcDsgVG9vIGluZmxleGlibGUu Jm5ic3A7IEJ5DQogdGhlIHNhbWUgdG9rZW4gdGhhdCBwYXJ0aWFsIGxvY2tzIHdlcmUgc3VwcG9y dGVkIHRvIGF2b2lkIHJlcXVpcmluZyBhbnlvbmUgd2hvIG5lZWRzIHRoZSBhYmlsaXR5IHRvIGNv bmR1Y3QgYSB0cmFuc2FjdGlvbiB0byBsb2NrIGRvd24gdGhlIGVudGlyZSBzZXJ2ZXIsIHRoZXJl IHNob3VsZCBiZSB0aGUgYWJpbGl0eSB0byByZXN0cmljdCBhY2Nlc3MgdG8gdGhlIGxvY2sgYW5k IHBhcnRpYWwtbG9jayBvcGVyYXRpb24gYnkgdGFyZ2V0ZWQgc3VidHJlZS4mbmJzcDsNCiBIb3dl dmVyLCB0aGlzIGNhcGFiaWxpdHkgaXMgY3VycmVudGx5IG1pc3NpbmcuJm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TkFDTSB3YXMgZGVzaWduZWQgdG8gYmUgc2ltcGxlIHRvIGlt cGxlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvbWUgY29tcGxleCBmZWF0dXJlcyB0aGF0IHdlcmUgaW4gVkFDTSB3ZXJlIGludGVudGlv bmFsbHkgbGVmdCBvdXQgb2YgTkFDTS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk5FVENPTkYgbG9ja2luZyBpcyBhbHNvIGludGVudGlvbmFsbHkg c2ltcGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHdvdWxkIHJhdGhlciBoYXZlIE5FVENPTkYgMi4wIHVzZSBhIG1hbmRhdG9yeSBpbXBs aWNpdCwgb3B0aW1pc3RpYyBjb25jdXJyZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5sb2NraW5nIG1vZGVsLCByYXRoZXIgdGhhbiBtb3JlIGJh bmQtYWlkcyBvbiB0aGUgb3B0aW9uYWwgZXhwbGljaXQsIHBlc3NpbWlzdGljPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZXJpYWxpemVkIGxvY2tp bmcgbW9kZWwgd2UgaGF2ZSBub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj4mbHQ7QUxFWCZn dDsgU2ltcGxlIGlzIGdvb2QsIGJ1dCBpdCBwdXRzIHRoZSBvbnVzIG9uIGFwcGxpY2F0aW9ucyBp ZiB0aGV5IHdhbnQgdG8gYWNjb21wbGlzaCBzb21ldGhpbmcgbW9yZSBwb3dlcmZ1bC4mbmJzcDsg QW5kLCB0aGVyZSBpcyB0aGUgcXVlc3Rpb24gaWYgaXQgaXMgbm90IHRvbyBzaW1wbGUuJm5ic3A7 IFRoZSZuYnNwOyBjYXNlIG9mIGFsbG93aW5nIGFueSBjbGllbnQgKHdobyBuZWVkcw0KIHRvIGJl IGdyYW50ZWQgXzxpPnNvbWU8L2k+XyBhY2Nlc3MpIGZyb20gbG9ja2luZyBkb3duIGVudGlyZSBj b25maWd1cmF0aW9ucyB0byBtZSBzZWVtcyBhdCBsZWFzdCBxdWVzdGlvbmFibGU7IHRoaXMgZG9l cyBhcHBlYXIgdG8gYmUgYSBjYXNlIHdoZXJlIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBkaWZm ZXJlbnRpYXRlIHByaXZpbGVnZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIw NTAiPldlIGFyZSBoYXZpbmcgdGhlIGRpc2N1c3Npb24gaW4gdGhlIGNvbnRleHQgb2YgdGhlIHRv cG9sb2d5IGRpc2N1c3Npb24uJm5ic3A7IFdoYXQgc3RhcnRlZCBpdCB3YXMgdGhlIGNhc2Ugb2Yg dGhlIGJhY2t1cC9yZXN0b3JlIGFwcGxpY2F0aW9uIHRoYXQgd2FudHMgdG8gYmUgYWdub3N0aWMg d2l0aCByZWdhcmRzIHRvIHRoZSBkYXRhLCB5ZXQgdGhhdCBjYW5ub3QgYmUgZGVuaWVkDQogYWNj ZXNzIHRvIGNlcnRhaW4gZGF0YSB0aGF0IHNob3VsZCBub3QgYmUgc3ViamVjdGVkIHRvIHRoaXMg YXBwbGljYXRpb24uJm5ic3A7IElmIG5vdCBmb3IgdGhpcywgdG9wb2xvZ3kgbWlnaHQgYmUgZG9u ZSBieSBub3cuJm5ic3A7IEluIHRoaXMgY2FzZSwgdGhlIHNpbXBsaWNpdHkgb2YgdGhlIGZyYW1l d29yayBkb2VzIGNhdXNlIHNpZ25pZmljYW50IGNvbXBsZXhpdHkgZWxzZXdoZXJlLiZuYnNwOw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMEIwNTAiPiZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS0xNTg0MTY3Mjk4MzgwNDczNjYxbXNv bGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hlcmUgY2FuIE5BQ00gcnVsZXMgb3JpZ2luYXRlIGZyb20/ Jm5ic3A7ICZuYnNwO1RoZSBjdXJyZW50IG1vZGVsIHNlZW1zIHRvIGFzc3VtZSB0aGF0IHJ1bGVz IHdpbGwgYWx3YXlzIGJlIGV4cGxpY2l0bHkgY29uZmlndXJlZCBmcm9tIGFuIGV4dGVybmFsIGNs aWVudCBhbmQgY29uc3RpdHV0ZSBwYXJ0IG9mIGNvbmZpZ3VyYXRpb24uDQogTm93LCB3aGF0IGFi b3V0IHRoZSBjYXNlIHdoZW4gcnVsZXMgYXJlIHRvIGJlIGVuZm9yY2VkIGF1dG9tYXRpY2FsbHkg YnkgdGhlIHNlcnZlcj8gJm5ic3A7Jm5ic3A7SSB0aGluayBOQUNNIHNob3VsZCBhbGxvdyBmb3Ig dGhhdCwgYW5kIGhhdmluZyBhIG1peCBvZiBib3RoLiAmbmJzcDsoVGhlIHNlcnZlci1wcm92aWRl ZCB0b3BvbG9naWVzIGFyZSBvbmUgcG90ZW50aWFsIGV4YW1wbGUgd2hlcmUgdGhpcyB3b3VsZCBi ZSB2ZXJ5IHVzZWZ1bC4mbmJzcDsgSW4gZmFjdCwgaWYgdGhpcw0KIGNhcGFiaWxpdHkgd2VyZSBz dXBwb3J0ZWQsIEkgZG9u4oCZdCB0aGluayB3ZSB3b3VsZCBiZSBoYXZpbmcgdGhlIHNlcnZlci1w cm92aWRlZCBkaXNjdXNzaW9uIGluIHRoZSB0b3BvbG9neSBjb250ZXh0IOKAkyBOQUNNIHdvdWxk IGJlIGFsbCB3ZSBuZWVkLiZuYnNwOyBIb3dldmVyLCB0aGVyZSBhcmUgb3RoZXIgdXNlIGNhc2Vz IGZvciB0aGlzLiZuYnNwOyBUaGluayBlLmcuIGFuIGludHJ1c2lvbiBwcm90ZWN0aW9uIGNvbXBv bmVudCBvbiB0aGUgc2VydmVyLCB0aGF0DQogeW91IHdvdWxkIG5vdCB3YW50IHRvIG92ZXJyaWRl IGJ5IGFuIGV4dGVybmFsIHVzZXIgYWRtaW5pc3RyYXRpb24gY2xpZW50IGFwcGxpY2F0aW9uIHRo YXQgeW91IHdvdWxkIHN0aWxsIHdhbnQgdG8gYWxsb3cgYXMgd2VsbC4mbmJzcDsgT3IgY2FzZXMg d2hlbiBzb21lIGF1dGhvcml6YXRpb25zIGdldCBzaWduYWxlZCwgZS5nLiBpbiB0aGUgY2FzZSBv ZiBhdXRvbm9taWMgcGVlci10by1wZWVyIHR5cGUgb2YgYXBwbGljYXRpb25zLik8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayBhbnkgWUFORyBjb25maWd1cmF0aW9uIG1v ZHVsZSBwcmVjbHVkZXMgc2VydmVyLWNyZWF0ZWQgZW50cmllcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb25maWd1cmF0aW9uIGlzIGNy ZWF0ZWQgc29tZWhvdy4mbmJzcDsgVGhlIFlBTkcgbW9kdWxlIGRpc2N1c3NlcyB0aGUgZGF0YSBt b2RlbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ aW5zdGFuY2VzIHdpdGhvdXQgc2F5aW5nIGhvdyB0aGV5IGdvdCB0aGVyZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMEIwNTAiPiZuYnNwOyZsdDtBTEVYJmd0OyBUaGVuIHdoeSBhcmUgd2UgY29uY2VybmVk IGluIHRoZSB0b3BvbG9neSBtb2RlbCBhYm91dCBob3cgdGhlIGVudHJpZXMgZ290IHRoZXJlPyZu YnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPiZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPi0tLSBBbGV4Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gaTJycyBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDEyOjQ5IFBNPGJy Pg0KPGI+VG86PC9iPiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpo LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkycnNA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaTJyc10gdG9wbyBtb2RlbCB1 c2Ugb2YgTkFDTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIG1v c3QgY29uY2VybmVkIGFib3V0IGdldHRpbmcgdGhlIGFyY2hpdGVjdHVyZSByaWdodC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgaGF2ZSBp Z25vcmVkIHNlcnZlci1jcmVhdGVkIG5vZGVzIHVudGlsIG5vdy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhbSBnbGFkIEkyUlMgV0cgaXMg dHJ5aW5nIHRvIGRlYWwgd2l0aCB0aGUgcHJvYmxlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVzdCBtYWtlIHN1cmUgd2UgaGF2ZSBhIHJl dXNhYmxlIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QWxzbyBjb25jZXJuZWQgYWJvdXQgdG9vbCBhdXRvbWF0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVy ZSB3YXMgc29tZSBkaXNjdXNzaW9uIG9mIGEgJ3NlcnZlci1jcmVhdGVkJyBleHRlbnNpb24gYXQg c29tZSBwb2ludCBJIHRoaW5rLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGlzIHdvdWxkIGhlbHAsIGJlY2F1c2UgdGhlIHNlcnZlci1jcmVh dGVkIGxlYWYgaXMgbm90IHJlYWxseSBkZXRlcm1pbmlzdGljLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBqdXN0IGEgY29udmVudGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPmUuZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IGNvbnRhaW5lciBuZXR3b3JrcyB7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJz cDsgJm5ic3A7bGlzdCBuZXR3b3JrIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ky cnM6c2VydmVyLWNyZWF0ZWQ7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgc2VydmVyLWNyZWF0ZWQgeyAuLi4gfTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7fTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVGh1LCBGZWIgMTYsIDIwMTcgYXQgMTE6NDcgQU0sIFN1c2FuIEhhcmVzICZs dDs8YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIiB0YXJnZXQ9Il9ibGFuayI+c2hhcmVz QG5kemguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHk6DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O2NoYWlyIGhh dCBvZmYsIGluZGl2aWR1YWwgY29udHJpYnV0b3IgaGF0IG9uJmd0Ow0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5BRkFJSyDigJMgSSBiZWxpZXZlIHRoZSByZXZpc2VkIGRhdGEgc3RvcmUgbW9kZWwgaXMg cmlnaHQgYXBwcm9hY2guICZuYnNwOyZuYnNwO0l0IGlzIGFuIGltcG9ydGFudCBxdWVzdGlvbiB0 byBhc2sgd2hldGhlciB0aGUNCiBhYmlsaXR5IHRvIGhhdmUgYSBtaXh0dXJlIG9mIOKAnHNlcnZl ci1wcm92aWRlZOKAnSBhbmQg4oCcY29uZmlndXJlZOKAnSBpcyBpbXBvcnRhbnQgZm9yIGFsbCB0 b3BvbG9neSBtb2RlbHMuJm5ic3A7IEkgaG9wZSBYdWZlbmcgYW5kIG90aGVyIHRvcG9sb2d5IG1v ZGVscyB3aWxsIGNvbW1lbnQgb24gdGhpcyBwb2ludC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Eb2Vz IHRoZSBORVRDT05GIGRhdGEgc3RvcmUgaW4gdGhlIHJldmlzZWQgZGF0YS1zdG9yZSBmdXR1cmUg aW5jbHVkZSB0aGUgY29udHJvbCBwbGFuZSBkYXRhIHN0b3Jlcz8gSSB0aG91Z2h0IHRoZSBhbnN3 ZXINCiB3YXMg4oCcbm/igJ0gaXQgZG9lcyBub3QuJm5ic3A7ICZuYnNwO0hlcmXigJlzIHNvbWUg dGV4dCBmcm9tIGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM2NTM2YmlzIHRoYXQgbGVhZHMgbWUgdG8g YmVsaWV2ZSB0aGF0DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIE5BQ00sIGRyYWZ0LWlldGYtbmV0 Y29uZi1yZmM2NTM2YmlzIGl0IHNheXM6DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEl0IGlz IG5lY2Vzc2FyeSB0byBjb250cm9sIGFjY2VzcyB0byBzcGVjaWZpYyBub2RlcyBhbmQgc3VidHJl ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgd2l0aGluIHRoZSBORVRDT05GIGRhdGFzdG9yZSwgcmVnYXJkbGVzcyBv ZiB3aGljaCBwcm90b2NvbCBvcGVyYXRpb24sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN0YW5kYXJkIG9yIHByb3By aWV0YXJ5LCB3YXMgdXNlZCB0byBhY2Nlc3MgdGhlIGRhdGFzdG9yZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8aDM+PGEgbmFtZT0ibV8tMTU4NDE2NzI5ODM4MDQ3MzY2MV9tXy02NDY4 MjY3MzQyODYyMCI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcy0wMCNzZWN0aW9uLTMuMiIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4zLjI8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4uJm5ic3A7DQogRGF0YXN0b3JlIEFjY2Vzczwvc3Bhbj48bzpwPjwvbzpwPjwvaDM+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ICZuYnNwOyZuYnNwO1RoZSBzYW1lIGFjY2VzcyBj b250cm9sIHJ1bGVzIGFwcGx5IHRvIGFsbCBkYXRhc3RvcmVzLCBmb3IgZXhhbXBsZSw8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgdGhlIGNhbmRpZGF0ZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBvciB0aGUgcnVubmlu ZyBjb25maWd1cmF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRhdGFzdG9yZS48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg T25seSB0aGUgc3RhbmRhcmQgTkVUQ09ORiBkYXRhc3RvcmVzIChjYW5kaWRhdGUsIHJ1bm5pbmcs IGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBzdGFydHVwKSBhcmUgY29udHJvbGxlZCBieSBOQUNNLiZuYnNwOyBM b2NhbCBvciByZW1vdGUgZmlsZXMgb3IgZGF0YXN0b3Jlczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhY2Nlc3NlZCB2 aWEgdGhlICZsdDt1cmwmZ3Q7IHBhcmFtZXRlciBhcmUgbm90IGNvbnRyb2xsZWQgYnkgTkFDTS4m bmJzcDsgQTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBzdGFuZGFsb25lIFJFU1RDT05GIHNlcnZlciAoaS5lLiwgbm90 IGNvLWxvY2F0ZWQgd2l0aCBhIE5FVENPTkY8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2VydmVyKSBhcHBsaWVzIE5B Q00gcnVsZXMgdG8gYSBjb25jZXB0dWFsIGRhdGFzdG9yZSwgc2luY2U8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZGF0 YXN0b3JlcyBhcmUgbm90IHN1cHBvcnRlZCBpbiBSRVNUQ09ORi48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPj09PT09 PT09PT09PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+VGhlIEkyUlMgc2VjdXJpdHkgZW52aXJvbm1lbnQgYWN0dWFsbHkgbG9va3Mg YXQgMyBwb2xpY2llcyBvbiB0aGUgc2VydmVyDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OZXR3b3JrIEFjY2Vzcw0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w588 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzIj7DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IHNlcnZlcg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w588L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzIj7DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IHJvdXRpbmctc3lzdGVtDQogYWNj ZXNzICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyhha2EgSTJSUyBhZ2VudCk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3Mi PsOfw6A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KIFN5c3RlbSBhY2Nlc3MgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXQgYWxzbyBsb29r cyBhdCBhcHBsaWNhdGlvbiBhY2Nlc3MgdG8gdGhlIGNsaWVudA0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IE5ldHdv cmsgYWNjZXNzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncyI+w5/DoDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQogY2xpZW50IDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPsOfw6A8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiBhcHBsaWNhdGlvbi1hY2Nlc3MgJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+VGhlIHByb3RvY29sIG9ubHkgbmVlZHMgdG8gY29uc2lkZXIgdGhlIE5BQ00gQWNjZXNz LCBidXQgdGhlIHJvdXRpbmcgaW5mcmFzdHJ1Y3R1cmUgbmVlZCB0byBjb25zaWRlciB0aGUgc2Vy dmVyIHRvL2Zyb20NCiByb3V0aW5nIHN5c3RlbSwgYW5kIHNlcnZlciB0by9mcm9tIHN5c3RlbS4m bmJzcDsgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBSb3V0aW5nIHN5c3RlbSBhY2Nlc3Mg Y29udHJvbCBtb2R1bGUgKFJBQ00pIGFuZCB0aGUgc3lzdGVtIGFjY2VzcyBjb250cm9sIG1vZHVs ZSAoU0FDTSkgZnVuY3Rpb25zIHdlcmUgbm90IGluIE5BQ00uDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFua3MgYWdhaW4g Zm9yIHBvc3RpbmcsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5TdWUgJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gaTJycyBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDI6MDAgUE08YnI+ DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+aTJyc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2kycnNdIHRvcG8gbW9k ZWwgdXNlIG9mIE5BQ008L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl IHVzZSBvZiBOQUNNIGZvciBzZXJ2ZXItcHJvdmlkZWQgZGF0YSBpcyB1bmRlci1zcGVjaWZpZWQg KGF0IGJlc3QpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+ZnJvbSBzZWMuIDQuMTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRmluYWxseSwgdGhl cmUgaXMgYW4gb2JqZWN0ICZxdW90O3NlcnZlci1wcm92aWRlZCZxdW90Oy4mbmJzcDsgVGhpcyBv YmplY3QgaXMgc3RhdGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhhdCBpbmRpY2F0ZXMgaG93IHRoZSBuZXR3b3Jr IGNhbWUgaW50byBiZWluZy4mbmJzcDsgTmV0d29yayBkYXRhIGNhbjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjb21l IGludG8gYmVpbmcgaW4gb25lIG9mIHR3byB3YXlzLiZuYnNwOyBJbiBvbmUgd2F5LCBuZXR3b3Jr IGRhdGEgaXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgY29uZmlndXJlZCBieSBjbGllbnQgYXBwbGljYXRpb25zLCBm b3IgZXhhbXBsZSBpbiBjYXNlIG9mIG92ZXJsYXk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbmV0d29ya3MgdGhhdCBh cmUgY29uZmlndXJlZCBieSBhbiBTRE4gQ29udHJvbGxlciBhcHBsaWNhdGlvbi4mbmJzcDsgSW48 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgYW5ub3RoZXIgd2F5LCBpdCBpcyBwb3B1bGF0ZWQgYnkgdGhlIHNlcnZlciwg aW4gY2FzZSBvZiBuZXR3b3JrcyB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNhbiBiZSBkaXNjb3ZlcmVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBJZiBzZXJ2ZXItcHJvdmlkZWQgaXMgc2V0IHRvIGZhbHNlLCB0aGUg bmV0d29yayB3YXMgY29uZmlndXJlZCBieSBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNsaWVudCBhcHBsaWNhdGlv biwgZm9yIGV4YW1wbGUgaW4gdGhlIGNhc2Ugb2YgYW4gb3ZlcmxheSBuZXR3b3JrPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHRoYXQgaXMgY29uZmlndXJlZCBieSBhIGNvbnRyb2xsZXIgYXBwbGljYXRpb24uJm5ic3A7 IElmIHNlcnZlci1wcm92aWRlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpcyBzZXQgdG8gdHJ1ZSwgdGhlIG5ldHdv cmsgd2FzIHBvcHVsYXRlZCBieSB0aGUgc2VydmVyIGl0c2VsZiw8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVzcGVj dGl2ZWx5IGFuIGFwcGxpY2F0aW9uIG9uIHRoZSBzZXJ2ZXIgdGhhdCBpcyBhYmxlIHRvIGRpc2Nv dmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHRoZSBuZXR3b3JrLiZuYnNwOyA8Yj5DbGllbnQgYXBwbGljYXRpb25z IFNIT1VMRCBOT1QgbW9kaWZ5IGNvbmZpZ3VyYXRpb25zIG9mPC9iPjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBu ZXR3b3JrcyBmb3Igd2hpY2ggJnF1b3Q7c2VydmVyLXByb3ZpZGVkJnF1b3Q7IGlzIHRydWUuPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBXaGVuIHRoZXkgZG8sIHRo ZXk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgbmVlZCB0byBiZSBhd2FyZSB0aGF0IGFueSBtb2RpZmljYXRpb25zIHRo ZXkgbWFrZSBhcmUgc3ViamVjdCB0byBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZXZlcnRlZCBieSB0aGUgc2Vy dmVyLiZuYnNwOyBGb3Igc2VydmVycyB0aGF0IHN1cHBvcnQgTkFDTSAoTmV0Y29uZjwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBBY2Nlc3MgQ29udHJvbCBNb2RlbCksIDxiPmRhdGEgbm9kZSBydWxlcyBzaG91bGQgaWRl YWxseSBwcmV2ZW50PC9iPiB3cml0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhY2Nlc3MgYnkgb3RoZXIgY2xpZW50 cyB0byBuZXR3b3JrIGluc3RhbmNlcyBmb3Igd2hpY2ggc2VydmVyLTwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwcm92 aWRlZCBpcyBzZXQgdG8gdHJ1ZS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBTSE9VTEQgTk9UIGFib3ZlIGlzIHJl YWxseSBvZGQsIGNvbnNpZGVyaW5nIGlzIG5vdCBzdXBwb3J0ZWQgYnkgWUFORzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vciB0aGUgTkMvUkMg cHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+JnF1b3Q7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5kYXRhIG5vZGUgcnVs ZXMgc2hvdWxkIGlkZWFsbHkgcHJldmVudCZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+cy9zaG91bGQvU0hPVUxELzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SWRlYWxseSBwcmV2ZW50Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JcyB0aGF0 IGEgbmV3IGVuZ2luZWVyaW5nIHRlcm0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkVp dGhlciB0aGlzIG5ldyB1c2FnZSBvZiBOQUNNIHdvcmtzIG9yIGl0IGRvZXNuJ3QuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbHNvLCB0aGVyZSBpcyBubyBndWlkYW5jZSBvciBl eGFtcGxlcyBvZiB0aGUgTkFDTSBjb25maWcgdGhhdCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+c2VydmVyIGlzIHN1cHBvc2VkIHRvIG1hZ2ljYWxseSBjcmVhdGUgZm9yIHNlcnZl ci1wcm92aWRlZCB0b3BvbG9neSBkYXRhLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5U aGVyZSBpcyBub3RoaW5nIGluIE5BQ00gYXQgYWxsIGFib3V0IHNlcnZlci1jcmVhdGVkIGRhdGEg cnVsZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgaXMgbm90IHN1cHBvcnRl ZCBieSBOQUNNLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RG9lcyB0aGUgSTJS UyB0ZXh0IGltcGx5IHRoYXQgdGhlIHNlcnZlci1wcm92aWRlZCBwcm9wZXJ0eSBleHRlbmRzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnRvIHRoZSBOQUNNIHN1Yi10cmVlcz8gVGhleSBh cmUgYWxzbyBzdWJqZWN0IHRvIHJlcGxhY2VtZW50IGJ5IHRoZSBzZXJ2ZXI/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBjbGllbnQgU0hPVUxEIE5PVCBjaGFuZ2UgdGhlc2UgTkFD TSBydWxlcz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklNTyB0aGUgd2F5IHRo aXMgc2VydmVyLXByb3ZpZGVkIHByb3BlcnR5IGlzIGJlaW5nIGRvbmUgaXMgYSBzaG9ydC1zaWdo dGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnBvaW50IHNvbHV0aW9uLCBidXQgdGhp cyBzaG91bGQgYmUgYSBmdW5kYW1lbnRhbCBwYXJ0IG9mIHRoZSByZXZpc2VkIGRhdGFzdG9yZXMg d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SXMgdGhlcmUgc29tZXRoaW5nIHNw ZWNpYWwgYWJvdXQgbmV0d29yayB0b3BvbG9neSBzdWNoIHRoYXQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+c2VydmVyLXByb3ZpZGVkIGRhdGEgZm9yIGEgZGlmZmVyZW50IG1vZHVsZSB3 aWxsIHJlcXVpcmUgYSBkaWZmZXJlbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c29s dXRpb24/IElmIG5vdCwgaXMgdGhlIHRvcG8gbW9kdWxlIHNvbHV0aW9uIHJldXNhYmxlPw0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QW5keTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQppMnJzIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF80A52SJCEML703CHMchi_-- From nobody Thu Feb 16 15:35:25 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE6126B6D for ; Thu, 16 Feb 2017 15:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EvlXesqmQYQ for ; Thu, 16 Feb 2017 15:35:22 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0114.outbound.protection.outlook.com [104.47.37.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F268129421 for ; Thu, 16 Feb 2017 15:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3tHheLN/7yPt5/Ewct2uPw/FuDRPBg10I/sPXBG+j28=; b=kPw6MBQFvUOsSrCi6us/suT4UO6gWAaughb8Kmx+dPFg2PTAfjB3JA7RRN6EJ/bi1e4CCFjwi2hWWTLrOmCI2/kY7XHWXZx8aSEbULf+p/0OPl1cjM3lsz20QzmSvJAiZOO0rm2LE5EawOfgcwDJnDbkv8ECPTu1EjZHHJPlez4= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 23:35:19 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.013; Thu, 16 Feb 2017 23:35:20 +0000 From: Kent Watsen To: Martin Bjorklund , "xufeng.liu.ietf@gmail.com" Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFoWKoA///awYCAAIH9AIADEzSAgABfVYD//9IJAA== Date: Thu, 16 Feb 2017 23:35:19 +0000 Message-ID: <9B5F937A-346D-429A-9E9C-1D453BED83B3@juniper.net> References: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <20170216.221949.1797970554181706414.mbj@tail-f.com> In-Reply-To: <20170216.221949.1797970554181706414.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 9d99c6df-a860-40d4-1dd6-08d456c47883 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:C7ikB2J35Je/t0IJszrEtANHOdyEmn0u6D+UJYVoMHRhzUlOYQe4b3SnHKyDtoNqOU3d/cVIIFt8NO/gqccmIQTWDH1h3jQNfMprjStQR2X19xS5aHQ8tJCUpnOvW7ojD6wn+UNO8hblqOi4AC7b+kSMVthQ69kPu0YfOC0iP4CrTzmw0ibPYSoDGVM4p86CjyPiMJnuzjCyS5g4vybAtm74G7vTaN9GO+L2t1o5Y0QE9yZIPhpbcrWy8nhMgQNVipvw3C/r5JSJbgZl0hhAugecs83N97bJnchVmi3CoUJlkRIxd9PYSncNIv2wNeUYL3Ne1YQNrZpSaUi3B66DHg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39450400003)(39860400002)(199003)(189002)(5660300001)(81156014)(2950100002)(81166006)(66066001)(33656002)(93886004)(7736002)(3660700001)(6512007)(2900100001)(122556002)(389900003)(83506001)(82746002)(305945005)(561944003)(53936002)(83716003)(25786008)(8936002)(8676002)(99286003)(92566002)(105586002)(6506006)(101416001)(97736004)(2906002)(106356001)(6486002)(6436002)(86362001)(77096006)(4001350100001)(36756003)(2501003)(54356999)(6246003)(230783001)(38730400002)(39060400002)(189998001)(76176999)(3280700002)(229853002)(3846002)(4326007)(68736007)(50986999)(6116002)(102836003)(106116001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 23:35:19.9938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:35:24 -0000 DQoNCj4+Pj4gMikgSXQgZG9lc24ndCBzYXkgYW55dGhpbmcgYWJvdXQgaG93IHRoZSBvcHN0YXRl IGRhdGEgaXMgc3RvcmVkIG9uIHRoZQ0KPj4+PiAgICBzZXJ2ZXIuICBUaGUgb3BzdGF0ZSBkYXRh IGlzIG5vdCBtb2RlbGVkIGF0IGFsbC4gIFRoaXMgYXBwcm9hY2gNCj4+Pj4gICAgb25seSBkZWZp bmVzIGEgcHJlc2VudGF0aW9uLWxheWVyIGZvcm1hdCBmb3IgaG93IG9wc3RhdGUgZGF0YSBjYW4N Cj4+Pj4gICAgYmUgcmV0dXJuZWQgdmlhIGFuIFJQQy4gIFRoZSBzZXJ2ZXIgaXMgZnJlZSB0byBw ZXJzaXN0IHRoZSBvcHN0YXRlDQo+Pj4+ICAgIGRhdGEgYW55d2F5IGl0IHdhbnRzLCBwZXJoYXBz IGluIGFuIGludGVybmFsIGRhdGFzdG9yZSBjYWxsZWQNCj4+Pj4gICAgJ29wZXJhdGlvbmFsLXN0 YXRlJyBvciBpbiBhbiB1YmVyLWRhdGFzdG9yZSB3aXRoIHRoZSBvcHN0YXRlIGRhdGENCj4+Pj4g ICAgZmxhZ2dlZCB3aXRoIGEgZGF0YXN0b3JlPSdvcGVyLXN0YXRlJyBhdHRyaWJ1dGUuICBSZWdh cmRsZXNzLCBpdCdzDQo+Pj4+ICAgIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCwgYW5kIHRoZSBj b25jZXB0dWFsIGRhdGFzdG9yZSBtb2RlbCBpcw0KPj4+PiAgICBwcmVzZXJ2ZWQuDQo+Pj4gDQo+ Pj4gWW91IGFyZSBlc3NlbnRpYWxseSBkZWZpbmluZyBhIG5ldyBvcGVyYXRpb24sIGJ1dCBkbyBp dCBieSBtb2RpZnlpbmcgdGhlDQo+Pj4gc2VtYW50aWNzIG9mIGFuIGV4aXN0aW5nIG9uZS4gIEkg ZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYTsgaXQgaXMNCj4+PiBiZXR0ZXIgdG8gZGVm aW5lIGEgbmV3IHJwYy4NCj4+IA0KPj4gW1h1ZmVuZ10gSXMgdXNpbmcgYSBuZXcgcnBjIGlzIGFj Y2VwdGFibGU/IElmIHNvLCB0aGlzIGNvdWxkIGJlIGEgdmlhYmxlDQo+PiBvcHRpb24uDQo+DQo+ VGhlIGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3JlcyBwcm9wb3NlcyBhIG5ldyBy cGMgKG1heWJlDQo+PGdldC1kYXRhPikgdG8gcmV0dXJuIGRhdGEgZnJvbSB0aGUgbmV3IG9wZXJh dGlvbmFsLXN0YXRlIGRhdGFzdG9yZS4NCj5UaGlzIGlzIElNTyBiZXR0ZXIgdGhhbiBhZGRpbmcg b3BzdGF0ZSBub2RlcyB0byB0aGUgcmVwbHkgdG8gYQ0KPjxnZXQtY29uZmlnPiByZXF1ZXN0Lg0K DQoNCk1hcnRpbiwNCg0KR29pbmcgYmFjayB5b3VyIGVhcmxpZXIgImJldHRlciB0byBkZWZpbmUg YSBuZXcgcnBjIiBjb21tZW50LCBJIGZhaWwgdG8NCnNlZSBob3cgdGhpcyBwcm9wb3NhbCBpcyBz aWduaWZpY2FudGx5IGRpZmZlcmVudCB0aGFuIFJGQyA2MjQzLg0KDQpJZiBub3QgdGhpcywgdGhl biB0aGUgbmV3IFJQQyB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSA8Z2V0LWNvbmZpZy1leD4NCm1v cmUgdGhhbiB0aGUgcGxhbm5lZCA8Z2V0LWRhdGE+LCBhcyB0aGUgZ29hbCBpcyB0byByZXR1cm4g J3J1bm5pbmcnDQorICJzb21lIG9wc3RhdGUiIChub3QganVzdCBvcHN0YXRlKS4NCg0KU3RpbGws IGluIGxvb2tpbmcgdGhlIHRoZSBwcm9zL2NvbnMsIE9wdGlvbiAxIGFwcGVhcnMgc3Ryb25nZXIg LSBvbmx5DQp0aGUgYXV0aG9ycyBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIGhhdmluZyB0byByZXdy aXRlIHRoZWlyIG1vZGVscw0KbGF0ZXIuLi4NCg0KS2VudA0KDQoNCg0KDQoNCg== From nobody Fri Feb 17 00:44:26 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C628D1295C6 for ; Fri, 17 Feb 2017 00:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSPSvHmpOdYq for ; Fri, 17 Feb 2017 00:44:21 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF47127078 for ; Fri, 17 Feb 2017 00:44:19 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.5.209; From: "Susan Hares" To: "'Xufeng Liu'" , "'Martin Bjorklund'" , References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <050901d28887$25a887d0$70f99770$@ndzh.com> <00bd01d2888d$9fe53290$dfaf97b0$@gmail.com> <055801d2888e$50276ba0$f07642e0$@ndzh.com> <00e801d28899$f7b231b0$e7169510$@gmail.com> In-Reply-To: <00e801d28899$f7b231b0$e7169510$@gmail.com> Date: Fri, 17 Feb 2017 03:38:59 -0500 Message-ID: <06f801d288f9$4962c650$dc2852f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKQx8r72RrckYMhXWnaB0v1b2P4ZAEWoFNQAqHHXJ0B1BTo7AGVrx3gAjEJjgcB0cJWuwIlsb4DAddBNrafd1DhYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:44:24 -0000 Xufeng and Alex: The WG will need to make the decision on the next steps (not the chair). My questions (as chair) were simply to clarify the issues. The AD (Alia) and I have been asking for input on those who felt the If you want to create a proposal for the short term, please do. Just to let you know, the shortest time period I have been able to turn around new proposal to RFC in a WG is 4 months (see IDR's large community draft). In this proposal, we had working code, a simple specification, and operators who wanted the code. If you feel the topology models + rpc are similar to this, please write-up the proposal. We can hold virtual interims before IETF in Chicago and after to speed the process. Thanks for working so hard on the topology models. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu Sent: Thursday, February 16, 2017 4:17 PM To: 'Susan Hares'; 'Martin Bjorklund'; kwatsen@juniper.net Cc: i2rs@ietf.org Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Hi Sue, I agree that the revised data stores solutions is the long term solution, but it may take a year to complete because it covers a much broader scope. Are we ok with delaying all these models for another year? This could be the decision of the Chairs and ADs. Also, this approach seems to be a sub-set of the long term solution, and they are compatible. If the details can be worked out, it would be good to have such an interim solution immediately, which does not need to solve all the problems, but hopefully can migrate to the long term solution smoothly. Thanks, - Xufeng > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, February 16, 2017 2:53 PM > To: 'Xufeng Liu' ; 'Martin Bjorklund' f.com>; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: RE: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > Xufeng: > > I suspect 2 rpcs will be needed, but Martin and Kent are the experts. Do > you think trying to accelerate the revised data stores solutions is a better way to > go? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > Sent: Thursday, February 16, 2017 2:48 PM > To: 'Susan Hares'; 'Martin Bjorklund'; kwatsen@juniper.net > Cc: i2rs@ietf.org > Subject: Re: [i2rs] modeling options for > draft-ietf-i2rs-yang-network-topo > > Hi Sue, > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, February 16, 2017 2:02 PM > > To: 'Xufeng Liu' ; 'Martin Bjorklund' > > f.com>; kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: RE: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > To Xufeng: > > > > Clarifying question - Are you asking about I2RS topology as a > > generic yang model for any configuration or are you asking about > > I2RS topology model as > an > > ephemeral topology model. > > [Xufeng] I was talking about I2RS topology as a generic yang model for > any configuration, but I think that the same solution can be applied > to ephemeral > case, though a separate rpc might be needed. > > Thanks, > - Xufeng > > > > > To Martin: > > Clarifying questions: > > > > 1) Is your rpc suggest target toward the I2RS topology model as a > > generic topology model or an I2RS ephemeral state model or both? > > > > 2) Could we define rpcs now that operate as Alex desired for generic > topology > > models that could be replaced by more generic mechanisms later? > > For example, the I2RS RIB has defined rpcs for all major functions > (add/delete rib, > > add/delete route, add/delete nexhop) plus notifications for changes. > > Is > this the > > best approach here? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Xufeng Liu > > Sent: Thursday, February 16, 2017 10:39 AM > > To: 'Martin Bjorklund'; kwatsen@juniper.net > > Cc: i2rs@ietf.org > > Subject: Re: [i2rs] modeling options for > > draft-ietf-i2rs-yang-network-topo > > > > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > > > Bjorklund > > > Sent: Tuesday, February 14, 2017 11:41 AM > > > To: kwatsen@juniper.net > > > Cc: i2rs@ietf.org > > > Subject: Re: [i2rs] modeling options for > > > draft-ietf-i2rs-yang-network-topo > > > > > > Kent Watsen wrote: > > > > > > > > > > > > [moving yang-doctors to BCC] > > > > > > > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > > > >> -------------------------------------------- > > > > >> > > > > >> This option was/is described here: > > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > > > >> > > > > >> PROS: > > > > >> a) does NOT break legacy clients (how we got here) > > > > >> b) consistent with convention used in many IETF modules > > > > >> c) able to show if/how opstate may differ from configured > > > > >> values > > > > >> > > > > >> CONS: > > > > >> a) questionably valid YANG leafref usage > > > > > > > > > > What does this mean? > > > > > > > > I'm referring to how the description statement explains that the > > > > server may look to operational state in order to resolve the > > > > leafref, which is to result in behavior similar to > > > > pre-configuration in RFC 7223. > > > > > > Ok, I didn't pay close attention to the proposal in the quoted email. > > > > > > I would design this a bit differently. The config true leaf > "dependency" > > should > > > have a leafref to the config false node name, with > > > require-instance > false. > > The > > > description should explain that the configuration item will be > > > used by the > > server > > > if all dependencies exist. When the configuration item is used, > > > it shows > > up in the > > > config false list. > > > > > > This way, the leafref usage is valid and straight forward. > > > > > > > >> b) complex server implementation (to handle > > > > >> require-instance > > > > >> false) > > > > > > > > > >Can you elaborate on this one? > > > > > > > > This is primarily a reflection of the CON listed above, in that > > > > it seems that a server would need to have special handling for > > > > when dependencies transition from being present to not-present > > > > and vice versa, much like the code to handle when a physical > > > > card is plugged in or removed. > > > > > > Yes, but I think this is inherent to the problem at hand. Even > > > with the > > config true > > > solution defined in the current draft, it is not clear how things > > > that > > were created > > > by the server would be deleted (if there were references to them). > > > > > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > > > >> solution, which would result in needing to also rewrite all > > > > >> modules that have augmented it (e.g., ietf-te-topology). > > > > >> d) leafref path expressions really only work for > > > > >> configuration > > data, > > > > >> though a clever server could have a special ability to > > > > >> peak at > > > > >> the opstate values when doing validations. Of course, with > > > > >> require-instance is false, the value of leafref based > validation > > > > >> checking is negated anyway, even for config true nodes, > > > > >> so > this > > > > >> may not matter much. > > > > >> > > > > >> > > > > >> > > > > >> OPTION 2: explicit client-option to also return tagged > > > > >> opstate data > > > > >> ------------------------------------------------------------- > > > > >> -- > > > > >> -- > > > > >> -- > > > > >> > > > > >> This option takes a couple forms. The first is > > > > >> module-specific and the second is generic. In both cases, > > > > >> the idea is modeled after the with-defaults solution > > > > >> (RFC6243), wherein the client passes a special flag into > > > > >> causing the server to also return opstate data, > > > > >> having a special metadata flag set, intermingled with the configuration data. > > > > >> > > > > >> > > > > >> 2A: Module-specific version > > > > >> > > > > >> module foo { > > > > >> import ietf-netconf { prefix nc; } > > > > >> import ietf-yang-metadata { prefix md; } > > > > >> md:annotation server-provided { > > > > >> type boolean; > > > > >> } > > > > >> container nodes { > > > > >> config true; > > > > >> list node { > > > > >> key "name"; > > > > >> leaf name { type string; } > > > > >> leaf dependency { > > > > >> type leafref { > > > > >> path "../node/name" > > > > >> require-instance false; > > > > >> } > > > > >> } > > > > >> } > > > > >> } > > > > >> augment /nc:get-config/nc:input { > > > > >> leaf with-server-provided { > > > > >> type boolean; > > > > >> } > > > > >> } > > > > >> } > > > > > > > > > > I don't think this solution is substantially different from > > > > > the solution in draft-ietf-i2rs-yang-network-topo-10. You > > > > > have just moved a config false leaf to a meta-data annotation. > > > > > This solution suffers from the same problems as the solution > > > > > in draft-ietf-i2rs-yang-network-topo-10. > > > > > > > > There are two primary differences: > > > > > > > > 1) It doesn't break legacy clients > > > > > > The solution in the draft doesn't break legacy clients either - > > > there's a > > config > > > false leaf among the config true. No problem. > > > > > > > , because it requires the client to > > > > explicitly pass a 'with-server-provided' flag in the > > > > request in order to get back the extended response. Likewise, it > > > > doesn't break backup/restore workflows, as the server can discard > > > > any 'server-provided' nodes passed in an operation. > > > > > > Huh? This goes against the defined behavior of 6241 + 7950. This > > > is the > > main > > > problem with the solution in the current draft. > > > > > > If a client sends a for data in running, the server > > > cannot > > send back > > > data that is not in running. > > > > > > > Lastly, it doesn't break /, as there is no comingling > > > > of opstate data in the 'running' datastore. > > > > > > > > 2) It doesn't say anything about how the opstate data is stored > > > > on the > > > > server. The opstate data is not modeled at all. This approach > > > > only defines a presentation-layer format for how opstate data can > > > > be returned via an RPC. The server is free to persist the opstate > > > > data anyway it wants, perhaps in an internal datastore called > > > > 'operational-state' or in an uber-datastore with the opstate data > > > > flagged with a datastore='oper-state' attribute. Regardless, it's > > > > an implementation detail, and the conceptual datastore model is > > > > preserved. > > > > > > You are essentially defining a new operation, but do it by > > > modifying the semantics of an existing one. I don't think this is > > > a good idea; it is > > better to > > > define a new rpc. > > > > [Xufeng] Is using a new rpc is acceptable? If so, this could be a > > viable > option. > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Feb 17 10:04:44 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3347C129631 for ; Fri, 17 Feb 2017 10:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTn5kVrxgxwB for ; Fri, 17 Feb 2017 10:04:41 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0138.outbound.protection.outlook.com [104.47.42.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 7B058129679 for ; Fri, 17 Feb 2017 09:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0XlcxqegKp1ac7MwNT8RbuPHSwK/p5JpPejWGtFPO/M=; b=earJn3wQfRoeTBSy63q2GD8frGa6+K0DbVEuMLSKl9ydGNABD6QHo/ndDzCfv/QVmSOWuzPCN521h1x+PBly3y+KT9530ivg5fW7gxYMMCkJSEMkJKqtiDqBlH5nsghw0aAGVzngWPbTZTh17rOtEKhRpm9GAL4ikRIs5p5/JZQ= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Fri, 17 Feb 2017 17:57:28 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.013; Fri, 17 Feb 2017 17:57:28 +0000 From: Kent Watsen To: Martin Bjorklund , "andy@yumaworks.com" Thread-Topic: [i2rs] topo model use of NACM Thread-Index: AQHSiIbsQP+b7wUX0UCeyrAepaEUL6FsCeUAgAART4CAAAb7AIABB4kA Date: Fri, 17 Feb 2017 17:57:28 +0000 Message-ID: <0BF3AD51-5359-4496-A230-F195033FA43A@juniper.net> References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> <20170216.221412.2181707942833993110.mbj@tail-f.com> In-Reply-To: <20170216.221412.2181707942833993110.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 33aaebca-e0fb-406f-c8d9-08d4575e6fee x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:oSHluKgs2LFHFlOlSQUsqBRk4Mbx9769ybCaS5vc8wHE3b8mYpbyyVBEwviTzrmAiKnijEbLNDe0nHlcKs/sDar5YFj/vO8ofV/4etfLoCkzm+c/tdiF2R5wjN4jCgJ7Lf3dkebcrvF94Afy6jL0bR3/XB+5M3udKnEQDKhyPLjbpGELXxsx4Ug1JTMcoTVWQwk5XGG0mdlFhgT1lEneKepDlff1t2lR/Z9oWIzid8hkxZT6/y9yfw0X4cEGcKUva76yW5MtLoxYOGewiqrShM2gfnbAmGWQuiQmzz7LQmjONN4yihr3HVoZM/K72IVk5548EkMvYseYr0wlzBH2Ow== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39860400002)(39850400002)(39840400002)(189002)(199003)(6486002)(6436002)(77096006)(106356001)(101416001)(97736004)(105586002)(6506006)(2906002)(86362001)(4001350100001)(106116001)(50986999)(3280700002)(76176999)(68736007)(229853002)(102836003)(6116002)(6246003)(4326007)(54356999)(3846002)(36756003)(38730400002)(2501003)(189998001)(7736002)(81156014)(5660300001)(3660700001)(66066001)(33656002)(2950100002)(81166006)(25786008)(83716003)(8936002)(92566002)(8676002)(99286003)(54906002)(6512007)(53936002)(305945005)(2900100001)(82746002)(83506001)(122556002)(93886004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2017 17:57:28.1554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: "i2rs@ietf.org" , "shares@ndzh.com" Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 18:04:42 -0000 SGkgQW5keSwNCg0KVGhlcmUgaXMgYW4gZWZmb3J0IGdvaW5nIHRvIHJlc29sdmUgdGhpcyBpc3N1 ZS4gIFNlZSB0aGUgIm1vZGVsaW5nIG9wdGlvbnMgZm9yIGRyYWZ0LWlldGYtaTJycy15YW5nLW5l dHdvcmstdG9wbyIgdGhyZWFkIGZvciB0aGUgbGF0ZXN0Lg0KDQoNCg0KSGkgTWFydGluLA0KDQo+ IEkgc3RpbGwgZG9uJ3QgcmVhbGx5DQo+IHVuZGVyc3RhbmQgdGhlIGV4cGVjdGVkIGxpZmVjeWNs ZSBvZiB0aGVzZSBzZXJ2ZXIgcHJvdmlkZWQgaW5zdGFuY2VzOw0KPiBzcGVjaWZpY2FsbHksIGNh biB0aGV5IGNvbWUgYW5kIGdvIGNvbXBsZXRlbHkgZHluYW1pY2FsbHksIGV2ZW4gaWYNCj4gdGhl cmUgYXJlIG90aGVyIGluc3RhbmNlcyB0aGF0IHJlZmVyIHRvIHRoZW0/DQoNClllcywgdGhlICdz ZXJ2ZXItcHJvdmlkZWQnIG5vZGVzIGFyZSBvcHN0YXRlIG5vZGVzLiAgVGhhdCB0aGV5J3JlIGJl aW5nIHBvdGVudGlhbGx5IHJlZmVyZW5jZWQgYnkgY29uZmlnIG5vZGVzIGlzIGluY29uc2VxdWVu dGlhbC4NCg0KDQoNCktlbnQNCg0KDQoNCg0K From nobody Mon Feb 20 07:35:30 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48841296AE for ; Mon, 20 Feb 2017 07:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0uZ3aejJDCz for ; Mon, 20 Feb 2017 07:35:26 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0139.outbound.protection.outlook.com [104.47.37.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77431294B1 for ; Mon, 20 Feb 2017 07:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j/ye+Arqk5dYBdUtpIaDv72Ch/E6x94SkGQotM5pK2k=; b=YEOn7kISfIrBAtEk89ztkHc4pzH+mqVtx+XhzRv6tLZQ0BNKRbbZsRPnXWAjjCf6rRwi525LmUjZWupftgj5RqsMokOfBSedGSe3IXEBec4wOYiDV2R01xFe19i1+udnTIk+WD6v6r2MzCFtaOnyBbawFzZ/tGwrZWr/ZsFfH3o= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Mon, 20 Feb 2017 15:35:25 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0919.015; Mon, 20 Feb 2017 15:35:25 +0000 From: Kent Watsen To: Martin Bjorklund , "xufeng.liu.ietf@gmail.com" Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFoWKoA///awYCAAIH9AIADEzSAgABfVYD//9IJAIAFwz4A Date: Mon, 20 Feb 2017 15:35:25 +0000 Message-ID: <36B6098C-84A9-480C-AF83-1EF04E18E50F@juniper.net> References: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <20170216.221949.1797970554181706414.mbj@tail-f.com> <9B5F937A-346D-429A-9E9C-1D453BED83B3@juniper.net> In-Reply-To: <9B5F937A-346D-429A-9E9C-1D453BED83B3@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 699a2505-06a0-4046-8d3a-08d459a61749 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:A7NKpLuI/00P+ZF3dlGDdQQ9DFsYokfCZMeweoNnTih7q4YJ96F3TSuFQFn6kdyANH34igruEpOkxltdETzcQF09NJ4QvdLBPlvn53jg1RbTnhQi3bCKsMssA/0eaKA5KpdmSBSDp0V+zPnfz+076RG67ggF9GGlberAFa8S7QPFEjBlct/TkQ32CJSVyyZdbfw3u1mW7UfPI6oxLRDkyu1Yl6nJJxYffTb8IJr0fKcuBOhZBiRaFTIjQfvKBARBNxSf1Q5OfmLvj19j5NT6gbMEJfUalRbqnY+tr2gj8I7NuMDTBZbHL+GImOKR4k5+XddFBcAqJzZf1EExcRP5yA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02243C58C6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(189002)(199003)(105586002)(101416001)(39060400002)(122556002)(2950100002)(38730400002)(106356001)(66066001)(561944003)(36756003)(83716003)(83506001)(33656002)(92566002)(82746002)(6306002)(50986999)(76176999)(54356999)(230783001)(93886004)(53936002)(6512007)(99286003)(5660300001)(2900100001)(2906002)(86362001)(4001350100001)(6486002)(3280700002)(6436002)(106116001)(6506006)(3660700001)(97736004)(229853002)(25786008)(6246003)(77096006)(189998001)(7736002)(305945005)(81166006)(4326007)(2501003)(81156014)(8676002)(8936002)(6116002)(3846002)(102836003)(68736007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4A50DBCBEE02C445A82C2543DB09A8E0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2017 15:35:25.4320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 15:35:28 -0000 SGkgTWFydGluLA0KDQpTcGVha2luZyB3aXRoIHRoZSBhdXRob3JzIG9mZmxpbmUgbGF0ZSBsYXN0 IHdlZWssIHRoaXMgZGlzY3Vzc2lvbg0KcmVnYXJkaW5nIE9QVElPTi0yIGNhbWUgdXAsIGFuZCBJ IG1lbnRpb25lZCBhZ2FpbiBteSBjb25jZXJucyBmb3INCkNPTiAnYyc6DQoNCiAgYykgdW5hYmxl IHRvIHJldHVybiB0aGUgb3BzdGF0ZSB2YWx1ZSBmb3IgYW55IGNvbmZpZ3VyZWQgbm9kZQ0KIA0K Li4udG8gd2hpY2ggdGhlIFh1ZmVuZyBzdWdnZXN0ZWQgd2UgdGFrZSB5b3VyIGlkZWEgdG8gaGVh cnQuDQpTcGVjaWZpY2FsbHksIHJhdGhlciB0aGFuIGF1Z21lbnQgPGdldC1jb25maWc+LCBsZXQn cyBsb29rLWFoZWFkIGFuZA0KdXNlIHRoZSBvcHN0YXRlIDxnZXQtZGF0YT4gUlBDIChpbmNsdWRp bmcgdGhlICdvcmlnaW4nIGF0dHJpYnV0ZSkgDQpub3cuICBUaGlzIHdheSwgPGdldC1jb25maWc+ IHdvdWxkIHJldHVybiB0aGUgY29uZmlndXJlZCB2YWx1ZSwgd2hpbGUNCjxnZXQtZGF0YT4gY291 bGQgcmV0dXJuIHRoZSBhcHBsaWVkIHZhbHVlLCBhcyB3ZWxsIGFzIHRoZSBzeXN0ZW0NCmdlbmVy YXRlZC9sZWFybmVkIHRvcG9sb2d5LiAgU28sIGFzIGluIHByZXZpb3VzIGZhc2hpb24sIEkgZm9y bWFsbHkNCnN1Ym1pdCBPUFRJT04gMzoNCg0KDQoNCk9QVElPTiAzOiB1c2UgbmV3IFJQQyA8Z2V0 LXRvcG8tZGF0YT4sIHdoaWNoIGlzIGp1c3QgbGlrZSA8Z2V0LWRhdGE+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpUaGlzIG9wdGlvbiBkZWZpbmVzIGEgbmV3IFJQQyBjYWxsZWQgPGdldC10b3BvLWRhdGE+IHRo YXQgaXMgZmFzaGlvbmVkDQpkaXJlY3RseSBhZnRlciB0aGUgPGdldC1kYXRhPiBSUEMgZnJvbSB0 aGUgcmV2aXNlZC1kYXRhc3RvcmVzIGRyYWZ0Lg0KVGhlIFJQQyBpcyByZW5hbWVkIGZvciBmZWFy IG9mIGNvbmZsaWN0aW5nIHdpdGggYW55IHBvc3NpYmxlIGZ1dHVyZQ0KY2hhbmdlcyB0aGF0IG1h eSBvY2N1ciB0byB0aGUgcGxhbm5lZCA8Z2V0LWRhdGE+IFJQQy4gIFRoZSA8Z2V0LXRvcG8tZGF0 YT4gUlBDIHdvdWxkIHRha2UgYW4gb3B0aW9uYWwgJ3dpdGgtb3JpZ2luLWRhdGEnIHNlbGVjdG9y IHRvIHJldHVybiB0aGUNCidvcmlnaW4nIGF0dHJpYnV0ZS4NCg0KUFJPUzoNCiAgYSkgZG9lcyBO T1QgYnJlYWsgbGVnYWN5IGNsaWVudHMgKGhvdyB3ZSBnb3QgaGVyZSkuDQogIGIpIGFiaWxpdHkg dG8gcmV0dXJuIHRoZSBvcHN0YXRlIHZhbHVlIGZvciBhbnkgY29uZmlndXJlZCBub2RlLg0KICBj KSBtaW5pbWFsIHJld3JpdGUgb2YgdGhlIG1vZHVsZSBmb3IgcmV2aXNlZC1kYXRhc3RvcmVzIHNv bHV0aW9uLg0KDQpDT05TOg0KICBhKSBzZWVtcyBsaWtlIGEgc2hhZHkgdGhpbmcgZm9yIGFuIElF VEYgbW9kdWxlIHRvIGRvLg0KICBiKSB3b3VsZCBuZWVkIHRvIHJlc29sdmUgb3RoZXIgaXNzdWVz IChlLmcuLCBob3cgdG8gc3VwcG9ydCB3aXRoDQogICAgIFJFU1RDT05GKSwgd2hpY2ggbWFrZXMg dGhlIGRyYWZ0IHF1aXRlIGEgYml0IG1vcmUgdGhhbiBqdXN0DQogICAgIGEgbW9kdWxlIGRyYWZ0 Lg0KICBjKSByZXF1aXJlcyBzZXJ2ZXIgdG8gc3VwcG9ydCBtZXRhZGF0YSwgd2hpY2ggaXMgYSBy ZWxhdGl2ZWx5DQogICAgIG5ldyBjb25jZXB0IGFuZCBtYXliZSBub3Qgd2VsbCBzdXBwb3J0ZWQg Ynkgc2VydmVycy4NCg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQotLS0tLS0tT1JJR0lOQUwgTUVT U0FHRS0tLS0tLS0NCj4+Pj4gMikgSXQgZG9lc24ndCBzYXkgYW55dGhpbmcgYWJvdXQgaG93IHRo ZSBvcHN0YXRlIGRhdGEgaXMgc3RvcmVkIG9uIHRoZQ0KPj4+PiAgICBzZXJ2ZXIuICBUaGUgb3Bz dGF0ZSBkYXRhIGlzIG5vdCBtb2RlbGVkIGF0IGFsbC4gIFRoaXMgYXBwcm9hY2gNCj4+Pj4gICAg b25seSBkZWZpbmVzIGEgcHJlc2VudGF0aW9uLWxheWVyIGZvcm1hdCBmb3IgaG93IG9wc3RhdGUg ZGF0YSBjYW4NCj4+Pj4gICAgYmUgcmV0dXJuZWQgdmlhIGFuIFJQQy4gIFRoZSBzZXJ2ZXIgaXMg ZnJlZSB0byBwZXJzaXN0IHRoZSBvcHN0YXRlDQo+Pj4+ICAgIGRhdGEgYW55d2F5IGl0IHdhbnRz LCBwZXJoYXBzIGluIGFuIGludGVybmFsIGRhdGFzdG9yZSBjYWxsZWQNCj4+Pj4gICAgJ29wZXJh dGlvbmFsLXN0YXRlJyBvciBpbiBhbiB1YmVyLWRhdGFzdG9yZSB3aXRoIHRoZSBvcHN0YXRlIGRh dGENCj4+Pj4gICAgZmxhZ2dlZCB3aXRoIGEgZGF0YXN0b3JlPSdvcGVyLXN0YXRlJyBhdHRyaWJ1 dGUuICBSZWdhcmRsZXNzLCBpdCdzDQo+Pj4+ICAgIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCwg YW5kIHRoZSBjb25jZXB0dWFsIGRhdGFzdG9yZSBtb2RlbCBpcw0KPj4+PiAgICBwcmVzZXJ2ZWQu DQo+Pj4gDQo+Pj4gWW91IGFyZSBlc3NlbnRpYWxseSBkZWZpbmluZyBhIG5ldyBvcGVyYXRpb24s IGJ1dCBkbyBpdCBieSBtb2RpZnlpbmcgdGhlDQo+Pj4gc2VtYW50aWNzIG9mIGFuIGV4aXN0aW5n IG9uZS4gIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYTsgaXQgaXMNCj4+PiBiZXR0 ZXIgdG8gZGVmaW5lIGEgbmV3IHJwYy4NCj4+IA0KPj4gW1h1ZmVuZ10gSXMgdXNpbmcgYSBuZXcg cnBjIGlzIGFjY2VwdGFibGU/IElmIHNvLCB0aGlzIGNvdWxkIGJlIGEgdmlhYmxlDQo+PiBvcHRp b24uDQo+DQo+VGhlIGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3JlcyBwcm9wb3Nl cyBhIG5ldyBycGMgKG1heWJlDQo+PGdldC1kYXRhPikgdG8gcmV0dXJuIGRhdGEgZnJvbSB0aGUg bmV3IG9wZXJhdGlvbmFsLXN0YXRlIGRhdGFzdG9yZS4NCj5UaGlzIGlzIElNTyBiZXR0ZXIgdGhh biBhZGRpbmcgb3BzdGF0ZSBub2RlcyB0byB0aGUgcmVwbHkgdG8gYQ0KPjxnZXQtY29uZmlnPiBy ZXF1ZXN0Lg0KDQoNCk1hcnRpbiwNCg0KR29pbmcgYmFjayB5b3VyIGVhcmxpZXIgImJldHRlciB0 byBkZWZpbmUgYSBuZXcgcnBjIiBjb21tZW50LCBJIGZhaWwgdG8NCnNlZSBob3cgdGhpcyBwcm9w b3NhbCBpcyBzaWduaWZpY2FudGx5IGRpZmZlcmVudCB0aGFuIFJGQyA2MjQzLg0KDQpJZiBub3Qg dGhpcywgdGhlbiB0aGUgbmV3IFJQQyB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSA8Z2V0LWNvbmZp Zy1leD4NCm1vcmUgdGhhbiB0aGUgcGxhbm5lZCA8Z2V0LWRhdGE+LCBhcyB0aGUgZ29hbCBpcyB0 byByZXR1cm4gJ3J1bm5pbmcnDQorICJzb21lIG9wc3RhdGUiIChub3QganVzdCBvcHN0YXRlKS4N Cg0KU3RpbGwsIGluIGxvb2tpbmcgdGhlIHRoZSBwcm9zL2NvbnMsIE9wdGlvbiAxIGFwcGVhcnMg c3Ryb25nZXIgLSBvbmx5DQp0aGUgYXV0aG9ycyBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIGhhdmlu ZyB0byByZXdyaXRlIHRoZWlyIG1vZGVscw0KbGF0ZXIuLi4NCg0KS2VudA0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppMnJzIG1haWxp bmcgbGlzdA0KaTJyc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pMnJzDQoNCg0K From nobody Mon Feb 20 10:47:21 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15131294C7 for ; Mon, 20 Feb 2017 10:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGg3cU9n15ji for ; Mon, 20 Feb 2017 10:47:18 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3885129494 for ; Mon, 20 Feb 2017 10:47:17 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id c85so88214041wmi.1 for ; Mon, 20 Feb 2017 10:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v1nB2MIS982xgwEptsp7ApTgF7CabVugeHE7GmK6hSI=; b=GcpNBUF4n7UyvGzvloEiiHguvs58MYxIq0FAmax8t8pBdwdn5eGOExepf+nQTew4Ae WcBtu2x8fKkpcSkpdeiRAjcyt+4GuTJ0sKp4djO/9rdXQgjJFRDb/vHOk2AlR0NdACEy UI/0JnEYuj9DJjWgP5VTX1Wl3Jfbbvm7buw44YsBPFMp5x4SJaGk5HhhgCSBm6foBkRY 96nE1IaeN08MgbY1eo34E1W1VYYpLGf84dDDT5/4Nd5ifFciVJ1sSJHWzCCyumFQoaWP gpxv7kY5eLDQ5VkaLrAlvlSHYMMchdLwzqDLvGVkDrSAMFnG3cHWU9FH0WtBpS6/OjfP S12A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v1nB2MIS982xgwEptsp7ApTgF7CabVugeHE7GmK6hSI=; b=EDj3CacODxAwYjQ66fSKW4FqoSRK07QTyQsuHEXHV8roRoYlt+2qfglI0cWmyb6tFI gfkB4u+P3jKSRXqLuNDpcCwAUoUVXpDtAq5Kmgw/1Zw372LcVmRYMoqpSJT5EPf68pg5 6OQ128BSEIJ91YWxojS+0AwIjDhVLirG3ny+Bb9OsArlwLDTHfQ45b0CUOwWqo83t9U9 t0+F+ZC+0Dk6FJVFUz3oj07Bs+FRZkaALbXZK2HUiqKJZVPuLIWi7jwmHhvskSicZ30X SlSzMMb3g36fxcKY3b1Mw94Cejy/gXIH/6wok5qj/Bsm7Hp5R2pH9sFhjpAEz3ZJgTHe /oCQ== X-Gm-Message-State: AMke39kv/zzIOzOAtNfvWyf5NgN3qcMydyEyjKrI3+xUxqvoalpmQSv+PwfCNfsecX+o3WEFsMDg5ANQoubrCg== X-Received: by 10.28.103.3 with SMTP id b3mr19150980wmc.99.1487616436410; Mon, 20 Feb 2017 10:47:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Mon, 20 Feb 2017 10:47:15 -0800 (PST) In-Reply-To: <20170216.221949.1797970554181706414.mbj@tail-f.com> References: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> <20170214.174106.332845199336010868.mbj@tail-f.com> <007601d2886a$bf085170$3d18f450$@gmail.com> <20170216.221949.1797970554181706414.mbj@tail-f.com> From: Andy Bierman Date: Mon, 20 Feb 2017 10:47:15 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114a91b24148b40548fab1b1 Archived-At: Cc: "i2rs@ietf.org" , Kent Watsen , Xufeng Liu Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 18:47:21 -0000 --001a114a91b24148b40548fab1b1 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 16, 2017 at 1:19 PM, Martin Bjorklund wrote: > "Xufeng Liu" wrote: > > > > > > > -----Original Message----- > > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin > Bjorklund > > > Sent: Tuesday, February 14, 2017 11:41 AM > > > To: kwatsen@juniper.net > > > Cc: i2rs@ietf.org > > > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network- > topo > > > > > > Kent Watsen wrote: > > > > > > > > > > > > [moving yang-doctors to BCC] > > > > > > > > > > > > >> OPTION 1: separate /foo and /foo-state trees > > > > >> -------------------------------------------- > > > > >> > > > > >> This option was/is described here: > > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > > > >> > > > > >> PROS: > > > > >> a) does NOT break legacy clients (how we got here) > > > > >> b) consistent with convention used in many IETF modules > > > > >> c) able to show if/how opstate may differ from configured values > > > > >> > > > > >> CONS: > > > > >> a) questionably valid YANG leafref usage > > > > > > > > > > What does this mean? > > > > > > > > I'm referring to how the description statement explains that the > > > > server may look to operational state in order to resolve the leafref, > > > > which is to result in behavior similar to pre-configuration in RFC > > > > 7223. > > > > > > Ok, I didn't pay close attention to the proposal in the quoted email. > > > > > > I would design this a bit differently. The config true leaf > "dependency" > > should > > > have a leafref to the config false node name, with require-instance > false. > > The > > > description should explain that the configuration item will be used by > the > > server > > > if all dependencies exist. When the configuration item is used, it > shows > > up in the > > > config false list. > > > > > > This way, the leafref usage is valid and straight forward. > > > > > > > >> b) complex server implementation (to handle require-instance > > > > >> false) > > > > > > > > > >Can you elaborate on this one? > > > > > > > > This is primarily a reflection of the CON listed above, in that it > > > > seems that a server would need to have special handling for when > > > > dependencies transition from being present to not-present and vice > > > > versa, much like the code to handle when a physical card is plugged > in > > > > or removed. > > > > > > Yes, but I think this is inherent to the problem at hand. Even with > the > > config true > > > solution defined in the current draft, it is not clear how things that > > were created > > > by the server would be deleted (if there were references to them). > > > > > > > Note: I should've listed this as a CON for OPTION 2 as well. > > > > > > > > > > > > > > > > >> c) eventually the module would need to migrate to the long-term > > > > >> solution, which would result in needing to also rewrite all > > > > >> modules that have augmented it (e.g., ietf-te-topology). > > > > >> d) leafref path expressions really only work for configuration > > data, > > > > >> though a clever server could have a special ability to peak > at > > > > >> the opstate values when doing validations. Of course, with > > > > >> require-instance is false, the value of leafref based > validation > > > > >> checking is negated anyway, even for config true nodes, so > this > > > > >> may not matter much. > > > > >> > > > > >> > > > > >> > > > > >> OPTION 2: explicit client-option to also return tagged opstate > data > > > > >> ------------------------------------------------------------ > ------- > > > > >> > > > > >> This option takes a couple forms. The first is module-specific > and > > > > >> the second is generic. In both cases, the idea is modeled after > > > > >> the with-defaults solution (RFC6243), wherein the client passes a > > > > >> special flag into causing the server to also return > > > > >> opstate data, having a special metadata flag set, intermingled > with > > > > >> the configuration data. > > > > >> > > > > >> > > > > >> 2A: Module-specific version > > > > >> > > > > >> module foo { > > > > >> import ietf-netconf { prefix nc; } > > > > >> import ietf-yang-metadata { prefix md; } > > > > >> md:annotation server-provided { > > > > >> type boolean; > > > > >> } > > > > >> container nodes { > > > > >> config true; > > > > >> list node { > > > > >> key "name"; > > > > >> leaf name { type string; } > > > > >> leaf dependency { > > > > >> type leafref { > > > > >> path "../node/name" > > > > >> require-instance false; > > > > >> } > > > > >> } > > > > >> } > > > > >> } > > > > >> augment /nc:get-config/nc:input { > > > > >> leaf with-server-provided { > > > > >> type boolean; > > > > >> } > > > > >> } > > > > >> } > > > > > > > > > > I don't think this solution is substantially different from the > > > > > solution in draft-ietf-i2rs-yang-network-topo-10. You have just > > > > > moved a config false leaf to a meta-data annotation. This solution > > > > > suffers from the same problems as the solution in > > > > > draft-ietf-i2rs-yang-network-topo-10. > > > > > > > > There are two primary differences: > > > > > > > > 1) It doesn't break legacy clients > > > > > > The solution in the draft doesn't break legacy clients either - > there's a > > config > > > false leaf among the config true. No problem. > > > > > > > , because it requires the client to > > > > explicitly pass a 'with-server-provided' flag in the > > > > request in order to get back the extended response. Likewise, it > > > > doesn't break backup/restore workflows, as the server can discard > > > > any 'server-provided' nodes passed in an operation. > > > > > > Huh? This goes against the defined behavior of 6241 + 7950. This is > the > > main > > > problem with the solution in the current draft. > > > > > > If a client sends a for data in running, the server cannot > > send back > > > data that is not in running. > > > > > > > Lastly, it doesn't break /, as there is no > comingling > > > > of opstate data in the 'running' datastore. > > > > > > > > 2) It doesn't say anything about how the opstate data is stored on > the > > > > server. The opstate data is not modeled at all. This approach > > > > only defines a presentation-layer format for how opstate data can > > > > be returned via an RPC. The server is free to persist the opstate > > > > data anyway it wants, perhaps in an internal datastore called > > > > 'operational-state' or in an uber-datastore with the opstate data > > > > flagged with a datastore='oper-state' attribute. Regardless, it's > > > > an implementation detail, and the conceptual datastore model is > > > > preserved. > > > > > > You are essentially defining a new operation, but do it by modifying > the > > > semantics of an existing one. I don't think this is a good idea; it is > > better to > > > define a new rpc. > > > > [Xufeng] Is using a new rpc is acceptable? If so, this could be a viable > > option. > > The draft-ietf-netmod-revised-datastores proposes a new rpc (maybe > ) to return data from the new operational-state datastore. > This is IMO better than adding opstate nodes to the reply to a > request. > > +1 There are billions of combinations of letters than can be used as YANG identifiers. The letters "get-config" are already used. Pick a different combination. > > /martin > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a114a91b24148b40548fab1b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 16, 2017 at 1:19 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
"Xufeng Liu" <= ;xufeng.liu.ietf@gmail.com= > wrote:
>
>
> > -----Original Message-----
> > From: i2rs [mailto:i2rs-= bounces@ietf.org] On Behalf Of Martin Bjorklund
> > Sent: Tuesday, February 14, 2017 11:41 AM
> > To: kwatsen@juniper.net
> > Cc: i2rs@ietf.org
> > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-net= work-topo
> >
> > Kent Watsen <kwatsen@ju= niper.net> wrote:
> > >
> > >
> > > [moving yang-doctors to BCC]
> > >
> > >
> > > >> OPTION 1: separate /foo and /foo-state trees
> > > >> -------------------------------------------- > > > >>
> > > >> This option was/is described here:
> > > >> https://www.= ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > >>
> > > >> PROS:
> > > >>=C2=A0 =C2=A0a) does NOT break legacy clients (how w= e got here)
> > > >>=C2=A0 =C2=A0b) consistent with convention used in m= any IETF modules
> > > >>=C2=A0 =C2=A0c) able to show if/how opstate may diff= er from configured values
> > > >>
> > > >> CONS:
> > > >>=C2=A0 =C2=A0a) questionably valid YANG leafref usag= e
> > > >
> > > > What does this mean?
> > >
> > > I'm referring to how the description statement explains = that the
> > > server may look to operational state in order to resolve the= leafref,
> > > which is to result in behavior similar to pre-configuration = in RFC
> > > 7223.
> >
> > Ok, I didn't pay close attention to the proposal in the quote= d email.
> >
> > I would design this a bit differently.=C2=A0 The config true leaf= "dependency"
> should
> > have a leafref to the config false node name, with require-instan= ce false.
> The
> > description should explain that the configuration item will be us= ed by the
> server
> > if all dependencies exist.=C2=A0 When the configuration item is u= sed, it shows
> up in the
> > config false list.
> >
> > This way, the leafref usage is valid and straight forward.
> >
> > > >>=C2=A0 =C2=A0b) complex server implementation (to ha= ndle require-instance
> > > >> false)
> > > >
> > > >Can you elaborate on this one?
> > >
> > > This is primarily a reflection of the CON listed above, in t= hat it
> > > seems that a server would need to have special handling for = when
> > > dependencies transition from being present to not-present an= d vice
> > > versa, much like the code to handle when a physical card is = plugged in
> > > or removed.
> >
> > Yes, but I think this is inherent to the problem at hand.=C2=A0 E= ven with the
> config true
> > solution defined in the current draft, it is not clear how things= that
> were created
> > by the server would be deleted (if there were references to them)= .
> >
> > > Note: I should've listed this as a CON for OPTION 2 as w= ell.
> > >
> > >
> > >
> > > >>=C2=A0 =C2=A0c) eventually the module would need to = migrate to the long-term
> > > >>=C2=A0 =C2=A0 =C2=A0 solution, which would result in= needing to also rewrite all
> > > >>=C2=A0 =C2=A0 =C2=A0 modules that have augmented it = (e.g., ietf-te-topology).
> > > >>=C2=A0 =C2=A0d) leafref path expressions really only= work for configuration
> data,
> > > >>=C2=A0 =C2=A0 =C2=A0 though a clever server could ha= ve a special ability to peak at
> > > >>=C2=A0 =C2=A0 =C2=A0 the opstate values when doing v= alidations.=C2=A0 Of course, with
> > > >>=C2=A0 =C2=A0 =C2=A0 require-instance is false, the = value of leafref based validation
> > > >>=C2=A0 =C2=A0 =C2=A0 checking is negated anyway, eve= n for config true nodes, so this
> > > >>=C2=A0 =C2=A0 =C2=A0 may not matter much.
> > > >>
> > > >>
> > > >>
> > > >> OPTION 2: explicit client-option to also return tag= ged opstate data
> > > >> ----------------------------------------------= ---------------------
> > > >>
> > > >> This option takes a couple forms.=C2=A0 The first i= s module-specific and
> > > >> the second is generic.=C2=A0 In both cases, the ide= a is modeled after
> > > >> the with-defaults solution (RFC6243), wherein the c= lient passes a
> > > >> special flag into <get-config> causing the se= rver to also return
> > > >> opstate data, having a special metadata flag set, i= ntermingled with
> > > >> the configuration data.
> > > >>
> > > >>
> > > >> 2A: Module-specific version
> > > >>
> > > >>=C2=A0 =C2=A0 module foo {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0import ietf-netconf { pre= fix nc; }
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0import ietf-yang-metadata= { prefix md; }
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0md:annotation server-prov= ided {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean;
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0container nodes {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config true;
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list node {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key = "name";
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf= name { type string; }
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf= dependency {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 type leafref {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 path "../node/name"
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 require-instance false;
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 }
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0augment /nc:get-config/nc= :input {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf with-server-= provided {
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type= boolean;
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > >>=C2=A0 =C2=A0 }
> > > >
> > > > I don't think this solution is substantially differ= ent from the
> > > > solution in draft-ietf-i2rs-yang-network-topo-10.= =C2=A0 You have just
> > > > moved a config false leaf to a meta-data annotation.=C2= =A0 This solution
> > > > suffers from the same problems as the solution in
> > > > draft-ietf-i2rs-yang-network-topo-10.
> > >
> > > There are two primary differences:
> > >
> > > 1) It doesn't break legacy clients
> >
> > The solution in the draft doesn't break legacy clients either= - there's a
> config
> > false leaf among the config true.=C2=A0 No problem.
> >
> > >=C2=A0 =C2=A0 , because it requires the client to
> > >=C2=A0 =C2=A0 explicitly pass a 'with-server-provided'= ; flag in the <get-config>
> > >=C2=A0 =C2=A0 request in order to get back the extended respo= nse.=C2=A0 Likewise, it
> > >=C2=A0 =C2=A0 doesn't break backup/restore workflows, as = the server can discard
> > >=C2=A0 =C2=A0 any 'server-provided' nodes passed in a= n <edit-config> operation.
> >
> > Huh?=C2=A0 This goes against the defined behavior of 6241 + 7950.= =C2=A0 This is the
> main
> > problem with the solution in the current draft.
> >
> > If a client sends a <get-config> for data in running, the s= erver cannot
> send back
> > data that is not in running.
> >
> > >=C2=A0 =C2=A0 Lastly, it doesn't break <lock>/<u= nlock>, as there is no comingling
> > >=C2=A0 =C2=A0 of opstate data in the 'running' datast= ore.
> > >
> > > 2) It doesn't say anything about how the opstate data is= stored on the
> > >=C2=A0 =C2=A0 server.=C2=A0 The opstate data is not modeled a= t all.=C2=A0 This approach
> > >=C2=A0 =C2=A0 only defines a presentation-layer format for ho= w opstate data can
> > >=C2=A0 =C2=A0 be returned via an RPC.=C2=A0 The server is fre= e to persist the opstate
> > >=C2=A0 =C2=A0 data anyway it wants, perhaps in an internal da= tastore called
> > >=C2=A0 =C2=A0 'operational-state' or in an uber-datas= tore with the opstate data
> > >=C2=A0 =C2=A0 flagged with a datastore=3D'oper-state'= attribute.=C2=A0 Regardless, it's
> > >=C2=A0 =C2=A0 an implementation detail, and the conceptual da= tastore model is
> > >=C2=A0 =C2=A0 preserved.
> >
> > You are essentially defining a new operation, but do it by modify= ing the
> > semantics of an existing one.=C2=A0 I don't think this is a g= ood idea; it is
> better to
> > define a new rpc.
>
> [Xufeng] Is using a new rpc is acceptable? If so, this could be a viab= le
> option.

The draft-ietf-netmod-revised-datastores proposes a new rpc (maybe
<get-data>) to return data from the new operational-state datastore.<= br> This is IMO better than adding opstate nodes to the reply to a
<get-config> request.


+1

There are = billions of combinations of letters than can be used as YANG identifiers.
The letters "get-config" are already used.=C2=A0 Pick a = different combination.

=C2=A0

/martin


Andy
= =C2=A0

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

--001a114a91b24148b40548fab1b1-- From nobody Tue Feb 21 01:33:12 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E812959A for ; Tue, 21 Feb 2017 01:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 VGtLhzMkmHoR for ; Tue, 21 Feb 2017 01:33:09 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DAF1298A9 for ; Tue, 21 Feb 2017 01:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9491; q=dns/txt; s=iport; t=1487669588; x=1488879188; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=usd8vNAhcb2BVmvgDo0AnrL06Sb9r0zPbkuGqCYEy2E=; b=M0Z4xvSB0BItYIJUq1nbaqvxiASqUbjH1OXiJvcTPyU6Um/6jf/vxWY1 dmsSNfNkcwo9oNO1r3P1jETaur3QBAsLF4PPdI6Kjsgxj2Km5vVn2NfU6 HCAJIrnRPInYX6SnFXSqO4oD9dEwaskfCtOgA1Smq7A3g2P2DiZSDU2a4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2BQDkCKxY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+BRidfjlWRJJAIgx2CD4INhiICgxsXAQIBAQEBAQEBYiiEcQE?= =?us-ascii?q?FeRALGCcHRhEGDQYCAQEXiVOwRyuLLQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GT?= =?us-ascii?q?IIFgmqEPoV7BZwIkh2Be4Ubgy0jhiiLHogGIQMzgQAgFAgXFYcGQDWLEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,189,1484006400"; d="scan'208,217";a="650869614" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 09:33:05 +0000 Received: from [10.63.23.109] (dhcp-ensft1-uk-vla370-10-63-23-109.cisco.com [10.63.23.109]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1L9X576030373; Tue, 21 Feb 2017 09:33:05 GMT To: Andy Bierman References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1@SJCEML703-CHM.china.huawei.com> From: Robert Wilton Message-ID: <7b5989e8-d920-d236-644a-3243f91267b1@cisco.com> Date: Tue, 21 Feb 2017 09:33:05 +0000 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: multipart/alternative; boundary="------------0BC56CF80F48C1B653B4A48B" Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 09:33:11 -0000 This is a multi-part message in MIME format. --------------0BC56CF80F48C1B653B4A48B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, On 16/02/2017 22:36, Andy Bierman wrote: > > > On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm > > wrote: > > There are actually a number of interesting implications with > regards to NACM. NACM could indeed be a key to the solution if it > provides sufficient flexibility with regards to articulating and > enforcing authorization rules. Regarding this, I have a number of > questions/comments: > > -If a subtree contains objects that a client does not have write > privileges for, will the client be prevented from locking the > subtree? How about the case when the client does not even have > read privileges? > > > locking and NACM are 2 different things. > NETCONF has datastore (global) locks and subtree (partial) locks. > There is no mechanism in NACM or elsewhere that constrains the values > that a particular client can use. (NACM controls access to the rpc, > with no > control over specific input paramters). > > > > > The current NACM-bis draft states in section 3.7.2 that this is > not the case – i.e. a client is able to lock an entire subtree, > even in cases when there is not a single object in that subtree > that the client actually has access privileges to. > > To me, this does not seem right. It just invites abuse. > > Now, there is still the possibility to restrict access to the > operation overall. But again, this means that you have to give a > users an all-or-nothing choice. Too inflexible. By the same > token that partial locks were supported to avoid requiring anyone > who needs the ability to conduct a transaction to lock down the > entire server, there should be the ability to restrict access to > the lock and partial-lock operation by targeted subtree. However, > this capability is currently missing. > > > > NACM was designed to be simple to implement. > Some complex features that were in VACM were intentionally left out of > NACM. > NETCONF locking is also intentionally simple. > > I would rather have NETCONF 2.0 use a mandatory implicit, optimistic > concurrent > locking model, rather than more band-aids on the optional explicit, > pessimistic > serialized locking model we have now. This is interesting. If you have time, then at some point, please can you expand on this idea, perhaps on the NETCONF alias? Thanks, Rob --------------0BC56CF80F48C1B653B4A48B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Andy,


On 16/02/2017 22:36, Andy Bierman wrote:


On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <alexander.clemm@huawei.com> wrote:

There are actually a number of interesting implications with regards to NACM.  NACM could indeed be a key to the solution if it provides sufficient flexibility with regards to articulating and enforcing authorization rules.  Regarding this, I have a number of questions/comments:

 

-          If a subtree contains objects that a client does not have write privileges for, will the client be prevented from locking the subtree? How about the case when the client does not even have read privileges? 


locking and NACM are 2 different things.
NETCONF has datastore (global) locks and subtree (partial) locks.
There is no mechanism in NACM or elsewhere that constrains the values
that a particular client can use. (NACM controls access to the rpc, with no
control over specific input paramters).




The current NACM-bis draft states in section 3.7.2 that this is not the case – i.e. a client is able to lock an entire subtree, even in cases when there is not a single object in that subtree that the client actually has access privileges to. 

 

To me, this does not seem right.  It just invites abuse. 

 

Now, there is still the possibility to restrict access to the operation overall.  But again, this means that you have to give a users an all-or-nothing choice.  Too inflexible.  By the same token that partial locks were supported to avoid requiring anyone who needs the ability to conduct a transaction to lock down the entire server, there should be the ability to restrict access to the lock and partial-lock operation by targeted subtree.  However, this capability is currently missing. 



NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out of NACM.
NETCONF locking is also intentionally simple.

I would rather have NETCONF 2.0 use a mandatory implicit, optimistic concurrent
locking model, rather than more band-aids on the optional explicit, pessimistic
serialized locking model we have now.
This is interesting.  If you have time, then at some point, please can you expand on this idea, perhaps on the NETCONF alias?

Thanks,
Rob

--------------0BC56CF80F48C1B653B4A48B-- From nobody Tue Feb 21 11:31:03 2017 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A502129494 for ; Tue, 21 Feb 2017 11:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xap76X2k5JC5 for ; Tue, 21 Feb 2017 11:30:59 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39469129489 for ; Tue, 21 Feb 2017 11:30:50 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id v186so121142030wmd.0 for ; Tue, 21 Feb 2017 11:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+XaMUyKZG9olOOf9T+STtZwx0u56ZxwrULyTpFbvFKU=; b=ypE1g8A+z7F9CjM6Nd1I3ga1Sn0E2EiAZWRLylRusnh3u8BEDCFpOOsaHtqW82ortv wyjmjk0+++dxg+2PwpkIqvQkSEjyPwnRQZn2FMkys8yI4iIGMH3Lg/JmwdCx5RM83uUw Q5BlvviOAMc4UxgD9zEAM4S4GaWcaw1s4yTnoPjKN9Wpmr5tq0I/2YSCW8Hk6glI+Mwn Z9ExtZJ79H7WDDss946LJpYVHCjZyNk/X8URSB1unQPFHjdFadUEBSGGN4us0Aznn1W3 DYWYI2igHA56vPRDjFg3ysI5Wg6bA4Z+UEMAzdhuBRPYhC1ofXQzgOhjbPRFBhF/IIWi Ce0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+XaMUyKZG9olOOf9T+STtZwx0u56ZxwrULyTpFbvFKU=; b=eQnVXh1dhAVJo3GVtESHV9qZCtLT4Z5kjhgF1wBUO/Z+V36msXokTIJzaKMjZYCxOO pea7JnPqKk5ASd0kLDnUeZdP1qv+UScIj+OMPuvHvRUZIwqV6TdBYg2kmIyKT0SYG140 vx+0SKiJFRtxF06Nwn2MC3sH1otJUHKNDS/v6gzJ/1BCDB1xvdRqJzF7m+31KzsLFrM5 W6pO+Lhk0M2L9MZHxBsAvz5VkMbrNVLvkfNbdgTA6tusaZeLhgpdbfVrWRcaZth/zc95 nKR9Uj7yhSsUcQ53cqoXPK6khECQcgtDqLPdnKLwjoq1DyJStxAUmxPLIUFX9EaJYtKr HR4A== X-Gm-Message-State: AMke39kU0aku8OzVUMJzPyHCei/z0aSKgdEaJ6ytXOLH0kcDkVa3QhrP+80y5PjC9MavYDyV9Fv/L565Nx0uSQ== X-Received: by 10.28.15.202 with SMTP id 193mr14545163wmp.99.1487705448746; Tue, 21 Feb 2017 11:30:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Tue, 21 Feb 2017 11:30:48 -0800 (PST) In-Reply-To: <7b5989e8-d920-d236-644a-3243f91267b1@cisco.com> References: <054b01d2888d$7aa8e120$6ffaa360$@ndzh.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF809F1@SJCEML703-CHM.china.huawei.com> <7b5989e8-d920-d236-644a-3243f91267b1@cisco.com> From: Andy Bierman Date: Tue, 21 Feb 2017 11:30:48 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a1145ac32cdaa7405490f6ab8 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] topo model use of NACM X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 19:31:00 -0000 --001a1145ac32cdaa7405490f6ab8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 21, 2017 at 1:33 AM, Robert Wilton wrote: > Hi Andy, > > On 16/02/2017 22:36, Andy Bierman wrote: > > > > On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm < > alexander.clemm@huawei.com> wrote: > >> There are actually a number of interesting implications with regards to >> NACM. NACM could indeed be a key to the solution if it provides suffici= ent >> flexibility with regards to articulating and enforcing authorization >> rules. Regarding this, I have a number of questions/comments: >> >> >> >> - If a subtree contains objects that a client does not have >> write privileges for, will the client be prevented from locking the >> subtree? How about the case when the client does not even have read >> privileges? >> > > locking and NACM are 2 different things. > NETCONF has datastore (global) locks and subtree (partial) locks. > There is no mechanism in NACM or elsewhere that constrains the values > that a particular client can use. (NACM controls access to the rpc, with = no > control over specific input paramters). > > > >> >> The current NACM-bis draft states in section 3.7.2 that this is not the >> case =E2=80=93 i.e. a client is able to lock an entire subtree, even in = cases when >> there is not a single object in that subtree that the client actually ha= s >> access privileges to. >> >> >> >> To me, this does not seem right. It just invites abuse. >> >> >> >> Now, there is still the possibility to restrict access to the operation >> overall. But again, this means that you have to give a users an >> all-or-nothing choice. Too inflexible. By the same token that partial >> locks were supported to avoid requiring anyone who needs the ability to >> conduct a transaction to lock down the entire server, there should be th= e >> ability to restrict access to the lock and partial-lock operation by >> targeted subtree. However, this capability is currently missing. >> > > > NACM was designed to be simple to implement. > Some complex features that were in VACM were intentionally left out of > NACM. > NETCONF locking is also intentionally simple. > > I would rather have NETCONF 2.0 use a mandatory implicit, optimistic > concurrent > locking model, rather than more band-aids on the optional explicit, > pessimistic > serialized locking model we have now. > > This is interesting. If you have time, then at some point, please can yo= u > expand on this idea, perhaps on the NETCONF alias? > > NETCONF does not really support concurrent transactions. It supports serialized transactions with explicit locks. More than that is complicated, so it's probably not going to change any time soon. Thanks, > Rob > > Andy --001a1145ac32cdaa7405490f6ab8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 21, 2017 at 1:33 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20

Hi Andy,


On 16/02/2017 22:36= , Andy Bierman wrote:
=20


On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <alexander.clemm@huawei.com> wrote:

There are actually a number of interesting implications with regards to NACM.=C2=A0 NACM could indeed be a ke= y to the solution if it provides sufficient flexibility with regards to articulating and enforcing authorization rules.=C2=A0 Regarding this, = I have a number of questions/comments:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a subtree contains objects that a client does not have write privileges for, will the client be prevented from locking the subtree? How about the case when the client does not even have read privileges?=C2=A0


locking and NACM are 2 different things.
NETCONF has datastore (global) locks and subtree (partial) locks.
There is no mechanism in NACM or elsewhere that constrains the values
that a particular client can use. (NACM controls access to the rpc, with no
control over specific input paramters).




The current NACM-bis draft states in section 3.7.2 that this is not the case =E2=80=93 i.e. a client is = able to lock an entire subtree, even in cases when there is not a single object in that subtree that the client actually has access privileges to.=C2=A0

=C2=A0

To me, this does not seem right.=C2=A0 It just invites abuse.=C2=A0

=C2=A0

Now, there is still the possibility to restrict access to the operation overall.=C2=A0 But again, this means that you have to give a users an all-or-nothing choice.=C2=A0 Too inflexible.=C2=A0 By the same token= that partial locks were supported to avoid requiring anyone who needs the ability to conduct a transaction to lock down the entire server, there should be the ability to restrict access to the lock and partial-lock operation by targeted subtree.=C2=A0 However, this capability is currently missing.=C2=A0



NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out of NACM.
NETCONF locking is also intentionally simple.

I would rather have NETCONF 2.0 use a mandatory implicit, optimistic concurrent
locking model, rather than more band-aids on the optional explicit, pessimistic
serialized locking model we have now.
This is interesting.=C2=A0 If you have time, then at some point, please can you expand on this idea, perhaps on the NETCONF alias?


NETCONF does not really supp= ort concurrent transactions.
It supports serialized transactions = with explicit locks.
More than that is complicated, so it's p= robably not going to change
any time soon.


Thanks,
Rob



Andy

--001a1145ac32cdaa7405490f6ab8--