From nobody Thu Jan 1 09:02:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDDA1A0105 for ; Thu, 1 Jan 2015 09:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtDvLKXQ7hRA for ; Thu, 1 Jan 2015 09:02:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id ECDF41A0120 for ; Thu, 1 Jan 2015 09:02:01 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 08B5C1280B44; Thu, 1 Jan 2015 18:01:58 +0100 (CET) Date: Thu, 01 Jan 2015 18:01:59 +0100 (CET) Message-Id: <20150101.180159.383715819274563402.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20141224073643.GA39117@elstar.local> References: <20141224073643.GA39117@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3EpmbKEvCQ4laihN_LXqwEvKgpk Cc: netmod@ietf.org Subject: Re: [netmod] [FWD] RFC 7405 on Case-Sensitive String Support in ABNF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 17:02:03 -0000 Hi, Juergen Schoenwaelder wrote: > Hi, > > this might be relevant for the YANG 1.1 specification Yes, I read this when it was still a draft. I have updated the grammar to use this new syntax. > (no idea whether > someone updates abnfgen and friends to support the new syntax). I added support for this new syntax to abnfgen and bap, and while testing this, I realized that abnfgen actually was too liberal in what it accepted; specifically, it would allow: yang-version-arg-str = < a string that matches the rule yang-version-arg > but bap correctly flags this as an error. The correct syntax is: yang-version-arg-str = < a string that matches the rule > < yang-version-arg > So I have fixed this across the grammar as well. /martin From nobody Fri Jan 2 05:14:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553561A1B69 for ; Fri, 2 Jan 2015 05:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f--oK4PD34Ip for ; Fri, 2 Jan 2015 05:14:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 76E281A1B59 for ; Fri, 2 Jan 2015 05:14:18 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 45C011280098; Fri, 2 Jan 2015 14:14:14 +0100 (CET) Date: Fri, 02 Jan 2015 14:14:24 +0100 (CET) Message-Id: <20150102.141424.805742182373718084.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201411181937.sAIJbguL080247@idle.juniper.net> References: <201411181937.sAIJbguL080247@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7Y4fMTnA9vMyrM-A4PK8Phy_VUg Cc: netmod@ietf.org Subject: [netmod] Y07: do not allow when or if-feature on key [Was: YANG 1.1 virtual interim 2014-11-19] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 13:14:21 -0000 Phil Shafer wrote: > * REVIEW :Y07: do not allow when or if-feature on keys > > No objection, though I'm not sure why the exception for > keys with identical conditions to their parents is worth > the time/trouble to explain. Forbidding it is simpler. I agree. Do we really want to allow: list x { if-feature "not (a or b)"; key y; leaf y { if-feature "(not a) and (not b)"; ... } ... } If we allow such constructs, do we really expect compilers to be able to detect this? In the case of "if-feature" it is doable, but not for "when" in general. Or are we saying that the argument strings must be character-by-character equal? What about whitespace? I agree w/ Phil; we should simply reject "when" and "if-feature" on keys. /martin From nobody Fri Jan 2 06:05:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467911A8746 for ; Fri, 2 Jan 2015 06:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76hqn5Vmkdya for ; Fri, 2 Jan 2015 06:05:24 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225F31A3BA6 for ; Fri, 2 Jan 2015 06:05:24 -0800 (PST) Received: from [195.113.220.113] (unknown [195.113.220.113]) by mail.nic.cz (Postfix) with ESMTPSA id B3BE5140266; Fri, 2 Jan 2015 15:05:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420207522; bh=pfpa9eOUirasnZO6ydISWmWGaIYsThgHPPsUoJWhrJQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qpzr4TGOQcNj9jWDTackNGNhDw36SfrgOjThiCP0jCgUEfMMVE0PbzQfTFxO8a0KM HwlnlUSFh03Ofgwx1T+K10dOx9MBZa1o+mlLSM/5139hUsiT8hhr+SQYObE6r1Chxg PH4P+ttIqPIVv56ZBcRMU0eZoQ+sT8jPEqOpa684= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150102.141424.805742182373718084.mbj@tail-f.com> Date: Fri, 2 Jan 2015 15:05:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88D855B4-C5F9-4C84-AA74-0AC2933E5646@nic.cz> References: <201411181937.sAIJbguL080247@idle.juniper.net> <20150102.141424.805742182373718084.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SNp7P-YicCkDWtwv1h5FJbBEdqY Cc: netmod@ietf.org Subject: Re: [netmod] Y07: do not allow when or if-feature on key [Was: YANG 1.1 virtual interim 2014-11-19] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 14:05:26 -0000 > On 02 Jan 2015, at 14:14, Martin Bjorklund wrote: >=20 > Phil Shafer wrote: >> * REVIEW :Y07: do not allow when or if-feature on keys >>=20 >> No objection, though I'm not sure why the exception for >> keys with identical conditions to their parents is worth >> the time/trouble to explain. Forbidding it is simpler. >=20 > I agree. Do we really want to allow: >=20 > list x { > if-feature "not (a or b)"; > key y; > leaf y { > if-feature "(not a) and (not b)"; > ... > } > ... > }=20 >=20 > If we allow such constructs, do we really expect compilers to be able > to detect this? In the case of "if-feature" it is doable, but not for > "when" in general. I don=E2=80=99t see any reason for allowing it. >=20 > Or are we saying that the argument strings must be > character-by-character equal? What about whitespace? >=20 > I agree w/ Phil; we should simply reject "when" and "if-feature" on > keys. Yes, but what do you mean by rejecting? I think for compatibility = reasons =E2=80=9Cwhen=E2=80=9D and =E2=80=9Cif-feature=E2=80=9D = statements should be allowed but ignored on key leafs. Lada >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 2 06:46:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32F21A1B73 for ; Fri, 2 Jan 2015 06:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGNWDQvB_QU0 for ; Fri, 2 Jan 2015 06:46:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 701AA1A1B72 for ; Fri, 2 Jan 2015 06:46:51 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 4A77B1280098; Fri, 2 Jan 2015 15:46:47 +0100 (CET) Date: Fri, 02 Jan 2015 15:46:57 +0100 (CET) Message-Id: <20150102.154657.740500579342842830.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <88D855B4-C5F9-4C84-AA74-0AC2933E5646@nic.cz> References: <201411181937.sAIJbguL080247@idle.juniper.net> <20150102.141424.805742182373718084.mbj@tail-f.com> <88D855B4-C5F9-4C84-AA74-0AC2933E5646@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RBbQt2mClP00p5DPKRvWo5-jLCw Cc: netmod@ietf.org Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 14:46:53 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDIgSmFu IDIwMTUsIGF0IDE0OjE0LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gUGhpbCBTaGFmZXIgPHBoaWxAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+PiAq IFJFVklFVyA6WTA3OiBkbyBub3QgYWxsb3cgd2hlbiBvciBpZi1mZWF0dXJlIG9uIGtleXMNCj4g Pj4gDQo+ID4+IE5vIG9iamVjdGlvbiwgdGhvdWdoIEknbSBub3Qgc3VyZSB3aHkgdGhlIGV4Y2Vw dGlvbiBmb3INCj4gPj4ga2V5cyB3aXRoIGlkZW50aWNhbCBjb25kaXRpb25zIHRvIHRoZWlyIHBh cmVudHMgaXMgd29ydGgNCj4gPj4gdGhlIHRpbWUvdHJvdWJsZSB0byBleHBsYWluLiAgRm9yYmlk ZGluZyBpdCBpcyBzaW1wbGVyLg0KPiA+IA0KPiA+IEkgYWdyZWUuICBEbyB3ZSByZWFsbHkgd2Fu dCB0byBhbGxvdzoNCj4gPiANCj4gPiAgbGlzdCB4IHsNCj4gPiAgICBpZi1mZWF0dXJlICJub3Qg KGEgb3IgYikiOw0KPiA+ICAgIGtleSB5Ow0KPiA+ICAgIGxlYWYgeSB7DQo+ID4gICAgICBpZi1m ZWF0dXJlICIobm90IGEpIGFuZCAobm90IGIpIjsNCj4gPiAgICAgIC4uLg0KPiA+ICAgIH0NCj4g PiAgICAuLi4NCj4gPiAgfSANCj4gPiANCj4gPiBJZiB3ZSBhbGxvdyBzdWNoIGNvbnN0cnVjdHMs IGRvIHdlIHJlYWxseSBleHBlY3QgY29tcGlsZXJzIHRvIGJlIGFibGUNCj4gPiB0byBkZXRlY3Qg dGhpcz8gIEluIHRoZSBjYXNlIG9mICJpZi1mZWF0dXJlIiBpdCBpcyBkb2FibGUsIGJ1dCBub3Qg Zm9yDQo+ID4gIndoZW4iIGluIGdlbmVyYWwuDQo+IA0KPiBJIGRvbuKAmXQgc2VlIGFueSByZWFz b24gZm9yIGFsbG93aW5nIGl0Lg0KPiANCj4gPiANCj4gPiBPciBhcmUgd2Ugc2F5aW5nIHRoYXQg dGhlIGFyZ3VtZW50IHN0cmluZ3MgbXVzdCBiZQ0KPiA+IGNoYXJhY3Rlci1ieS1jaGFyYWN0ZXIg ZXF1YWw/ICBXaGF0IGFib3V0IHdoaXRlc3BhY2U/DQo+ID4gDQo+ID4gSSBhZ3JlZSB3LyBQaGls OyB3ZSBzaG91bGQgc2ltcGx5IHJlamVjdCAid2hlbiIgYW5kICJpZi1mZWF0dXJlIiAgb24NCj4g PiBrZXlzLg0KPiANCj4gWWVzLCBidXQgd2hhdCBkbyB5b3UgbWVhbiBieSByZWplY3Rpbmc/IEkg dGhpbmsgZm9yIGNvbXBhdGliaWxpdHkNCj4gcmVhc29ucyDigJx3aGVu4oCdIGFuZCDigJxpZi1m ZWF0dXJl4oCdIHN0YXRlbWVudHMgc2hvdWxkIGJlIGFsbG93ZWQgYnV0DQo+IGlnbm9yZWQgb24g a2V5IGxlYWZzLg0KDQpPaywgaWdub3JlZCBpcyBvayBhcyB3ZWxsLiAgSXQgYWxzbyBtYWtlcyBp dCBlYXNpZXIgdy8gZ3JvdXBpbmdzLg0KDQoNCi9tYXJ0aW4NCg== From nobody Fri Jan 2 06:49:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145011A876E for ; Fri, 2 Jan 2015 06:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLgUbjcJeT4Q for ; Fri, 2 Jan 2015 06:49:25 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74891A876F for ; Fri, 2 Jan 2015 06:49:24 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so15127170lab.20 for ; Fri, 02 Jan 2015 06:49:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6M5Fbxx+ZLFmSBQjisSWcF+k4YPm2NJnnaU/dF+Dcq4=; b=StPGV4wneTiX2IVedOS9jnoeaOIcorinJtT1e1XCoBY/lUrM6NAZ4pO+3AKY6/nksz B8SoshSRx2CVUfxeVVhykluscBo+uJBrWQWjXA8v5HVl2zcel+9FrfBJPAISw0z1fhLz TyHzWfJQ9cmUSCexRwDmqO3ErfG72nnSLzUKov+Z+lkPAaMb6blLN3cLhVgxZQn0V4mK EbLxB0DxxilIZu7C3BGIvK/zwSx1exDb4rHCiYNF9sP9kV4/YlH37U4SACpyprVSTcVE wpenW/3MXxvEsrF3osEruCReFmdaLC2ssCXc3thN1rnNPbeiMsUKIrj4/JMW8YP/xtdX ZXdA== X-Gm-Message-State: ALoCoQm5DzKYAhjghCHdP6VCfSMrENV5qiWNG8VA+EIKqYmJ46+DHGR2MLOP1awJEBePrcUKBe+6 MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr75725260lam.15.1420210163193; Fri, 02 Jan 2015 06:49:23 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 2 Jan 2015 06:49:23 -0800 (PST) In-Reply-To: <20150102.154657.740500579342842830.mbj@tail-f.com> References: <201411181937.sAIJbguL080247@idle.juniper.net> <20150102.141424.805742182373718084.mbj@tail-f.com> <88D855B4-C5F9-4C84-AA74-0AC2933E5646@nic.cz> <20150102.154657.740500579342842830.mbj@tail-f.com> Date: Fri, 2 Jan 2015 06:49:23 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/w9GeYwdE__CMrUOlUNoPAyO_kj0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 14:49:27 -0000 Hi, This would make valid YANG 1.0 modules be rejected. I strongly object to this change. Andy On Fri, Jan 2, 2015 at 6:46 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> > On 02 Jan 2015, at 14:14, Martin Bjorklund wrote: >> > >> > Phil Shafer wrote: >> >> * REVIEW :Y07: do not allow when or if-feature on keys >> >> >> >> No objection, though I'm not sure why the exception for >> >> keys with identical conditions to their parents is worth >> >> the time/trouble to explain. Forbidding it is simpler. >> > >> > I agree. Do we really want to allow: >> > >> > list x { >> > if-feature "not (a or b)"; >> > key y; >> > leaf y { >> > if-feature "(not a) and (not b)"; >> > ... >> > } >> > ... >> > } >> > >> > If we allow such constructs, do we really expect compilers to be able >> > to detect this? In the case of "if-feature" it is doable, but not for >> > "when" in general. >> >> I don=E2=80=99t see any reason for allowing it. >> >> > >> > Or are we saying that the argument strings must be >> > character-by-character equal? What about whitespace? >> > >> > I agree w/ Phil; we should simply reject "when" and "if-feature" on >> > keys. >> >> Yes, but what do you mean by rejecting? I think for compatibility >> reasons =E2=80=9Cwhen=E2=80=9D and =E2=80=9Cif-feature=E2=80=9D statemen= ts should be allowed but >> ignored on key leafs. > > Ok, ignored is ok as well. It also makes it easier w/ groupings. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 2 06:52:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499BC1A877A for ; Fri, 2 Jan 2015 06:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhgPAXrT8VCn for ; Fri, 2 Jan 2015 06:52:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4291A877D for ; Fri, 2 Jan 2015 06:52:37 -0800 (PST) Received: from [195.113.220.113] (unknown [195.113.220.113]) by mail.nic.cz (Postfix) with ESMTPSA id 5199A1400C3; Fri, 2 Jan 2015 15:52:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420210356; bh=0st5sJ2V2nIKHpPe4qAZ5Id65gBS2KkHGuiuQfoV0WE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ar0OgG/Zv1ZgevnhK0VFf3A/r7DFrTzS6tRrLApTO8R+cuqKNbJGbmH+36nbdsxWo q0QwsARMkzhtc08lUOmPsTvog2fwwNIeN4ILGdZf9FwCRN3KAvOeBp8US8sVMydCtD Pug2BokKFY2vQFxNvBL3HaoUsHp5Eo0NlagXTTRI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 2 Jan 2015 15:52:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76123ABE-5BB5-4358-8F12-84B81DB2C2F3@nic.cz> References: <201411181937.sAIJbguL080247@idle.juniper.net> <20150102.141424.805742182373718084.mbj@tail-f.com> <88D855B4-C5F9-4C84-AA74-0AC2933E5646@nic.cz> <20150102.154657.740500579342842830.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/enQLE5pJQwM1m2gko-B1w-tVqxg Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 14:52:39 -0000 > On 02 Jan 2015, at 15:49, Andy Bierman wrote: >=20 > Hi, >=20 > This would make valid YANG 1.0 modules be rejected. > I strongly object to this change. No 1.0 module will be rejected if the statements are just ignored. It = does mean a change in module semantics but then I guess this qualifies = as a bug fix. Lada >=20 >=20 > Andy >=20 >=20 > On Fri, Jan 2, 2015 at 6:46 AM, Martin Bjorklund = wrote: >> Ladislav Lhotka wrote: >>>=20 >>>> On 02 Jan 2015, at 14:14, Martin Bjorklund wrote: >>>>=20 >>>> Phil Shafer wrote: >>>>> * REVIEW :Y07: do not allow when or if-feature on keys >>>>>=20 >>>>> No objection, though I'm not sure why the exception for >>>>> keys with identical conditions to their parents is worth >>>>> the time/trouble to explain. Forbidding it is simpler. >>>>=20 >>>> I agree. Do we really want to allow: >>>>=20 >>>> list x { >>>> if-feature "not (a or b)"; >>>> key y; >>>> leaf y { >>>> if-feature "(not a) and (not b)"; >>>> ... >>>> } >>>> ... >>>> } >>>>=20 >>>> If we allow such constructs, do we really expect compilers to be = able >>>> to detect this? In the case of "if-feature" it is doable, but not = for >>>> "when" in general. >>>=20 >>> I don=E2=80=99t see any reason for allowing it. >>>=20 >>>>=20 >>>> Or are we saying that the argument strings must be >>>> character-by-character equal? What about whitespace? >>>>=20 >>>> I agree w/ Phil; we should simply reject "when" and "if-feature" = on >>>> keys. >>>=20 >>> Yes, but what do you mean by rejecting? I think for compatibility >>> reasons =E2=80=9Cwhen=E2=80=9D and =E2=80=9Cif-feature=E2=80=9D = statements should be allowed but >>> ignored on key leafs. >>=20 >> Ok, ignored is ok as well. It also makes it easier w/ groupings. >>=20 >>=20 >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 2 08:24:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8320B1A1B81 for ; Fri, 2 Jan 2015 08:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5fV0A4ElhCd for ; Fri, 2 Jan 2015 08:24:29 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437741A1B89 for ; Fri, 2 Jan 2015 08:24:28 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so15853208lab.18 for ; Fri, 02 Jan 2015 08:24:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O3HHQS2RLpT/85Wu5U7Qho+RXP67KsI8+FuN763bHHw=; b=ZpgZPRAOi3GM713XREQKu+ukujvlWndNBz2Pyv4LUtpTNfVX2julNNUGNptz+3CvGG z3V1bP6PP0TP8kWO6jqXtwBntYlJNY7o0u2SHoZeg7oBaHANSRk5zaETK/qkYxYJiHu/ IOTCbajBi30wkCEd46Egmqi7uKaAvSfiNW76knyWtU7pz5CVD0a4diXQRd9Law+rHwq1 z/o0jpEzX2ZxHieoWTDimbG9itvzqtzbP9YRW6xgLCSjy95POYyNaE6Ovso//sla0YM4 xnNa29O5xtX5Kw+oCwQPsAdlp+3ABZszLkUAe6OiLjFDRXsPGLMGOzEb6irxVYCWKWW6 kOXQ== X-Gm-Message-State: ALoCoQnoMUJUVgO8fcwGpkV3V90PegrR9PsQRP/lP1v36uZKHgDCbcxo0CWuDwICTQZ2uqyLKeac MIME-Version: 1.0 X-Received: by 10.152.27.130 with SMTP id t2mr75435952lag.28.1420215866488; Fri, 02 Jan 2015 08:24:26 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 2 Jan 2015 08:24:26 -0800 (PST) In-Reply-To: <76123ABE-5BB5-4358-8F12-84B81DB2C2F3@nic.cz> References: <201411181937.sAIJbguL080247@idle.juniper.net> <20150102.141424.805742182373718084.mbj@tail-f.com> <88D855B4-C5F9-4C84-AA74-0AC2933E5646@nic.cz> <20150102.154657.740500579342842830.mbj@tail-f.com> <76123ABE-5BB5-4358-8F12-84B81DB2C2F3@nic.cz> Date: Fri, 2 Jan 2015 08:24:26 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GDR4ep5KNV5n6XCQC4g-mM2wPXU Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 16:24:31 -0000 On Fri, Jan 2, 2015 at 6:52 AM, Ladislav Lhotka wrote: > >> On 02 Jan 2015, at 15:49, Andy Bierman wrote: >> >> Hi, >> >> This would make valid YANG 1.0 modules be rejected. >> I strongly object to this change. > > No 1.0 module will be rejected if the statements are just ignored. It doe= s mean a change in module semantics but then I guess this qualifies as a bu= g fix. > IMO it is a really bad idea to allow tools to ignore any statements in the base language. This is only OK for external statements defined with extensions. It is really confusing to the writer and reader as well. I agree that it is not feasible for a tool to compare XPath statements with different context nodes to see if they always produce the same results. But it is easy to check if the feature-stmts are the same or less than the parent. When-stmt can be inherited from uses and augment. Not sure if keys can be augmented into a list, but uses can certainly pull in the keys. Is module X valid: module X { augment /my-list { leaf key1 { type string; } } list my-list { key "key1"; leaf column1 { type string; } } } I know module Y is valid: module Y { grouping key1 { leaf key1 { type string; } } list my-list { key "key1"; uses key1; leaf column1 { type string; } } } Note that a when-stmt could appear in the uses-stmt or augment-stmts making the key leaf conditional. Also, if-feature-stmts could be present as well. I might be in favor of making key leafs that are conditional due to when-st= mt invalid and rejected with a compiler error. It's not OK to ignore this condition. > Lada > >> >> >> Andy >> Andy >> >> On Fri, Jan 2, 2015 at 6:46 AM, Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>> >>>>> On 02 Jan 2015, at 14:14, Martin Bjorklund wrote: >>>>> >>>>> Phil Shafer wrote: >>>>>> * REVIEW :Y07: do not allow when or if-feature on keys >>>>>> >>>>>> No objection, though I'm not sure why the exception for >>>>>> keys with identical conditions to their parents is worth >>>>>> the time/trouble to explain. Forbidding it is simpler. >>>>> >>>>> I agree. Do we really want to allow: >>>>> >>>>> list x { >>>>> if-feature "not (a or b)"; >>>>> key y; >>>>> leaf y { >>>>> if-feature "(not a) and (not b)"; >>>>> ... >>>>> } >>>>> ... >>>>> } >>>>> >>>>> If we allow such constructs, do we really expect compilers to be able >>>>> to detect this? In the case of "if-feature" it is doable, but not fo= r >>>>> "when" in general. >>>> >>>> I don=E2=80=99t see any reason for allowing it. >>>> >>>>> >>>>> Or are we saying that the argument strings must be >>>>> character-by-character equal? What about whitespace? >>>>> >>>>> I agree w/ Phil; we should simply reject "when" and "if-feature" on >>>>> keys. >>>> >>>> Yes, but what do you mean by rejecting? I think for compatibility >>>> reasons =E2=80=9Cwhen=E2=80=9D and =E2=80=9Cif-feature=E2=80=9D statem= ents should be allowed but >>>> ignored on key leafs. >>> >>> Ok, ignored is ok as well. It also makes it easier w/ groupings. >>> >>> >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jan 2 08:39:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7C1A1B76 for ; Fri, 2 Jan 2015 08:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw8XMrLMmbws for ; Fri, 2 Jan 2015 08:39:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 03AD61A1B53 for ; Fri, 2 Jan 2015 08:39:11 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id D814B1280098; Fri, 2 Jan 2015 17:39:09 +0100 (CET) Date: Fri, 02 Jan 2015 17:39:21 +0100 (CET) Message-Id: <20150102.173921.2068884682648761059.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <76123ABE-5BB5-4358-8F12-84B81DB2C2F3@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oLtxNSKhrhZiUQbglH41TYcES08 Cc: netmod@ietf.org Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 16:39:12 -0000 Andy Bierman wrote: > On Fri, Jan 2, 2015 at 6:52 AM, Ladislav Lhotka wrote: > > > >> On 02 Jan 2015, at 15:49, Andy Bierman wrote: > >> > >> Hi, > >> > >> This would make valid YANG 1.0 modules be rejected. > >> I strongly object to this change. > > > > No 1.0 module will be rejected if the statements are just ignored. It does mean a change in module semantics but then I guess this qualifies as a bug fix. > > > > > IMO it is a really bad idea to allow tools to ignore any statements > in the base language. This is only OK for external statements > defined with extensions. We already do this in a couple of instances; e.g. config statement in rpc/notification, and default in a key leaf. > It is really confusing to the writer and reader as well. > > I agree that it is not feasible for a tool to compare XPath statements > with different context nodes to see if they always produce the > same results. But it is easy to check if the feature-stmts are the same > or less than the parent. > > When-stmt can be inherited from uses and augment. > Not sure if keys can be augmented into a list, but uses can > certainly pull in the keys. [...] > Note that a when-stmt could appear in the uses-stmt or augment-stmts > making the key leaf conditional. Also, if-feature-stmts could be present > as well. > > I might be in favor of making key leafs that are conditional due to when-stmt > invalid and rejected with a compiler error. It's not OK to ignore this > condition. Consider this situation: grouping x { leaf a { if-feature "bar"; type string; } } list y { key "a b"; uses x; leaf b { type string; } } Now, if the server doesn't advertise "bar", what does this mean? YANG 1.0 doesn't say. We can make it illegal in 1.1, or we can say that the if-feature/when statements are ignored. If we make it illegal, it means that there is no way list y can use the grouping x. I think Lada's suggestion was to ignore if-feature/when b/c of backwards compatibility reasons. This would be legal in 1.1, if we say that we ignore the if-feature: list y { if-feature "bar"; key "a b"; uses x; leaf b { type string; } } /martin From nobody Fri Jan 2 09:02:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B139D1A1B87 for ; Fri, 2 Jan 2015 09:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW3pXBgfxW6W for ; Fri, 2 Jan 2015 09:02:43 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D0E1A1B81 for ; Fri, 2 Jan 2015 09:02:42 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so14631945lbj.8 for ; Fri, 02 Jan 2015 09:02:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zoYjzSJL+KVV+CSVc3AY+lOjTHED3ftk9qRPczmZbk4=; b=OuArW5T+GlXwnOz2Ku6zkn+9WxCS6sx7WvKQM/QEF5gaYzT7HDIr48CTcOc1L06Y2O F+WrMPRnUtAnALNcYACGMsu+WXUkU/+F3jlaluR1bvcPjTLV6vs0HA2vFwMmDJb4R+Gk C3HtKZdge2WxSwk2NW3Xe+5ZuowtZfAkG+94ZZ6TssTJnIBEgZD5Nsi9iSpiDoyDAxMK YaGKkmR1xkGue8fj9sMofBMebzc9S5ttwR0L17ICi5QfM+/xI4OQOcOTdwH0m2SI+2Aj yQI04J+UHgGaVaoH66uM6Q/IIEYH5UCGQg8UwmAILjQX69XMFe63JbkfbohOE74G2MOd SDlA== X-Gm-Message-State: ALoCoQmYaRWhC65dnKWCx5JI7zTxTM/rJZ/LhCEl4c7MwgipfaGz/wKM2eKE6mrUpaGi93tDxUAp MIME-Version: 1.0 X-Received: by 10.112.156.132 with SMTP id we4mr52775963lbb.59.1420218161314; Fri, 02 Jan 2015 09:02:41 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 2 Jan 2015 09:02:41 -0800 (PST) In-Reply-To: <20150102.173921.2068884682648761059.mbj@tail-f.com> References: <76123ABE-5BB5-4358-8F12-84B81DB2C2F3@nic.cz> <20150102.173921.2068884682648761059.mbj@tail-f.com> Date: Fri, 2 Jan 2015 09:02:41 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FYavMIeD1v4BFq68TYwbd6ituRw Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 17:02:44 -0000 On Fri, Jan 2, 2015 at 8:39 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Fri, Jan 2, 2015 at 6:52 AM, Ladislav Lhotka wrote: >> > >> >> On 02 Jan 2015, at 15:49, Andy Bierman wrote: >> >> >> >> Hi, >> >> >> >> This would make valid YANG 1.0 modules be rejected. >> >> I strongly object to this change. >> > >> > No 1.0 module will be rejected if the statements are just ignored. It does mean a change in module semantics but then I guess this qualifies as a bug fix. >> > >> >> >> IMO it is a really bad idea to allow tools to ignore any statements >> in the base language. This is only OK for external statements >> defined with extensions. > > We already do this in a couple of instances; e.g. config statement in > rpc/notification, and default in a key leaf. > And now we will change the rules in YANG 1.1 so default-stmt is not ignored in a leaf? How is that backward-compatible? >> It is really confusing to the writer and reader as well. >> >> I agree that it is not feasible for a tool to compare XPath statements >> with different context nodes to see if they always produce the >> same results. But it is easy to check if the feature-stmts are the same >> or less than the parent. >> >> When-stmt can be inherited from uses and augment. >> Not sure if keys can be augmented into a list, but uses can >> certainly pull in the keys. > > [...] > >> Note that a when-stmt could appear in the uses-stmt or augment-stmts >> making the key leaf conditional. Also, if-feature-stmts could be present >> as well. >> >> I might be in favor of making key leafs that are conditional due to when-stmt >> invalid and rejected with a compiler error. It's not OK to ignore this >> condition. > > Consider this situation: > > grouping x { > leaf a { > if-feature "bar"; > type string; > } > } > > list y { > key "a b"; > uses x; > leaf b { > type string; > } > } > > Now, if the server doesn't advertise "bar", what does this mean? > As I said before, it is an error for the leaf to have if-feature-stmts that are not also in the parent node. Our compiler would flag leaf "a" as an error. If an "if-feature bar;" stmt appeared in the parent list y, then this is not an error at all. > YANG 1.0 doesn't say. > > We can make it illegal in 1.1, or we can say that the if-feature/when > statements are ignored. > > If we make it illegal, it means that there is no way list y can use > the grouping x. > sure it can -- add "if-feature bar;" > I think Lada's suggestion was to ignore if-feature/when b/c of > backwards compatibility reasons. > > This would be legal in 1.1, if we say that we ignore the if-feature: > > list y { > if-feature "bar"; > key "a b"; > uses x; > leaf b { > type string; > } > } > > This is legal now -- our tools support it and check for key leafs that are more conditional than their parent. The statements are validated > /martin Andy From nobody Sun Jan 4 02:09:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187E41A7033 for ; Sun, 4 Jan 2015 02:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drw_WoV9rJd7 for ; Sun, 4 Jan 2015 02:09:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 577811A7028 for ; Sun, 4 Jan 2015 02:09:20 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id B76571280056; Sun, 4 Jan 2015 11:09:16 +0100 (CET) Date: Sun, 04 Jan 2015 11:09:16 +0100 (CET) Message-Id: <20150104.110916.325563256712417030.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150102.173921.2068884682648761059.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/O30798Of9VYmdAFU6uxoeqEs_DA Cc: netmod@ietf.org Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 10:09:22 -0000 Andy Bierman wrote: > On Fri, Jan 2, 2015 at 8:39 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: [...] > >> I agree that it is not feasible for a tool to compare XPath statements > >> with different context nodes to see if they always produce the > >> same results. But it is easy to check if the feature-stmts are the same > >> or less than the parent. This is exactly the problem that I tried to describe orginally in this email thread. The current approach to Y07 is to say that it is ok to have if-feature/when on key leafs, as long as they are the same as the parent list node. This sounds simple, but my point is - and it seems you agree - that it is not simple. For boolean expressions in if-feature it is doable, but for XPath expressions in when it is not. So how do we solve this? First of all, this is mostly an issue w/ using leafs defined in a groping as a key in a list. If the key leaf is defined "inline", it is not necessary to allow if-feature/when on the key leaf (*). 1. Require the expression to be *exactly* the same string, including whitespaces. There are some corner cases where some groupings cannot be used in this case (**). 2. Require the expression to be logically the same - but this is difficult and will probably lead to tools not checking this. (Or rather, the expression on the list can be more restrictive than the expression on the key; even more difficult to check.) 3. Ignore the if-feature/when on the key leaf. This is possibly confusing. 4. Make if-feature/when on the key leaf illegal. This means that certain groupings cannot be used. 5. Have different rules for if-feature and when. (*) one interesting case is Y07 combined with Y09, for example: list address { key "ip vrf"; leaf ip { ... } leaf vrf { if-feature vrf; mandatory false; ... } ... } (**) grouping a { leaf a { when "/properties/a": ... } } grouping b { leaf b { when "/properties/b": ... } } list x { when "/properties/a and /properties/b"; key "a b"; uses a; uses b; } > > I think Lada's suggestion was to ignore if-feature/when b/c of > > backwards compatibility reasons. > > > > This would be legal in 1.1, if we say that we ignore the if-feature: > > > > list y { > > if-feature "bar"; > > key "a b"; > > uses x; > > leaf b { > > type string; > > } > > } > > > > > > This is legal now -- our tools support it and check for key leafs > that are more conditional than their parent. But this behavior isn't specified in RFC 6020 - and this is the problem that we want to solve. /martin From nobody Sun Jan 4 03:53:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6F41A879B for ; Sun, 4 Jan 2015 03:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGVEFS78bGo0 for ; Sun, 4 Jan 2015 03:53:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABCD1A8710 for ; Sun, 4 Jan 2015 03:53:16 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:194e:bfc7:73a6:5ef] (unknown [IPv6:2a01:5e0:29:ffff:194e:bfc7:73a6:5ef]) by mail.nic.cz (Postfix) with ESMTPSA id 9D22113F7AF; Sun, 4 Jan 2015 12:53:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420372394; bh=X1MZA/AY0ccL14O4+Z/K6+BEBDke7BWUaIEYxPMTzqA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KCNlqf1dI0l/3VyovG0hKPVZ4KYmaihJd6+VMQAL7wSLmS9bniHpbhvaXs0AgpGKM yfOyyLmoakbWbaxhXFg8kupJ9fhM8yPq6DTF2Zmr9VjA0QDcTue9aYza85S9TA37RJ wUjLdUSmEUKsI7dSb+5IcxIxzwPXURdH7vrUNji4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150104.110916.325563256712417030.mbj@tail-f.com> Date: Sun, 4 Jan 2015 12:53:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70150F84-5C10-42D8-BF78-76E0A3CF0F6C@nic.cz> References: <20150102.173921.2068884682648761059.mbj@tail-f.com> <20150104.110916.325563256712417030.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qrxWRFcZiT2vluZTA7JTbmtDk70 Cc: netmod@ietf.org Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 11:53:18 -0000 > On 04 Jan 2015, at 11:09, Martin Bjorklund wrote: >=20 > Andy Bierman wrote: >> On Fri, Jan 2, 2015 at 8:39 AM, Martin Bjorklund = wrote: >>> Andy Bierman wrote: >=20 > [...] >=20 >>>> I agree that it is not feasible for a tool to compare XPath = statements >>>> with different context nodes to see if they always produce the >>>> same results. But it is easy to check if the feature-stmts are the = same >>>> or less than the parent. >=20 > This is exactly the problem that I tried to describe orginally in this > email thread. >=20 > The current approach to Y07 is to say that it is ok to have > if-feature/when on key leafs, as long as they are the same as the > parent list node. This sounds simple, but my point is - and it seems > you agree - that it is not simple. For boolean expressions in > if-feature it is doable, but for XPath expressions in when it is not. >=20 > So how do we solve this? >=20 > First of all, this is mostly an issue w/ using leafs defined in a > groping as a key in a list. If the key leaf is defined "inline", it > is not necessary to allow if-feature/when on the key leaf (*). >=20 > 1. Require the expression to be *exactly* the same string, including > whitespaces. This could possibly work only for a small subset of XPath expressions = because of different context nodes. Also, it would be extremely brittle. >=20 > There are some corner cases where some groupings cannot be used in > this case (**). >=20 > 2. Require the expression to be logically the same - but this is > difficult and will probably lead to tools not checking this. Yes. >=20 > (Or rather, the expression on the list can be more restrictive > than the expression on the key; even more difficult to check.) >=20 > 3. Ignore the if-feature/when on the key leaf. This is possibly > confusing. A =E2=80=9Cdefault=E2=80=9D statement on a key is also ignored. >=20 > 4. Make if-feature/when on the key leaf illegal. This means that > certain groupings cannot be used. =E2=80=A6 and makes some 1.0 modules illegal. >=20 > 5. Have different rules for if-feature and when. This is IMO too complicated given that such cases should be quite rare. >=20 >=20 > (*) one interesting case is Y07 combined with Y09, for example: >=20 > list address { > key "ip vrf"; > leaf ip { ... } > leaf vrf { > if-feature vrf; > mandatory false; > ... > } > ... > } This actually makes a good sense and should be allowed if Y09 makes it = into 1.1. Lada >=20 > (**) >=20 > grouping a { > leaf a { > when "/properties/a": > ... > } > } >=20 > grouping b { > leaf b { > when "/properties/b": > ... > } > } >=20 > list x { > when "/properties/a and /properties/b"; > key "a b"; > uses a; > uses b; > } >=20 >=20 >>> I think Lada's suggestion was to ignore if-feature/when b/c of >>> backwards compatibility reasons. >>>=20 >>> This would be legal in 1.1, if we say that we ignore the if-feature: >>>=20 >>> list y { >>> if-feature "bar"; >>> key "a b"; >>> uses x; >>> leaf b { >>> type string; >>> } >>> } >>>=20 >>>=20 >>=20 >> This is legal now -- our tools support it and check for key leafs >> that are more conditional than their parent. >=20 > But this behavior isn't specified in RFC 6020 - and this is the > problem that we want to solve. >=20 >=20 > /martin >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Jan 4 09:00:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430571A87BC for ; Sun, 4 Jan 2015 09:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pq_lI3bb2Yh for ; Sun, 4 Jan 2015 09:00:14 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A471A8951 for ; Sun, 4 Jan 2015 09:00:12 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z12so8958863lbi.3 for ; Sun, 04 Jan 2015 09:00:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cPjAkKfoJCL3ajgV8ua+gh6NrHvdbyQ/NHZoXrji+SM=; b=T5PHGH+6SXtWaeSqtp/0n25uIaBTNe54Wo5eq1PWfG/FcDW0ieDDP8ns7bMxfPy7/D qDsM4H29s4UkJCoq6ZYkOx8tjcRNqlU+JmTkXQ21sVm9Wp0ls/q96WFlHwxDWFMhMUQz 3ZLFgbEoW1Uu2FbL1xe7tsEpP+dV2NVeVzpjjPrfh548iM0FF6ex9t7k+Q3Z7RATcdYf /2WzGK51DGenhF8Fc/1sToJcCnHnQhC8iUEEURo0d/r5sp0yc5zjpNvYTGL6rk3JhD9W uyf3mCibzEfB3BXI5lt/Ztpb8YpBCEoRdXSJla0utv549MTsIZidk51RBNRfSThHeF5B sCsw== X-Gm-Message-State: ALoCoQkGSmhMSAHEbmuw5bvSLQc3J2sD7WPtZ20qHQ60cMEMatkOtSNhjero+h7pwMZIiQwas6v4 MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr86538635lam.15.1420390810381; Sun, 04 Jan 2015 09:00:10 -0800 (PST) Received: by 10.112.77.231 with HTTP; Sun, 4 Jan 2015 09:00:10 -0800 (PST) In-Reply-To: <70150F84-5C10-42D8-BF78-76E0A3CF0F6C@nic.cz> References: <20150102.173921.2068884682648761059.mbj@tail-f.com> <20150104.110916.325563256712417030.mbj@tail-f.com> <70150F84-5C10-42D8-BF78-76E0A3CF0F6C@nic.cz> Date: Sun, 4 Jan 2015 09:00:10 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EeX9uw_cz2O_xX6YXZGKFdGIl_Q Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 17:00:17 -0000 On Sun, Jan 4, 2015 at 3:53 AM, Ladislav Lhotka wrote: > >> On 04 Jan 2015, at 11:09, Martin Bjorklund wrote: >> >> Andy Bierman wrote: >>> On Fri, Jan 2, 2015 at 8:39 AM, Martin Bjorklund wrote= : >>>> Andy Bierman wrote: >> >> [...] >> >>>>> I agree that it is not feasible for a tool to compare XPath statement= s >>>>> with different context nodes to see if they always produce the >>>>> same results. But it is easy to check if the feature-stmts are the s= ame >>>>> or less than the parent. >> >> This is exactly the problem that I tried to describe orginally in this >> email thread. >> >> The current approach to Y07 is to say that it is ok to have >> if-feature/when on key leafs, as long as they are the same as the >> parent list node. This sounds simple, but my point is - and it seems >> you agree - that it is not simple. For boolean expressions in >> if-feature it is doable, but for XPath expressions in when it is not. >> >> So how do we solve this? >> >> First of all, this is mostly an issue w/ using leafs defined in a >> groping as a key in a list. If the key leaf is defined "inline", it >> is not necessary to allow if-feature/when on the key leaf (*). >> >> 1. Require the expression to be *exactly* the same string, including >> whitespaces. > > This could possibly work only for a small subset of XPath expressions bec= ause of different context nodes. Also, it would be extremely brittle. > This is not very robust. It only works if the context node has no affect on the expression, which is a corner-case, and not the way XPath is really used. (So this solution is out) >> >> There are some corner cases where some groupings cannot be used in >> this case (**). >> >> 2. Require the expression to be logically the same - but this is >> difficult and will probably lead to tools not checking this. > > Yes. > This is too hard to implement (except if the context node is irrelevant -- see previous point). >> >> (Or rather, the expression on the list can be more restrictive >> than the expression on the key; even more difficult to check.) >> >> 3. Ignore the if-feature/when on the key leaf. This is possibly >> confusing. > > A =E2=80=9Cdefault=E2=80=9D statement on a key is also ignored. > >> >> 4. Make if-feature/when on the key leaf illegal. This means that >> certain groupings cannot be used. > > =E2=80=A6 and makes some 1.0 modules illegal. > which modules? if-feature is not a problem at all. The solution is clear and simple to implement for if-feature. Only the whrn-stmt is a problem. So which YANG modules currently have when-stmts on key leafs? >> >> 5. Have different rules for if-feature and when. > > This is IMO too complicated given that such cases should be quite rare. > This is not too complicated. YANG features are static and the values are not dependent on the datastore node values. A key leaf MUST NOT have if-feature-stmts that do not also apply to its parent. IMO we should make any when-stmt that applies to a key-leaf illegal, just to make it clear that conditional keys are not allowed. >> >> >> (*) one interesting case is Y07 combined with Y09, for example: >> >> list address { >> key "ip vrf"; >> leaf ip { ... } >> leaf vrf { >> if-feature vrf; >> mandatory false; >> ... >> } >> ... >> } > > This actually makes a good sense and should be allowed if Y09 makes it in= to 1.1. > IMO optional keys do not work well at all, and they require a base type to be changed, which is unacceptable. Allowing default-stmt on a key leaf does not work because a YANG 1.0 module clearly ignores the default. IMO YANG backward compatibility is easy to define: Axiom 1: Within YANG 1.0 there are statements with clear behavior and som= e behavior that is under-defined. Backward compatibility only applies to t= he behavior that is clearly defined. Axiom 2: There MUST NOT be any changes in clearly defined behavior when a YANG 1.0 module is parsed as if it were a YANG 1.1 module > Lada > Andy >> >> (**) >> >> grouping a { >> leaf a { >> when "/properties/a": >> ... >> } >> } >> >> grouping b { >> leaf b { >> when "/properties/b": >> ... >> } >> } >> >> list x { >> when "/properties/a and /properties/b"; >> key "a b"; >> uses a; >> uses b; >> } >> >> >>>> I think Lada's suggestion was to ignore if-feature/when b/c of >>>> backwards compatibility reasons. >>>> >>>> This would be legal in 1.1, if we say that we ignore the if-feature: >>>> >>>> list y { >>>> if-feature "bar"; >>>> key "a b"; >>>> uses x; >>>> leaf b { >>>> type string; >>>> } >>>> } >>>> >>>> >>> >>> This is legal now -- our tools support it and check for key leafs >>> that are more conditional than their parent. >> >> But this behavior isn't specified in RFC 6020 - and this is the >> problem that we want to solve. >> >> >> /martin >> >> >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Sun Jan 4 11:50:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAE81A8AE6 for ; Sun, 4 Jan 2015 11:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWLFfnqOR_uB for ; Sun, 4 Jan 2015 11:50:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932531A8AC2 for ; Sun, 4 Jan 2015 11:50:55 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:b908:4c5d:2993:e655] (unknown [IPv6:2a01:5e0:29:ffff:b908:4c5d:2993:e655]) by mail.nic.cz (Postfix) with ESMTPSA id 152EF13F634; Sun, 4 Jan 2015 20:50:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420401053; bh=lqdhbnsixkvM4F+iV5tjGlBAkjkXf7ux6zXeq/YNcy0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qwOgYHhBbyQVWczSnKYJn7xN/AfMXo5c4d6xZ5fL+2e1YadU3KUKb4X174c47K09k gCoQObA84F5hWYTyZydrfB/3WwprSHqmaNxs1i2GGbQhB2TK3eNc/n1WBcNvJztvas zGl7izRIcdO/2pxJ3AIeaZOS8AXCup2BL2rH0+C8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Sun, 4 Jan 2015 20:50:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150102.173921.2068884682648761059.mbj@tail-f.com> <20150104.110916.325563256712417030.mbj@tail-f.com> <70150F84-5C10-42D8-BF78-76E0A3CF0F6C@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wSKsxGruwKohzhTTCZoAcBlUuJU Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:50:58 -0000 > On 04 Jan 2015, at 18:00, Andy Bierman wrote: >=20 ... >>=20 >>>=20 >>> 4. Make if-feature/when on the key leaf illegal. This means that >>> certain groupings cannot be used. >>=20 >> =E2=80=A6 and makes some 1.0 modules illegal. >>=20 >=20 > which modules? Those that have if-feature or when on a list key - as Martin wrote, this = is not forbidden by RFC 6020. >=20 > if-feature is not a problem at all. > The solution is clear and simple to implement for if-feature. > Only the whrn-stmt is a problem. So which YANG modules > currently have when-stmts on key leafs? >=20 >=20 >>>=20 >>> 5. Have different rules for if-feature and when. >>=20 >> This is IMO too complicated given that such cases should be quite = rare. >>=20 >=20 > This is not too complicated. > YANG features are static and the values are not dependent on > the datastore node values. A key leaf MUST NOT have > if-feature-stmts that do not also apply to its parent. >=20 > IMO we should make any when-stmt that applies to a key-leaf illegal, > just to make it clear that conditional keys are not allowed. This would still violate the first charter requirement (all compliant = 1.0 modules must remain compliant). >=20 >=20 >>>=20 >>>=20 >>> (*) one interesting case is Y07 combined with Y09, for example: >>>=20 >>> list address { >>> key "ip vrf"; >>> leaf ip { ... } >>> leaf vrf { >>> if-feature vrf; >>> mandatory false; >>> ... >>> } >>> ... >>> } >>=20 >> This actually makes a good sense and should be allowed if Y09 makes = it into 1.1. >>=20 >=20 > IMO optional keys do not work well at all, and they require a base = type to > be changed, which is unacceptable. >=20 > Allowing default-stmt on a key leaf does not work because a YANG 1.0 = module > clearly ignores the default. >=20 > IMO YANG backward compatibility is easy to define: >=20 > Axiom 1: Within YANG 1.0 there are statements with clear behavior and = some > behavior that is under-defined. Backward compatibility only applies = to the > behavior that is clearly defined. >=20 > Axiom 2: There MUST NOT be any changes in clearly defined behavior > when a YANG 1.0 module is parsed as if it were a YANG 1.1 module The charter says something else. Above the charter text, I think it is = also reasonable to avoid changes in the semantics of existing statements = unless it is a bug fix. But this case clearly qualifies as a bug fix. Lada >=20 >=20 >> Lada >>=20 >=20 >=20 > Andy >=20 >>>=20 >>> (**) >>>=20 >>> grouping a { >>> leaf a { >>> when "/properties/a": >>> ... >>> } >>> } >>>=20 >>> grouping b { >>> leaf b { >>> when "/properties/b": >>> ... >>> } >>> } >>>=20 >>> list x { >>> when "/properties/a and /properties/b"; >>> key "a b"; >>> uses a; >>> uses b; >>> } >>>=20 >>>=20 >>>>> I think Lada's suggestion was to ignore if-feature/when b/c of >>>>> backwards compatibility reasons. >>>>>=20 >>>>> This would be legal in 1.1, if we say that we ignore the = if-feature: >>>>>=20 >>>>> list y { >>>>> if-feature "bar"; >>>>> key "a b"; >>>>> uses x; >>>>> leaf b { >>>>> type string; >>>>> } >>>>> } >>>>>=20 >>>>>=20 >>>>=20 >>>> This is legal now -- our tools support it and check for key leafs >>>> that are more conditional than their parent. >>>=20 >>> But this behavior isn't specified in RFC 6020 - and this is the >>> problem that we want to solve. >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Jan 4 12:20:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B641A8FD6 for ; Sun, 4 Jan 2015 12:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fuum4ihMmMl8 for ; Sun, 4 Jan 2015 12:20:21 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587B21A8F49 for ; Sun, 4 Jan 2015 12:20:19 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id z11so8798656lbi.6 for ; Sun, 04 Jan 2015 12:20:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qRIV+jkEdkNA2a9XrflHJkq74zAO585ybCts3RgDg1w=; b=Tolrw+lSEkdyPyG/CSsaIVksOh9f/BYSwECCS7Gy685x5rSOk4sghbgQFRPeQEKLV7 avEiufUosANYR+dcwB7cd45tDsBbI8RsmVh4Z35hpHZ1+hHq4ISpLaE4QsS/rT79RHuN 7YSdvjINiM8xAKYgvIDdV45e0zkZqYSjtK0AErx2XbPGNeZGqlGOynhlLzbRVNJg9rM3 dUY08/ZZaOaBgZeRaF+AVauVbdsZ5Xn05GXdxKzaIRFUF+R/WK8+ph3taszonBsdwRKO zkdik34mVGWndtLcIM/snRMbN78Wc2K55h+H8AxhRdOJ6fxHIE3ggqKIFGXAWWTOGRNC 86QQ== X-Gm-Message-State: ALoCoQnDpDGZDzE1U+M5AlnmpfTQWElmtRMcBvlVegGFTZasuYlmvnUaDUZDcY8bd9yRoWJ0Xqn6 MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr64766454lbv.21.1420402817838; Sun, 04 Jan 2015 12:20:17 -0800 (PST) Received: by 10.112.77.231 with HTTP; Sun, 4 Jan 2015 12:20:17 -0800 (PST) In-Reply-To: References: <20150102.173921.2068884682648761059.mbj@tail-f.com> <20150104.110916.325563256712417030.mbj@tail-f.com> <70150F84-5C10-42D8-BF78-76E0A3CF0F6C@nic.cz> Date: Sun, 4 Jan 2015 12:20:17 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Rw-VszvoL106Qnt1fU5zzM0lVuw Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 20:20:23 -0000 On Sun, Jan 4, 2015 at 11:50 AM, Ladislav Lhotka wrote: > >> On 04 Jan 2015, at 18:00, Andy Bierman wrote: >> > > ... > >>> >>>> >>>> 4. Make if-feature/when on the key leaf illegal. This means that >>>> certain groupings cannot be used. >>> >>> =E2=80=A6 and makes some 1.0 modules illegal. >>> >> >> which modules? > > Those that have if-feature or when on a list key - as Martin wrote, this = is not forbidden by RFC 6020. > So none. There are no modules that have key leafs that have if-feature-stmts that are not in the parent. There is nothing in YANG 1.0 that even suggests that a key leaf is allowed to be absent in a list. The mechanics of the if-feature-stmt and when-stmt may inadvertently allow it, but it is disallowed in other text so this overrides it. >> >> if-feature is not a problem at all. >> The solution is clear and simple to implement for if-feature. >> Only the whrn-stmt is a problem. So which YANG modules >> currently have when-stmts on key leafs? >> >> >>>> >>>> 5. Have different rules for if-feature and when. >>> >>> This is IMO too complicated given that such cases should be quite rare. >>> >> >> This is not too complicated. >> YANG features are static and the values are not dependent on >> the datastore node values. A key leaf MUST NOT have >> if-feature-stmts that do not also apply to its parent. >> >> IMO we should make any when-stmt that applies to a key-leaf illegal, >> just to make it clear that conditional keys are not allowed. > > This would still violate the first charter requirement (all compliant 1.0= modules must remain compliant). > So then the only solution is to say (even though it is already clear) that key leafs are never optional. It is an error if an edit would require the server to remove a key leaf and not its parent. The server must reject such changes. >> >> >>>> >>>> >>>> (*) one interesting case is Y07 combined with Y09, for example: >>>> >>>> list address { >>>> key "ip vrf"; >>>> leaf ip { ... } >>>> leaf vrf { >>>> if-feature vrf; >>>> mandatory false; >>>> ... >>>> } >>>> ... >>>> } >>> >>> This actually makes a good sense and should be allowed if Y09 makes it = into 1.1. >>> >> >> IMO optional keys do not work well at all, and they require a base type = to >> be changed, which is unacceptable. >> >> Allowing default-stmt on a key leaf does not work because a YANG 1.0 mod= ule >> clearly ignores the default. >> >> IMO YANG backward compatibility is easy to define: >> >> Axiom 1: Within YANG 1.0 there are statements with clear behavior and s= ome >> behavior that is under-defined. Backward compatibility only applies to= the >> behavior that is clearly defined. >> >> Axiom 2: There MUST NOT be any changes in clearly defined behavior >> when a YANG 1.0 module is parsed as if it were a YANG 1.1 module > > The charter says something else. Above the charter text, I think it is al= so reasonable to avoid changes in the semantics of existing statements unle= ss it is a bug fix. But this case clearly qualifies as a bug fix. > We do not agree on the bug or the fix. > Lada > Andy >> >> >>> Lada >>> >> >> >> Andy >> >>>> >>>> (**) >>>> >>>> grouping a { >>>> leaf a { >>>> when "/properties/a": >>>> ... >>>> } >>>> } >>>> >>>> grouping b { >>>> leaf b { >>>> when "/properties/b": >>>> ... >>>> } >>>> } >>>> >>>> list x { >>>> when "/properties/a and /properties/b"; >>>> key "a b"; >>>> uses a; >>>> uses b; >>>> } >>>> >>>> >>>>>> I think Lada's suggestion was to ignore if-feature/when b/c of >>>>>> backwards compatibility reasons. >>>>>> >>>>>> This would be legal in 1.1, if we say that we ignore the if-feature: >>>>>> >>>>>> list y { >>>>>> if-feature "bar"; >>>>>> key "a b"; >>>>>> uses x; >>>>>> leaf b { >>>>>> type string; >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>> >>>>> This is legal now -- our tools support it and check for key leafs >>>>> that are more conditional than their parent. >>>> >>>> But this behavior isn't specified in RFC 6020 - and this is the >>>> problem that we want to solve. >>>> >>>> >>>> /martin >>>> >>>> >>>> >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Mon Jan 5 01:28:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F22A1A1BB7 for ; Mon, 5 Jan 2015 01:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U6wb9C3iStt for ; Mon, 5 Jan 2015 01:28:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660AA1A1F20 for ; Mon, 5 Jan 2015 01:28:46 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 5DF0C13FA5E; Mon, 5 Jan 2015 10:28:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420450124; bh=OkNWAVHR0p4XtJYC47NApRNjZjIit5JVlfhAddX4ObA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BDBFoW9PzymyPpf77z/w1by/4EDheISMnLLM60LglRoUpYfPvrmPaQ+NJN3x1ZaRD 6cd2jK4Tn1bWd0qCGpKFKI2TcoUWnBm70Mrsc67hYNhsUTQqXRLoTVHtucxriVLTcM YL37zI0fNqrIEzna11oTO4IbvwfvooYzGu64gBy4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Jan 2015 10:28:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C23ED6B-9790-4582-AC57-EE75D67041F2@nic.cz> References: <20150102.173921.2068884682648761059.mbj@tail-f.com> <20150104.110916.325563256712417030.mbj@tail-f.com> <70150F84-5C10-42D8-BF78-76E0A3CF0F6C@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zMvc_bPxaziLsdqHXAqN9yCC3gI Cc: "netmod@ietf.org" Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 09:28:48 -0000 > On 04 Jan 2015, at 21:20, Andy Bierman wrote: >=20 > On Sun, Jan 4, 2015 at 11:50 AM, Ladislav Lhotka = wrote: >>=20 >>> On 04 Jan 2015, at 18:00, Andy Bierman wrote: >>>=20 >>=20 >> ... >>=20 >>>>=20 >>>>>=20 >>>>> 4. Make if-feature/when on the key leaf illegal. This means that >>>>> certain groupings cannot be used. >>>>=20 >>>> =E2=80=A6 and makes some 1.0 modules illegal. >>>>=20 >>>=20 >>> which modules? >>=20 >> Those that have if-feature or when on a list key - as Martin wrote, = this is not forbidden by RFC 6020. >>=20 >=20 > So none. How can you be so sure? I can write one if you wish. > There are no modules that have key leafs that have if-feature-stmts > that are not in the parent. There is nothing in YANG 1.0 that even > suggests that a key leaf is allowed to be absent in a list. >=20 > The mechanics of the if-feature-stmt and when-stmt > may inadvertently allow it, but it is disallowed in other text so > this overrides it. OK, so let=E2=80=99s move Y07 to DEAD and forget about it. Lada >=20 >=20 >>>=20 >>> if-feature is not a problem at all. >>> The solution is clear and simple to implement for if-feature. >>> Only the whrn-stmt is a problem. So which YANG modules >>> currently have when-stmts on key leafs? >>>=20 >>>=20 >>>>>=20 >>>>> 5. Have different rules for if-feature and when. >>>>=20 >>>> This is IMO too complicated given that such cases should be quite = rare. >>>>=20 >>>=20 >>> This is not too complicated. >>> YANG features are static and the values are not dependent on >>> the datastore node values. A key leaf MUST NOT have >>> if-feature-stmts that do not also apply to its parent. >>>=20 >>> IMO we should make any when-stmt that applies to a key-leaf illegal, >>> just to make it clear that conditional keys are not allowed. >>=20 >> This would still violate the first charter requirement (all compliant = 1.0 modules must remain compliant). >>=20 >=20 >=20 > So then the only solution is to say (even though it is already clear) > that key leafs are never optional. It is an error if an edit would > require the server to remove a key leaf and not its parent. > The server must reject such changes. >=20 >=20 >>>=20 >>>=20 >>>>>=20 >>>>>=20 >>>>> (*) one interesting case is Y07 combined with Y09, for example: >>>>>=20 >>>>> list address { >>>>> key "ip vrf"; >>>>> leaf ip { ... } >>>>> leaf vrf { >>>>> if-feature vrf; >>>>> mandatory false; >>>>> ... >>>>> } >>>>> ... >>>>> } >>>>=20 >>>> This actually makes a good sense and should be allowed if Y09 makes = it into 1.1. >>>>=20 >>>=20 >>> IMO optional keys do not work well at all, and they require a base = type to >>> be changed, which is unacceptable. >>>=20 >>> Allowing default-stmt on a key leaf does not work because a YANG 1.0 = module >>> clearly ignores the default. >>>=20 >>> IMO YANG backward compatibility is easy to define: >>>=20 >>> Axiom 1: Within YANG 1.0 there are statements with clear behavior = and some >>> behavior that is under-defined. Backward compatibility only applies = to the >>> behavior that is clearly defined. >>>=20 >>> Axiom 2: There MUST NOT be any changes in clearly defined behavior >>> when a YANG 1.0 module is parsed as if it were a YANG 1.1 module >>=20 >> The charter says something else. Above the charter text, I think it = is also reasonable to avoid changes in the semantics of existing = statements unless it is a bug fix. But this case clearly qualifies as a = bug fix. >>=20 >=20 > We do not agree on the bug or the fix. >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>>=20 >>>> Lada >>>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>>>=20 >>>>> (**) >>>>>=20 >>>>> grouping a { >>>>> leaf a { >>>>> when "/properties/a": >>>>> ... >>>>> } >>>>> } >>>>>=20 >>>>> grouping b { >>>>> leaf b { >>>>> when "/properties/b": >>>>> ... >>>>> } >>>>> } >>>>>=20 >>>>> list x { >>>>> when "/properties/a and /properties/b"; >>>>> key "a b"; >>>>> uses a; >>>>> uses b; >>>>> } >>>>>=20 >>>>>=20 >>>>>>> I think Lada's suggestion was to ignore if-feature/when b/c of >>>>>>> backwards compatibility reasons. >>>>>>>=20 >>>>>>> This would be legal in 1.1, if we say that we ignore the = if-feature: >>>>>>>=20 >>>>>>> list y { >>>>>>> if-feature "bar"; >>>>>>> key "a b"; >>>>>>> uses x; >>>>>>> leaf b { >>>>>>> type string; >>>>>>> } >>>>>>> } >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> This is legal now -- our tools support it and check for key leafs >>>>>> that are more conditional than their parent. >>>>>=20 >>>>> But this behavior isn't specified in RFC 6020 - and this is the >>>>> problem that we want to solve. >>>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 5 05:19:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBEE1A8546; Mon, 5 Jan 2015 05:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05CUNLooMB4f; Mon, 5 Jan 2015 05:19:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 659761A700F; Mon, 5 Jan 2015 05:19:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105131925.27694.75694.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 05:19:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4sW6_qNq5wtwOcbll36k849TyKU Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:19:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-03.txt Pages : 186 Date : 2015-01-05 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 05:23:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164ED1A711A for ; Mon, 5 Jan 2015 05:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-BtsTl-OG9M for ; Mon, 5 Jan 2015 05:23:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADE01A6F1D for ; Mon, 5 Jan 2015 05:23:08 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FF281280A5D for ; Mon, 5 Jan 2015 14:23:07 +0100 (CET) Date: Mon, 05 Jan 2015 14:23:18 +0100 (CET) Message-Id: <20150105.142318.2166906759771604565.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20150105131925.27694.75694.idtracker@ietfa.amsl.com> References: <20150105131925.27694.75694.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TvCdNtG_j-zsw3Z2h64zWhEQUuo Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:23:10 -0000 Hi, Version -03 addresses the following issues: - Incorporated changes from WG reviews. - Included solution Y05-01. - Included solution Y10-01. - Included solution Y13-01. - Included solution Y28-02. - Included solution Y55-01 (parts of it was included in -01). The issues list (at https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html) has been updated accordingly. /martin From nobody Mon Jan 5 17:11:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC691A9097 for ; Mon, 5 Jan 2015 17:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt6S-qUnodVY for ; Mon, 5 Jan 2015 17:11:42 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A742A1A9094 for ; Mon, 5 Jan 2015 17:11:42 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 01:11:41 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 01:11:40 +0000 From: Kent Watsen To: Ladislav Lhotka , Andy Bierman Thread-Topic: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt Thread-Index: AQHQCxBMAQjAWzxqU0u9RAYW+cJ05Jx5ZBgAgAK4EACANhVagA== Date: Tue, 6 Jan 2015 01:11:40 +0000 Message-ID: References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(2473001)(377454003)(479174004)(377424004)(164054003)(51704005)(2950100001)(21056001)(66066001)(31966008)(102836002)(122556002)(19580405001)(99396003)(19580395003)(83506001)(40100003)(2900100001)(120916001)(76176999)(46102003)(15975445007)(93886004)(2420400003)(54356999)(50986999)(64706001)(101416001)(20776003)(92566001)(105586002)(106356001)(106116001)(97736003)(107046002)(36756003)(4396001)(230783001)(68736005)(86362001)(575784001)(99286002)(1720100001)(87936001)(2656002)(77156002)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <502370F2807C1C4692AC541BF3FACDAC@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 01:11:40.1306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cQxy8jsmfDCa5iU3UNYHgWHj74I Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 01:11:46 -0000 Hi Lada, I don't understand the need for a module like this. I fully appreciate us wanting annotations (default, enabled, etc.), but see those as better defined in purpose-specific drafts (e.g., 'default' is defined in RFC 6243). Also, consider that some annotations might require additional interactions to work (report-all-tagged) whereas others would require versioning the protocol, so clients that don't understand the annotations don't break things, though we might get away with having a general requirement that clients MUST echo all annotations verbatim in case they don't understand them (like on the and elements) It seems that your primary motivation is to have a "type" annotation to support JSON parsing. I understand that need - it reminds me of the XML schema instance "type" annotation, used to support types derived off a base type. But why not define a specific draft for it instead? As for the "enabled" attribute (that's what I called it), I am hoping to resurrect that conversation after current drafts are out the door. Having different names for each variant of a boolean expression won't work, since there will be contradictions and/or ambiguities. For instance, consider this: =3D 90%"> Kent =20 On 12/2/14, 5:17 AM, "Ladislav Lhotka" wrote: >Andy Bierman writes: > >> Hi, >> >> This draft defines 2 annotations: "inactive" and "type". >> I am strongly opposed to the "inactive" annotation. >> The "Conditional Enablement" draft by Kent Watsen should >> be used for this purpose. This topic is more complicated than >> just defining an "inactive" flag. > >The "inactive" annotation is Kent's "simple expression". The other >expression types (complex, time) could be added but I'd strongly suggest >to use a specific name for each. > >It might be a good idea though to add if-feature as an optional >substatement of the "annotation" statement. > >> >> The "type" annotation seems useless because the YANG parser >> decides what internal type gets assigned to a union. >> Sending the types inside the instance document is normally >> only done if there is no schema. > >Some encoding formats (JSON in the first place) carry partial type info, >and this annotation allows both clients and servers to specify the exact >type of a union value in all encodings. > >It would be immediately useful e.g. for inet:host type because the >other party then needn't match the value against multiple regexps to >figure out whether it is an IPv4, IPv6 address or a domain name. > >Do you have other annotations that could be of general interest? > >Lada > >> >> >> >> Andy >> >> >> >> On Fri, Nov 28, 2014 at 5:36 AM, Ladislav Lhotka wrote: >>> Hi, >>> >>> this draft contains the module =B3ietf-yang-annotations=B2 that is >>>intended to contain definitions of generally useful metadata >>>annotations. I included two annotations that I think might be handy. If >>>you know about others, please let me know. >>> >>> Thanks, Lada >>> >>> Begin forwarded message: >>> >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for >>>>draft-lhotka-netmod-yang-annotations-00.txt >>>> Date: 28 Nov 2014 14:31:57 GMT+1 >>>> To: Ladislav Lhotka , "Ladislav Lhotka" >>>> >>>> >>>> A new version of I-D, draft-lhotka-netmod-yang-annotations-00.txt >>>> has been successfully submitted by Ladislav Lhotka and posted to the >>>> IETF repository. >>>> >>>> Name: draft-lhotka-netmod-yang-annotations >>>> Revision: 00 >>>> Title: Common Metadata Annotations for Data Modelled >>>>with YANG >>>> Document date: 2014-11-28 >>>> Group: Individual Submission >>>> Pages: 9 >>>> URL: =20 >>>>http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-annotation >>>>s-00.txt >>>> Status: =20 >>>>https://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-annotations/ >>>> Htmlized: =20 >>>>http://tools.ietf.org/html/draft-lhotka-netmod-yang-annotations-00 >>>> >>>> >>>> Abstract: >>>> This document introduces a collection of common metadata annotations >>>> intended for use in data modeled with the YANG language. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>>submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jan 6 03:57:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE61AC3DF for ; Tue, 6 Jan 2015 03:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, J_CHICKENPOX_75=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1rFNYG8OYW4 for ; Tue, 6 Jan 2015 03:57:39 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 401151AC3D9 for ; Tue, 6 Jan 2015 03:57:39 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 13F111CC089C; Tue, 6 Jan 2015 12:57:44 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman In-Reply-To: References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 06 Jan 2015 12:57:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ndh8e3dLkKRfp5Bjrz3P_oYG3z8 Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 11:57:42 -0000 Hi Kent, Kent Watsen writes: > Hi Lada, > > I don't understand the need for a module like this. I fully appreciate us > wanting annotations (default, enabled, etc.), but see those as better > defined in purpose-specific drafts (e.g., 'default' is defined in RFC > 6243). Also, consider that some annotations might require additional I thought these annotations (and maybe some more) might be of general interest, which was apparently a mistake. > interactions to work (report-all-tagged) whereas others would require > versioning the protocol, so clients that don't understand the annotations > don't break things, though we might get away with having a general > requirement that clients MUST echo all annotations verbatim in case they > don't understand them (like on the and elements) > > It seems that your primary motivation is to have a "type" annotation to > support JSON parsing. I understand that need - it reminds me of the Actually, this one would be slightly more useful for XML. My motivation however was to overcome the limitations of the existing union rules and make unions easier to resolve. For example, up to three regexps have to be matched in order to resolve an inet:host value. > XML schema instance "type" annotation, used to support types derived > off a base type. But why not define a specific draft for it instead? > > As for the "enabled" attribute (that's what I called it), I am hoping to > resurrect that conversation after current drafts are out the door. Sure. > Having different names for each variant of a boolean expression won't wor= k, since > there will be contradictions and/or ambiguities. For instance, consider > this: > > enabled-if=3D"/sys/cpu-usage >=3D 90%"> It is easy to define reasonable arbitration rules, e.g. enabled=3D"false" would take precedence in this case. Occassionally, it can be useful to be able to do something like in your example. Also, I thought enabled=3D"false" was a no-brainer whereas enabled-if will probably need much longer discussion. Lada > > Kent >=20=20 > > > > > On 12/2/14, 5:17 AM, "Ladislav Lhotka" wrote: > >>Andy Bierman writes: >> >>> Hi, >>> >>> This draft defines 2 annotations: "inactive" and "type". >>> I am strongly opposed to the "inactive" annotation. >>> The "Conditional Enablement" draft by Kent Watsen should >>> be used for this purpose. This topic is more complicated than >>> just defining an "inactive" flag. >> >>The "inactive" annotation is Kent's "simple expression". The other >>expression types (complex, time) could be added but I'd strongly suggest >>to use a specific name for each. >> >>It might be a good idea though to add if-feature as an optional >>substatement of the "annotation" statement. >> >>> >>> The "type" annotation seems useless because the YANG parser >>> decides what internal type gets assigned to a union. >>> Sending the types inside the instance document is normally >>> only done if there is no schema. >> >>Some encoding formats (JSON in the first place) carry partial type info, >>and this annotation allows both clients and servers to specify the exact >>type of a union value in all encodings. >> >>It would be immediately useful e.g. for inet:host type because the >>other party then needn't match the value against multiple regexps to >>figure out whether it is an IPv4, IPv6 address or a domain name. >> >>Do you have other annotations that could be of general interest? >> >>Lada >> >>> >>> >>> >>> Andy >>> >>> >>> >>> On Fri, Nov 28, 2014 at 5:36 AM, Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> this draft contains the module =C2=B3ietf-yang-annotations=C2=B2 that = is >>>>intended to contain definitions of generally useful metadata >>>>annotations. I included two annotations that I think might be handy. If >>>>you know about others, please let me know. >>>> >>>> Thanks, Lada >>>> >>>> Begin forwarded message: >>>> >>>>> From: internet-drafts@ietf.org >>>>> Subject: New Version Notification for >>>>>draft-lhotka-netmod-yang-annotations-00.txt >>>>> Date: 28 Nov 2014 14:31:57 GMT+1 >>>>> To: Ladislav Lhotka , "Ladislav Lhotka" >>>>> >>>>> >>>>> A new version of I-D, draft-lhotka-netmod-yang-annotations-00.txt >>>>> has been successfully submitted by Ladislav Lhotka and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-lhotka-netmod-yang-annotations >>>>> Revision: 00 >>>>> Title: Common Metadata Annotations for Data Modelled >>>>>with YANG >>>>> Document date: 2014-11-28 >>>>> Group: Individual Submission >>>>> Pages: 9 >>>>> URL:=20=20=20=20=20=20=20=20=20=20 >>>>>http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-annotation >>>>>s-00.txt >>>>> Status:=20=20=20=20=20=20=20 >>>>>https://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-annotations/ >>>>> Htmlized:=20=20=20=20=20 >>>>>http://tools.ietf.org/html/draft-lhotka-netmod-yang-annotations-00 >>>>> >>>>> >>>>> Abstract: >>>>> This document introduces a collection of common metadata annotations >>>>> intended for use in data modeled with the YANG language. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>>submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> >>--=20 >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 6 04:10:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F161AC42D for ; Tue, 6 Jan 2015 04:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lvxosdZPfW1 for ; Tue, 6 Jan 2015 04:10:35 -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 E8AF81AC435 for ; Tue, 6 Jan 2015 04:09:37 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2FFB26FD; Tue, 6 Jan 2015 13:09:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6CLGAfMAHzdo; Tue, 6 Jan 2015 13:09:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Jan 2015 13:09:35 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 559752002C; Tue, 6 Jan 2015 13:09:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6x39GEWFl720; Tue, 6 Jan 2015 13:09:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C16A820017; Tue, 6 Jan 2015 13:09:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C7081305031D; Tue, 6 Jan 2015 13:09:34 +0100 (CET) Date: Tue, 6 Jan 2015 13:09:34 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150106120934.GB10192@elstar.local> Mail-Followup-To: Ladislav Lhotka , Kent Watsen , Andy Bierman , NETMOD Working Group References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-b1G0Bv-Ksc_0_uXuu5OSCWpq84 Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 12:10:37 -0000 On Tue, Jan 06, 2015 at 12:57:37PM +0100, Ladislav Lhotka wrote: > > Actually, this one would be slightly more useful for XML. My motivation > however was to overcome the limitations of the existing union rules and > make unions easier to resolve. For example, up to three regexps have to > be matched in order to resolve an inet:host value. Implementors have said that there is no problem. There is no requirement to implement things in the most inefficient way. There are of course more efficient ways to convert an inet:host value into an internal representation. Having a common type library allows to implement and utilize such optimizations. You seem to believe that type information on the wire is a good thing. I am not sure this view is generally shared. I have heard from implementors that they will follow the postel principle and be lenient in what they accept (that is they may even ignore the type information of a particular encoding for the sake of interoperability). YANG was not designed to carry type information on the wire. And as far as I recall, this was by intention. The fact that some ecodings may carry type information should not change the design of YANG. And we already learned that type systems sometimes do not align well anyway. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 6 05:17:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B0F1ACD33 for ; Tue, 6 Jan 2015 05:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqSlHmTkUOrZ for ; Tue, 6 Jan 2015 05:16:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D70C1ACD26 for ; Tue, 6 Jan 2015 05:16:58 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 95FA4140A50; Tue, 6 Jan 2015 14:16:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420550215; bh=hTGkzsoBjtaskRaJ6AMEMHRKBdZsZfPx2fn6q88uPQg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rFjOPfmFc2YZ3Wk7kqWD76ZLALZbSIDCjYBJjwBXUPstGV+mEnAlZ4uGnL4ugDRYl b2cmANylvQA6ryChs0F+unp7k4V5r2BJvDOBT1NZdnknXI7edBfFVMJTyIXj/q0CjX J68+bOPERZt1Pkd58WMDBT5ic6jOlTK1V2HlP454= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150106120934.GB10192@elstar.local> Date: Tue, 6 Jan 2015 14:16:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141128133157.7808.83054.idtracker@ietfa.amsl.com> <1307F092-152A-487F-A5C8-8DE449A0015D@nic.cz> <20150106120934.GB10192@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LhXHufiLN1VhdY3VdrKYcHdqOEI Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-annotations-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 13:17:01 -0000 Juergen, as I already said, I consider that draft dead and I am not going to = defend this annotation or another. I just tried to explain my original = motivation because Kent wrote that it was intended to aid JSON parsing, = which it wasn=E2=80=99t. Lada > On 06 Jan 2015, at 13:09, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 06, 2015 at 12:57:37PM +0100, Ladislav Lhotka wrote: >>=20 >> Actually, this one would be slightly more useful for XML. My = motivation >> however was to overcome the limitations of the existing union rules = and >> make unions easier to resolve. For example, up to three regexps have = to >> be matched in order to resolve an inet:host value. >=20 > Implementors have said that there is no problem. There is no > requirement to implement things in the most inefficient way. There are > of course more efficient ways to convert an inet:host value into an > internal representation. Having a common type library allows to > implement and utilize such optimizations. >=20 > You seem to believe that type information on the wire is a good > thing. I am not sure this view is generally shared. I have heard from > implementors that they will follow the postel principle and be lenient > in what they accept (that is they may even ignore the type information > of a particular encoding for the sake of interoperability). YANG was > not designed to carry type information on the wire. And as far as I > recall, this was by intention. The fact that some ecodings may carry > type information should not change the design of YANG. And we already > learned that type systems sometimes do not align well anyway. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 6 13:21:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C381A86FF for ; Tue, 6 Jan 2015 13:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhd54n19Lynz for ; Tue, 6 Jan 2015 13:21:22 -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 C6C831A86F7 for ; Tue, 6 Jan 2015 13:21:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9328D753 for ; Tue, 6 Jan 2015 22:21:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NxD5TQsMyRLo for ; Tue, 6 Jan 2015 22:21:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 6 Jan 2015 22:21:21 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE5522002C for ; Tue, 6 Jan 2015 22:21:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 34EXOqliOtPv; Tue, 6 Jan 2015 22:21:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB62720017; Tue, 6 Jan 2015 22:21:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 239073050AE7; Tue, 6 Jan 2015 22:21:20 +0100 (CET) Date: Tue, 6 Jan 2015 22:21:20 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150106212118.GB11692@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/z_ju_q5aE4Ix7IT1lCLjFBvkWhM Subject: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:21:24 -0000 Hi, the chairs like to receive feedback from the WG whether draft-lhotka-netmod-yang-metadata-00 should become a working group work item. The abstract says: This document defines a YANG extension statement that allows for defining metadata annotions in YANG modules. The document also specifies the encoding of annotations and rules for annotating instances of YANG data nodes. In particular, the chairs like to know - who believes a mechanism to define metadata annotations should be standardized - who plans to use the proposed annotation extension statement - who is willing to review the document during the WG phase Lada's IETF 91 slides can be found here: http://www.ietf.org/proceedings/91/slides/slides-91-netmod-4.pdf Please respond by January 23rd the latest. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 6 13:41:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4835B1A871B for ; Tue, 6 Jan 2015 13:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmj0dHKpjex3 for ; Tue, 6 Jan 2015 13:41:00 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E73F1A1A1E for ; Tue, 6 Jan 2015 13:41:00 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so143491lab.12 for ; Tue, 06 Jan 2015 13:40:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Rl7vbrM/nNwLjRS+yY1mDdRxQcvPN7jvNKpVh32Myaw=; b=KmBtC5BH6Wid2tYHYwOpRLqgUEJF1e/097pwl8pV8NdX0T8Jy60+UHt4dpIfMy/5Z0 BiNdG3ZLNPcWbcmTOfyqTv/wXy+zt8FoPs2fcOYfLdPZuIA9fndMMXo4iiVZGY54rBGJ +PgunSkdt/TKI8lWLY9Hbol3Lm3rrXY1GPH3AI3doVbEDPZQvOjUIopVpCmSJ2WCm62l bJZFDh9/S2ZM/1Hj4n4kLk0yJX1JIMKOM5cwawQb0sFQl0/WtQEz9ts+fMH83bCBjT50 bVhJVOZSupqg/uD/hn3nw+Y/3ldeQMwSumVJsWqzm3rKAiCh+INuwnSNyPnfOJAUKAH3 TwoA== X-Gm-Message-State: ALoCoQla0egT22m4vziKVzPeVfoZj9YfMlg2rxMeNS0X4IuXIwpRXcwkKYSz0cFMRpnAenjjXHfv MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr79383136lbv.21.1420580458458; Tue, 06 Jan 2015 13:40:58 -0800 (PST) Received: by 10.112.77.231 with HTTP; Tue, 6 Jan 2015 13:40:58 -0800 (PST) In-Reply-To: <20150106212118.GB11692@elstar.local> References: <20150106212118.GB11692@elstar.local> Date: Tue, 6 Jan 2015 13:40:58 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aYJAIxIQ0F6_v1lFQYmCNx3Q9o8 Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:41:02 -0000 On Tue, Jan 6, 2015 at 1:21 PM, Juergen Schoenwaelder wrote: > Hi, > > the chairs like to receive feedback from the WG whether > > draft-lhotka-netmod-yang-metadata-00 > > should become a working group work item. The abstract says: > > This document defines a YANG extension statement that allows for > defining metadata annotions in YANG modules. The document also > specifies the encoding of annotations and rules for annotating > instances of YANG data nodes. > > In particular, the chairs like to know > > - who believes a mechanism to define metadata annotations > should be standardized > - who plans to use the proposed annotation extension statement > - who is willing to review the document during the WG phase > yes to all 3. We have implemented the JSON server output (but not input yet). The extension is not supported yet, but planned. Currently there is hard-wired support for "with-defaults" and "owner". The extension is a good way for the server to tell the client what attributes it supports and tell the validation tools what attributes to process automatically instead of generating a parsing error. > Lada's IETF 91 slides can be found here: > > http://www.ietf.org/proceedings/91/slides/slides-91-netmod-4.pdf > > Please respond by January 23rd the latest. > > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jan 6 17:12:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C602D1A036F for ; Tue, 6 Jan 2015 17:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5wJkLxnx4sT for ; Tue, 6 Jan 2015 17:12:39 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id A6C661A0072 for ; Tue, 6 Jan 2015 17:12:39 -0800 (PST) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t071CcxL017917 for ; Wed, 7 Jan 2015 10:12:38 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id BE73A5F58E for ; Wed, 7 Jan 2015 10:12:38 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id B149A5F588 for ; Wed, 7 Jan 2015 10:12:38 +0900 (JST) Received: from [129.60.21.195] (neba-hp-shiomoto.silab.ecl.ntt.co.jp [129.60.21.195]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t071CcST004870 for ; Wed, 7 Jan 2015 10:12:38 +0900 Message-ID: <54AC88BE.5010507@lab.ntt.co.jp> Date: Wed, 07 Jan 2015 10:15:42 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EZ7t2rU3s3GtBoKboufFVN3aogA Subject: [netmod] Call for Presentation: iPOP 2015 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 01:12:42 -0000 [Apologies, if you receive multiple copies of this CFP] --------------------------------------- Call for Presentation 11th International Conference on IP + Optical Network (iPOP 2015) April 20-22, 2015 Okinawa Jichikaikan, Naha Okinawa Japan http://www.pilab.jp/ipop2015/ Important Dates: Submission deadline of one-page abstract: January 16, 2015 Notification of acceptance: February 23, 2015 Submission deadline of final presentation slides: March 13, 2015 Following the successful events of iPOP, the 11th Conference on IP+Optical Network (iPOP 2015) will be held at Okinawa Jichikaikan, Naha Okinawa Japan, April 20-22, 2015. The conference has been provided opportunities for both of the industry and the academia to share their knowledge, new findings, and experiences on the state-of-the-art IP and optical networking technologies for these ten years. The Technical Program Committee for iPOP 2015 is soliciting presentation proposals for this conference. Architecture and protocol designs, experiments/PoCs/field trials, theories/algorithms, implementations, and operational experiences are solicited. The topics of the conference will include but not be limited to the following: * Control plane (MPLS/GMPLS, OpenFlow, etc) * SDN for packet and optical transport networks * MLN (Multi-Layer Network), MRN (Multi-Region Network) * TE (Traffic Engineering), PCE (Path Computation Element) * Network abstraction/virtualization * Flex-grid, elastic optical networks * Optical networking/switching for cloud services * Data center and WAN orchestration * Carrier Ethernet and MPLS-TP for backhauling * Service function chaining for mobile networks * Security * QoS (Quality of Service)/QoE (Quality of Experience) * Network operation and management * Standardization/interoperability * Open Source Software (OSS) for SDN/NFV * DevOps Submit an extended abstract (400 words, 1 page), including figures and diagrams, speaker’s name, affiliation, and contact information, to the Technical Program Committee: ipop2015-cfp@pilab.jp. Please see http://www.pilab.jp/ipop2015/ for more details. ------------------------------------------------------------------------ -- Kohei Shiomoto, Ph.D Senior Manager, Communication Traffic & Service Quality Project NTT Network Technology Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION TEL +81-422-59-4402 FAX +81-422-59-6364 From nobody Tue Jan 6 23:56:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D911A8979 for ; Tue, 6 Jan 2015 23:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYzSW7VTM8HS for ; Tue, 6 Jan 2015 23:56:27 -0800 (PST) Received: from sjmda16.webex.com (sjmda16.webex.com [64.68.124.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C3E1A8976 for ; Tue, 6 Jan 2015 23:56:27 -0800 (PST) Received: from jva2tc114.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-2.webex.com [64.68.121.246]) by sjmda16.webex.com (Postfix) with ESMTP id 43628A01D1 for ; Wed, 7 Jan 2015 07:56:27 +0000 (GMT) Received: from jva2tc114.webex.com (localhost [127.0.0.1]) by jva2tc114.webex.com (Postfix) with ESMTP id E859E15F54A for ; Wed, 7 Jan 2015 07:56:26 +0000 (GMT) Date: Wed, 7 Jan 2015 07:56:26 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <1327093186.73191.1420617386949.JavaMail.nobody@jva2tc114.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_73189_1138221568.1420617386948" X-Priority: 3 Importance: normal Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DvJ9g-sYLQEVodDYmlnwuOCzRIc Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 07:56:29 -0000 ------=_Part_73189_1138221568.1420617386948 Content-Type: multipart/Alternative; boundary="----=_Part_73190_305565900.1420617386948" ------=_Part_73190_305565900.1420617386948 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCldlZG5lc2RheSwgSmFudWFyeSA3LCAyMDE1 CjQ6MDAgcG0gIHwgIEV1cm9wZSBUaW1lIChCZXJsaW4sIEdNVCswMTowMCkgIHwgIDIgaHIKCgpK T0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTc2MTcwMGQyYTFkYjUxZGEyNWM0ZTI5MmMwYWRjOTYwCk1lZXRpbmcgbnVtYmVyOiA2NDggNzc4 IDI3MApNZWV0aW5nIHBhc3N3b3JkOiBzaGFoc2g1RQoKDQpKT0lOIEJZIFBIT05FDQoxLTg3Ny02 NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgCjEtNjUwLTQ3OS0z MjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0OCA3Nzgg MjcwCgpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IApodHRwOi8vd3d3LndlYmV4LmNv bS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRkIHRoaXMgbWVldGluZyB0byB5 b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMDZi MDQ0ZjI0OWNhNDgwYzBkZmQxMWRmODNjZTczYzANCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/ IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMKCgpJ TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwg ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNl c3Npb24uCg== ------=_Part_73190_305565900.1420617386948 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+V2Vk bmVzZGF5LCBKYW51YXJ5IDcsIDIwMTUKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJ CTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjQ6MDAgcG0mbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7RXVyb3BlIFRpbWUgKEJlcmxpbiwgR01UKzAxOjAwKSZuYnNwOyZuYnNwO3wm bmJzcDsmbmJzcDsyIGhyCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+ Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRo OmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5 bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXplOjE2cHgiPgoJCQkJCQkJCQk8YSBocmVmPSJodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNzYxNzAwZDJhMWRiNTFkYTI1YzRl MjkyYzBhZGM5NjAiCgkJCQkJCQkJCQlzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1z aXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJCQkJCQkJCQk8Yj5Kb2luIFdlYkV4IG1lZXRpbmc8 L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJs ZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+ CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGlu Zy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVyOgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQkJPHRkPjY0OCA3NzggMjcwCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8 dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij5NZWV0aW5nIHBhc3N3 b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPnNoYWhzaDVFPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwv dGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5 bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0ZCBz dHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48L3RyPjx0ciBz dHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtODc3LTY2OC00NDkzPC9iPiZuYnNwO0NhbGwtaW4g dG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChV Uy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPkFjY2VzcyBjb2Rl OiZuYnNwOzY0OCA3NzggMjcwPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxh IGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRm IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6IzAwQUZG OTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L3RkPjwvdHI+PC90YWJsZT4K CgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWln aHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZv bnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tMDZiMDQ0ZjI0OWNhNDgwYzBkZmQxMWRmODNjZTczYzAiIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNweCI+QWRkIHRoaXMgbWVldGlu ZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRkIHN0eWxlPSJmb250LXNp emU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAgICAgICAgQ2Fu J3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAgICAg ICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRhYmxl Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJCQkJ CTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJSU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90cj4K CQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_73190_305565900.1420617386948-- ------=_Part_73189_1138221568.1420617386948 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDEwN1QxNjAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUwMTA3VDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxClVJRDpXRUJFWC1NRUVUSU5HIENFTlRF Ui02LjA0NTY2ODAtMzE3NjE4MDA3LVNVPWlldGYKRFRTVEFNUDoyMDE1MDEwN1QxNTAwMDBaCkRF U0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTc2MTcwMGQyYTFkYjUxZGEyNWM0ZTI5MmMwYWRjOTYwXG5NZWV0 aW5nIG51bWJlcjogNjQ4IDc3OCAyNzBcbk1lZXRpbmcgcGFzc3dvcmQ6IHNoYWhzaDVFXG5cblxu Sk9JTiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChV Uy9DYW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KVxuQWNjZXNzIGNvZGU6IDY0OCA3NzggMjcwXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0 aW9uczogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk ZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztG TVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4g PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW03NjE3MDBkMmExZGI1MWRhMjVjNGUyOTJjMGFkYzk2 MCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4 IG1lZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9G T05UPgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPjY0OCA3NzggMjcwPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8 L3RhYmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+c2hhaHNoNUU8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4m bmJzcDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIz IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7 IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+ MS04NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVT L0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ4IDc3OCAyNzA8L0ZP TlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVf cmVzdHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFy aWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJS PjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVm PSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0i IzAwQUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8 QlI+Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUK Q0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRF U0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_73189_1138221568.1420617386948-- From nobody Wed Jan 7 04:18:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15A1A89FB for ; Wed, 7 Jan 2015 04:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN9klcMgbMJU for ; Wed, 7 Jan 2015 04:18:08 -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 B729E1A8728 for ; Wed, 7 Jan 2015 04:18:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4D6BC716 for ; Wed, 7 Jan 2015 13:18:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JgN48w0xORmi for ; Wed, 7 Jan 2015 13:17:50 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 7 Jan 2015 13:18:04 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C486C2002C for ; Wed, 7 Jan 2015 13:18:04 +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 VCN-MmE9gOUA; Wed, 7 Jan 2015 13:18:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB7BC20017; Wed, 7 Jan 2015 13:18:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D65CB3050F63; Wed, 7 Jan 2015 13:18:03 +0100 (CET) Date: Wed, 7 Jan 2015 13:18:02 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150107121802.GA13160@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jEgiffceWQUxMb-BDvaIQckWhBg Subject: [netmod] minutes of the NETMOD 2014-12-17 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 12:18:12 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2014-12-17 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2014-12-17-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 10th YANG 1.1 Virtual Interim Wednesday, December 17, 2014, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants ME = Juergen Schoenwaelder LL = Lada Lhotka MB = Martin Bjorklund AB = Andy Bierman DR = David Reid JS = Jason Sterne BC = Benoit Clais BL = Balazs Lengyel KW = Kent Watsen DR = Dan Romascanu * Status Check - Y09 introduce optional keys Need to validate adoption of Y09-03 on the mailing list. - Y16 module advertisement optimization Need to validate adoption of Y16-03 on the mailing list. - Y18 fix "when" expression context problem Pending action MB => action to be completed - Y59 restrict use of 64-bit numbers in XPath expressions Moved to open, perhaps discuss resolution? - Y25 make enum numbering purely informative and optional JS to start a thread on the mailing list. There once was rough consensus for Y25-01 - we need to check what happens on the list. - Y26 allow mandatory nodes in augment Pending action LL => action done - Y58 associate an actions with a data node Pending action JS (check with NETCONF chairs concerning NACM update). - Y34 remove/deprecate/replace the 'anyxml' statement Need to verify Y34-04 on the mailing list and that it can handle all existing meaningful uses of anyxml. - Y49 clarify nested submodule behavior Need to validate adoption of Y49-04 on the mailing list. - Y57 non-unique leaf-list There was an action item for BL on 2014-10-15 => action to be completed - Y45 better conformance mechanism How to resolve this? Do we need to collect the requirements a solution must satisfy? It sometimes feels like going in circles on this. * Y45 better conformance mechanism JS: We seem to go in circles, can we collect use cases to verify solution proposals against? MB: Yes, we seem to go in circles. AB: Using import-by-revision everywhere is one solution, but it has a cost. AB: I wanted to move conformance out of the YANG module, conformance is specified separate from the objects. BL: Simplifying assumptions may be needed (only one version per module) AB: Do we agree on one module per server? MB: Only one module where you implement data nodes. KW: Import by revision resolves which version of a type has been used. MB: This may lead to massive updates if a type module changes. JS: Lets distinguish between (a) a modular server implementing multiple versions within a module and (b) different modules importing from different versions of some other module. MB: Import by revision does not solve the problem. MB: The problem is two augmenting modules importing the augmented module at different revision numbers. KW: RFC6020 says must statement can be relaxed, it is silent about when statements, perhaps an errata? AB: Phil said that if B augments A, then a server needs to implement A KW: If you have a module A that imports only groupings from B, then the server does not need to claim implementing B BL: We use a lot of imports without import-by-revision. MB: This may be a maintenance issue. AB: There is already some confusion about what needs to be announced. KW: You can add a must statement to a new node, but you can't add a stricter statement to an existing node. BL: But you can break the rules by side effects. BL: I like to know which version of a typedef module is actually being used. MB: The requirement is that the client can understand which version of a typedef module is actually used by a module. AB: Perhaps keep it simple - if you change a grouping, you have to give it a new name. KW: Lets collect statements (axioms) we agree on (or not). A0. Claiming conformance means that the server implements all protocol-accessible nodes, rpcs, notifications (modulo supported features). It does not include aspects that are not directly accessible, including typedefs, identities, and groupings. A1. A server can only claim conformance (i.e., implement the data-nodes, rpcs, notifications) to one revision of a specific module at a time. A2. A server does not need to claim conformance to a module that was only imported by other modules for purposes other than augment. A3. A server must claim conformance to a module if it is imported by another module for the purpose of an augment statement by another module the server claims conformance to. A4. The version of all imported items including typedefs, groupings, etc. must be visible to the client. BL: We need to maintain backwards compatibility since management systems are very hard to update. LL: But backwards compatibility rules hard coded in the language limit flexibility where needed. AB: I agree with BL, we need to be most concerned about software updates. AB: The cost of being wrong can be high, so try to check the modules well before publishing them. KW: I believe vendors will implement functionally overlapping modules. MB: What is in that case the response to a get-config? KW: Without a namespace, you get the default module set, otherwise the namespace defines what is returned to a client. KW: The developers of submodules may use imports at different revision levels. BL: This may be fine for the developers, but how does an operator deal with this? KW: I assume the operator's code is data model driven. The import-by-revision will tell them which imported definition was used. AB: In a module, you can't import a module multiple times. But this happens with submodules if they import at different revisions. BL: I do not like to allow importing different revisions of A in different submodules. MB: But it depends on the solution. We need to work out the use cases and evaluate the solution against use cases. BL: RFC 6020 says multiple revisions imported in a module is not supported. It is not clear whether this applies to modules and/or submodules. AB: You can only have conformance to things that are protocol accessible. LL: A server advertises the identities it implements by advertising the module where the identity is defined. JS: I do not think this is valid for say iana-interface-types. AB: The set of identity values that can be used is a runtime issue. KW: Is this not similar to groupings? MB: No, because the value is used (or not) at runtime. MB: Use an RPC to discover possible values at runtime. LL: The problem is the IANA interface type list, the identities should be defined in type specific modules. BL: Even with specialized modules, we will see the problem again. At the end, every identity ends up in a separate module. AB: Line cards often have specific constraints and we need to be able to deal with this. BL: There are also license restrictions that apply. AB: The problem is when import-by-revision is mixed with import without revision. KW: We need to distinguish the different types of imports (import for just groupings/typdefs/etc vs import for augment). Actions: - MB volunteers to kick of the process of collecting use-cases and solutions. --fUYQa+Pmc3FrFX/N-- From nobody Wed Jan 7 06:22:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FF91A904A for ; Wed, 7 Jan 2015 06:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MXz29_C8g23 for ; Wed, 7 Jan 2015 06:22:19 -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 60AE01A902D for ; Wed, 7 Jan 2015 06:22:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2CEF98E9; Wed, 7 Jan 2015 15:22:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id E2Sp0z-MBlhE; Wed, 7 Jan 2015 15:21:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 7 Jan 2015 15:22:14 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4642F2002C; Wed, 7 Jan 2015 15:22:14 +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 09e3keBdDX1w; Wed, 7 Jan 2015 15:22:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 319C020017; Wed, 7 Jan 2015 15:22:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 823273051093; Wed, 7 Jan 2015 15:22:14 +0100 (CET) Date: Wed, 7 Jan 2015 15:22:13 +0100 From: Juergen Schoenwaelder To: netmod-chairs@tools.ietf.org Message-ID: <20150107142213.GA13358@elstar.local> Mail-Followup-To: netmod-chairs@tools.ietf.org, netmod@ietf.org References: <1327093186.73191.1420617386949.JavaMail.nobody@jva2tc114.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1327093186.73191.1420617386949.JavaMail.nobody@jva2tc114.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6Zmt-8lIMw2SsuTeUjnF_A7TEYQ Cc: netmod@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:22:21 -0000 Hi, our etherpad is going to be this one: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-01-107?useMonospaceFont=true /js On Wed, Jan 07, 2015 at 07:56:26AM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Wednesday, January 7, 2015 > 4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hr > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m761700d2a1db51da25c4e292c0adc960 > Meeting number: 648 778 270 > Meeting password: shahsh5E > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 648 778 270 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=m06b044f249ca480c0dfd11df83ce73c0 > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 7 06:32:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967B11A9025 for ; Wed, 7 Jan 2015 06:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYoeuMrx-FOJ for ; Wed, 7 Jan 2015 06:32:16 -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 7264A1A6F87 for ; Wed, 7 Jan 2015 06:32:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3BCCC8E9 for ; Wed, 7 Jan 2015 15:32:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wKsxRUrsC3yH for ; Wed, 7 Jan 2015 15:31:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 7 Jan 2015 15:32:14 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A284D2002F for ; Wed, 7 Jan 2015 15:32:14 +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 pm_PuXr_xXes; Wed, 7 Jan 2015 15:32:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDF3520017; Wed, 7 Jan 2015 15:32:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2B2AC3051125; Wed, 7 Jan 2015 15:32:16 +0100 (CET) Date: Wed, 7 Jan 2015 15:32:16 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150107143216.GA13482@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7OZw3CiTmai1GUOVpEgWIu6wmMo Subject: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:32:17 -0000 The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. Please speak up by Wednesday 2015-01-14 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 7 06:33:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E06D1A906E for ; Wed, 7 Jan 2015 06:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9quHOGn6zEa for ; Wed, 7 Jan 2015 06:33:44 -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 D510E1A6F87 for ; Wed, 7 Jan 2015 06:33:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A0EA7716 for ; Wed, 7 Jan 2015 15:33:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Kk4wbz0VSafM for ; Wed, 7 Jan 2015 15:33:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 7 Jan 2015 15:33:42 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D45F2002C for ; Wed, 7 Jan 2015 15:33:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L8J-fNHkFpKm; Wed, 7 Jan 2015 15:33:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B69220017; Wed, 7 Jan 2015 15:33:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC699305114E; Wed, 7 Jan 2015 15:33:43 +0100 (CET) Date: Wed, 7 Jan 2015 15:33:43 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150107143343.GB13482@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hCALXt5pasjmoqLO2tpq4d8ZkaY Subject: [netmod] VRFY :Y16: module advertisement optimization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:33:45 -0000 The 2014-12-03 virtual interim meeting proposal is to adopt Y16-03. Please speak up by Wednesday 2015-01-14 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 7 06:55:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1572E1A90C4 for ; Wed, 7 Jan 2015 06:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB7u8cw_DfNY for ; Wed, 7 Jan 2015 06:55:03 -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 24B341A90B9 for ; Wed, 7 Jan 2015 06:55:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E69BA715 for ; Wed, 7 Jan 2015 15:55:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KflKi2XZOgw4 for ; Wed, 7 Jan 2015 15:54:46 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 7 Jan 2015 15:55:01 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 357C72002C for ; Wed, 7 Jan 2015 15:55:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NLE0GEpFjSAD; Wed, 7 Jan 2015 15:55:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BCFE20017; Wed, 7 Jan 2015 15:55:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9745230511D2; Wed, 7 Jan 2015 15:55:02 +0100 (CET) Date: Wed, 7 Jan 2015 15:55:02 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150107145502.GD13482@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_SOIcVdYYZymamdv0uAqddlUMRY Subject: [netmod] VRFY :Y49: clarify nested submodule behavior X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:55:09 -0000 The 2014-12-03 virtual interim meeting proposal is to adopt Y49-04. Please speak up by Wednesday 2015-01-14 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 7 06:56:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F441A9084 for ; Wed, 7 Jan 2015 06:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0MBpNrtwg6G for ; Wed, 7 Jan 2015 06:56:21 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 784991A8FD7 for ; Wed, 7 Jan 2015 06:56:21 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 07E801CC003F; Wed, 7 Jan 2015 15:56:27 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20150106212118.GB11692@elstar.local> References: <20150106212118.GB11692@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 07 Jan 2015 15:56:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qmOmMXP5uknYv7hIWLnV2cfk9w0 Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:56:25 -0000 Juergen Schoenwaelder writes: > Hi, > > the chairs like to receive feedback from the WG whether > > draft-lhotka-netmod-yang-metadata-00 > > should become a working group work item. The abstract says: > > This document defines a YANG extension statement that allows for > defining metadata annotions in YANG modules. The document also > specifies the encoding of annotations and rules for annotating > instances of YANG data nodes. > > In particular, the chairs like to know > > - who believes a mechanism to define metadata annotations > should be standardized > - who plans to use the proposed annotation extension statement Support for this extension statement is now implemented in the following two plugins of pyang: - dsdl: XML instance documents can be validated with DSDL schemas including annotations defined through this extension; - jsonxsl: Annotated XML documents can be translated to JSON. I also plan to implement translation of annotations in the opposite direction (JSON->XML) via the jtox plugin. Lada > - who is willing to review the document during the WG phase > > Lada's IETF 91 slides can be found here: > > http://www.ietf.org/proceedings/91/slides/slides-91-netmod-4.pdf > > Please respond by January 23rd the latest. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 7 06:58:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25661A9084 for ; Wed, 7 Jan 2015 06:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2wIe07cvGlN for ; Wed, 7 Jan 2015 06:58:46 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0024E1A6F2B for ; Wed, 7 Jan 2015 06:58:38 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id 10so1209743lbg.29 for ; Wed, 07 Jan 2015 06:58:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2F3xjpa9Uy4fW1ch7b/e+Zes7nOG25MKwLRq5mKHhIU=; b=O1e+X9UbpOSlkeZ4BpzlMv8FlL68yQFUnSfsH+A/lUssF+87ykg6vblkvh+Ur56GV8 hPWvHd9J4CLqZVFbKFTkPjxRJMpXAMfLfoEu2qzJKivqYtRANP6SG9cXCEPAHsqzEeok 251YDdXvftGzueJNtTKe/sVPmCc/PYPE/HoErLnYM5GJL2hb4HZZfJ1yap7ng/wouAsT YkpkwCMUntrrh7OOA2QiczXygXI8SKmCffVG5YW+g8kAnSj3LO6+qWujeR5ba9uAtCay +fGMwbAXK2zGXBVjWs6dFs2M4HUJ/EgOPMJVMU7zutTtpvNaIp2BVGHQxd/gJRyQW24r D4Ag== X-Gm-Message-State: ALoCoQliz05KZG5aYLGDGDHNoL0+qXOXnpemO/YscEMELItBCLe/SJ5DkSRgJnPlyTalrqrcZ3Yv MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr5206539lbv.21.1420642717371; Wed, 07 Jan 2015 06:58:37 -0800 (PST) Received: by 10.112.77.231 with HTTP; Wed, 7 Jan 2015 06:58:37 -0800 (PST) In-Reply-To: <20150107143216.GA13482@elstar.local> References: <20150107143216.GA13482@elstar.local> Date: Wed, 7 Jan 2015 06:58:37 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2PxJkJMH0qP59tw9AHPMAApySR0 Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 14:58:48 -0000 Hi, I object to Y09-3. In YANG 1.0 a default on a key leaf is ignored. The exact same module parsed as YANG 1.1 does not ignore the default on a key leaf. Providing 1 leaf is supposed to be an error and all of a sudden it is not and creates an entry with the automatic key. This is not what the YANG 1.0 client is expecting. Also, when defaults are suppressed in or replies, do the key leafs that match defaults get suppressed? This would also break a YANG 1.0 client. Andy On Wed, Jan 7, 2015 at 6:32 AM, Juergen Schoenwaelder wrote: > The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. > Please speak up by Wednesday 2015-01-14 if you disagree with this > proposal. > > For more details, see the issues list and the virtual interim meeting > minutes available here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jan 7 07:00:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A311A8FD7 for ; Wed, 7 Jan 2015 07:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pKulbNOUGw3 for ; Wed, 7 Jan 2015 07:00:09 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF231A9108 for ; Wed, 7 Jan 2015 06:59:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2C85771A for ; Wed, 7 Jan 2015 15:59:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oWSthlKkUCO4 for ; Wed, 7 Jan 2015 15:59:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 7 Jan 2015 15:59:42 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CF262002C for ; Wed, 7 Jan 2015 15:59:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VB35m2edLdmq; Wed, 7 Jan 2015 15:59:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F3F720017; Wed, 7 Jan 2015 15:59:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 910AA3051209; Wed, 7 Jan 2015 15:59:43 +0100 (CET) Date: Wed, 7 Jan 2015 15:59:43 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150107145943.GE13482@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ey4sOiPokQJumQSjH3Lds7MzAJE Subject: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:00:10 -0000 The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. Please speak up by Wednesday 2015-01-14 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 7 07:02:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85B1A90B5 for ; Wed, 7 Jan 2015 07:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9wAvS9x4cXF for ; Wed, 7 Jan 2015 07:02:28 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D191A8828 for ; Wed, 7 Jan 2015 07:02:28 -0800 (PST) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 15:02:27 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.245]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.245]) with mapi id 15.01.0049.002; Wed, 7 Jan 2015 15:02:27 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 Thread-Index: AQHQKorzyOT8EqJPYEqnPzaeHodUCg== Date: Wed, 7 Jan 2015 15:02:27 +0000 Message-ID: References: <20150106212118.GB11692@elstar.local> In-Reply-To: <20150106212118.GB11692@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BN1PR05MB456; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB456; x-forefront-prvs: 044968D9E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(46102003)(99286002)(107886001)(68736005)(107046002)(76176999)(54356999)(50986999)(36756003)(20776003)(64706001)(2900100001)(105586002)(21056001)(102836002)(66066001)(83506001)(2950100001)(106356001)(106116001)(2656002)(99396003)(62966003)(77156002)(2501002)(40100003)(230783001)(122556002)(97736003)(4396001)(120916001)(31966008)(87936001)(86362001)(92566001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <3E5B341C522D3349990DDCF75C389A03@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2015 15:02:27.0408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB456 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IGPmMFGPId9emhjCr2rqoVP3qMY Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 15:02:30 -0000 > - who believes a mechanism to define metadata annotations > should be standardized Not yet. =20 First I think we need to clear the way for attributes to be used safely. We used attributes in and also with-defaults, but in both cases the client either accepted the contract of the protocol (base:1.1) or explicitly opted into receiving the attributes (report-all-tagged). Specifically, what happens to a legacy client if the attribute MUST be semantically understood (e.g., the enabled/inactive) in order to correctly process the data? Even if we don't care about the client, we might want to assert that the client will always echo back any attributes it receives on config=3Dtrue nodes - this might require a base:1.2 for NETCONF, I'm not sure how to do this for RESTCONF. Perhaps I'm conflating what and how, but it seems that we're skipping a step. > - who plans to use the proposed annotation extension statement As proposed, I don't see how it can be used. Specially, I'd need to see more examples around how to declare where attributes can be used. For instance, how to specify that the "default" and "enabled" parameter can only appear on config=3Dtrue nodes or a "last-sampled-timesamp" can show up only on specific config=3Dfalse nodes? Or that a "timestamp" or "Etag" attribute MUST be on top-level config node and MAY be on other config nodes (yes, I know that RESTCONF uses HTTP headers for this, but a similar mechanic may be desired for NETCONF). Note that as long as attributes are cross-cutting (applying to all config nodes generically), then they'll likely only be used for "metadata". But, if we introduce the ability for attributes to be used on specific nodes (top-level node, or specific config=3Dfalse node), then we open the door to attributes being used for regular data (not just metadata), which I don't think we want... > - who is willing to review the document during the WG phase I will, if it is promoted to a WG item. Thanks, Kent From nobody Wed Jan 7 08:46:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA9D1A0097 for ; Wed, 7 Jan 2015 08:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRSsRND5aiUp for ; Wed, 7 Jan 2015 08:46: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 298511A00A3 for ; Wed, 7 Jan 2015 08:46:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E5817708 for ; Wed, 7 Jan 2015 17:45:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id j1CrpC0JGOAN for ; Wed, 7 Jan 2015 17:45:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 7 Jan 2015 17:45:59 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3175320034 for ; Wed, 7 Jan 2015 17:45:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F4UXYUSLSkBc; Wed, 7 Jan 2015 17:45: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 D032120017; Wed, 7 Jan 2015 17:45:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 970893051336; Wed, 7 Jan 2015 17:45:59 +0100 (CET) Date: Wed, 7 Jan 2015 17:45:59 +0100 From: Juergen Schoenwaelder To: "netmod@ietf.org" Message-ID: <20150107164559.GA13878@elstar.local> Mail-Followup-To: "netmod@ietf.org" References: <20150102.173921.2068884682648761059.mbj@tail-f.com> <20150104.110916.325563256712417030.mbj@tail-f.com> <70150F84-5C10-42D8-BF78-76E0A3CF0F6C@nic.cz> <3C23ED6B-9790-4582-AC57-EE75D67041F2@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C23ED6B-9790-4582-AC57-EE75D67041F2@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/22XgBzVh-KNGRQ5_IgL2Nx7qJfI Subject: Re: [netmod] Y07: do not allow when or if-feature on key X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:46:03 -0000 Hi, we briefly discussed Y07 during the virtual interim meeting today and I have re-read this email thread as well. The original proposal was to adopt Y07-01 and this was verified on the mailing list. Make "if-feature" and "when" illegal on leafs that are key, unless the condition matches the condition on the parent. I think the intention here was to be able to detect "if-feature" and "when" statements on key leafs that are different from the parent's restriction at compile time. Martin then figured out that it is not easy to decide this at compile time in the general case for when statements. It seems a number of options have meanwhile surfaced: a) Make if-feature and when statements on key leafs illegal since they can at best provide redundant information (and a compiler can easily detect the presense of these statements for key leafs and abort with an error). (Y07-02) b) Ignore if-feature and when statements on key leafs (the idea is to make it easier to reuse groupings that may have if-feature / when constraints inside). (Y07-03) c) Make if-feature and when statements on key leafs illegal if the condition does not match the condition of the parent. (Y07-01) As explained above, this requires to be able to determine whether conditions are equal, which is difficult at compile-time for when expressions. d) Do not do anything about this in YANG 1.1 but add text to the guidelines document explaining why if-feature and when statements on key leafs can be problematic, encouraging tools to warn about them. (Y07-04) During today's meeting, there was a movement towards d). Please let me know if that works for you. Also let the WG know if you think one of the other options is the way to go or there is yet another option to consider. /js PS: I might add a), b), and d) as possible solutions to the issues list -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 7 08:56:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74311A0055 for ; Wed, 7 Jan 2015 08:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCIOGUYysoD4 for ; Wed, 7 Jan 2015 08:56:13 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53161A0012 for ; Wed, 7 Jan 2015 08:56:12 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so1426469lbv.7 for ; Wed, 07 Jan 2015 08:56:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=nhV33bXv8t7vW0fePIVgF/yMHLcEQyU6+he+ePv6kCs=; b=KC27FV4+COMF5BIYAYifHgq8XEvJFS4qKFFymZDXeuB57qF/iUy0q6G7kz7ISTp2k3 Uj24uER2ymdEINnrXaqkGMGY7HvEHFcfOz1wcwDjVUAqDCvyTZwQb8rXI5cA8s83GjkD 70lJYh6r0N94wwZeZwDy7XBcxebEgQx7AaHo5P24TYGO40jSopU703CBAr4QFam+sGTT UG4VOCajLJoKSslyYVPoPiBbP3OVrSFP6iz4iQKIj9m/HJu4s84afBkX034ZLEX6ejYz YQcBCzUPYCEbKO+IU9PrAVNX5E1idsi5I36LswCYehNp9Umkqxc9OQmGyLTi3gc0sXDw /KVA== X-Gm-Message-State: ALoCoQmgGpkrRowxZBRevdzo2cVVxBmIABv/rdEyTw72xVY7TKcZYk0RKATPdN4quSwRCZUGf6yC MIME-Version: 1.0 X-Received: by 10.112.156.132 with SMTP id we4mr6173004lbb.59.1420649768852; Wed, 07 Jan 2015 08:56:08 -0800 (PST) Received: by 10.112.77.231 with HTTP; Wed, 7 Jan 2015 08:56:08 -0800 (PST) In-Reply-To: References: <20150107143216.GA13482@elstar.local> Date: Wed, 7 Jan 2015 08:56:08 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tSbEmwlDQ2kwZBF5snrFUey8eNo Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 16:56:15 -0000 Hi, There is a difference between backward compatibility at compile-time and run-time. The former means that a YANG 1.0 module still compiles OK if parsed as if it were a 1.1 module. The latter means a YANG 1.0 module still behaves the same within a 1.1 server implementation. Both are required. There is a solution to fix Y09-3. Add a new statement instead of redefining key-stmt. Was this considered? What if the designer does not want a list to automatically instantiate entries? How is this accomplished? typedef X { type int32; default 42; } list broken { key x; leaf x { type X; } leaf y { type string; mandatory true; } } Does the server automatically create a default entry for x=42? If so, then isn't the mandatory-stmt violated immediately? Are must-stmts in the default key leaf evaluated? Are requests for list "broken" allowed to omit the leaf? Is the server supposed to fill in x=42 in such cases? Seems like "key" 1.0 needs to be preserved, even if "key2" is added. This would also prevent YANG 1.0 lists from magically changing run-time behavior. Andy On Wed, Jan 7, 2015 at 6:58 AM, Andy Bierman wrote: > Hi, > > I object to Y09-3. > In YANG 1.0 a default on a key leaf is ignored. > The exact same module parsed as YANG 1.1 does not ignore the > default on a key leaf. Providing 1 leaf is supposed to be an error > and all of a sudden it is not and creates an entry with the automatic key. > This is not what the YANG 1.0 client is expecting. > > Also, when defaults are suppressed in or replies, > do the key leafs that match defaults get suppressed? This would also > break a YANG 1.0 client. > > > Andy > > > On Wed, Jan 7, 2015 at 6:32 AM, Juergen Schoenwaelder > wrote: >> The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. >> Please speak up by Wednesday 2015-01-14 if you disagree with this >> proposal. >> >> For more details, see the issues list and the virtual interim meeting >> minutes available here: >> >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jan 7 13:03:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AA91A1B9C for ; Wed, 7 Jan 2015 13:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M9twjpAoWUA for ; Wed, 7 Jan 2015 13:03:52 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 390961A1B85 for ; Wed, 7 Jan 2015 13:03:51 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA21911 for ; Wed, 7 Jan 2015 16:03:50 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t07L3plR059884 for ; Wed, 7 Jan 2015 16:03:51 -0500 (EST) (envelope-from reid@snmp.com) Message-Id: <201501072103.t07L3plR059884@mainfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Wed, 07 Jan 2015 15:32:16 +0100. <20150107143216.GA13482@elstar.local> Date: Wed, 07 Jan 2015 16:03:51 -0500 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-h8yHpGeEwhQFsVl27VJiNwehfE Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 21:03:55 -0000 > The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. > Please speak up by Wednesday 2015-01-14 if you disagree with this > proposal. I prefer to NOT introduce optional keys. If we do add them, I think -03 is the best solution. -David Reid From nobody Wed Jan 7 13:08:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3231A1BD7 for ; Wed, 7 Jan 2015 13:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yMLCBOHYMdH for ; Wed, 7 Jan 2015 13:08:13 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950041A039D for ; Wed, 7 Jan 2015 13:08:12 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so5908584lam.5 for ; Wed, 07 Jan 2015 13:08:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ohsqiSRM+LxPtwQlAlx9peDLSYYx4UEgZQBgZE6Xc8c=; b=Ap+QErfsK681wMiDKpCuW0qhaj75Ql4sWCoqnA6fpe98hED/aPaIocd3Y60uUkL1tC jd8leCMvcGNskBy08qkGkLRfpS8w1gHhfGoT7Hw34wxEAT7n3i6bzjhejruGds3svUcY 77VJ9SuUGEE8ZiSrBB6YbsEbb0gPGfXrzsTYq475fsfJ2T5ouvh4q3qqEbeJzB0edITy iOtnQEWNQkpC1Pt2zFs91YDy+m5WnnirSNgQ5Ws9KpCxgAVvhc5jeRTZG2npXXC/knzF g+y4eA+QJ2lZ78j7ZJcpy3jpId4TGDNPCnEfLLGw630D6RaFoW1CrrwoRsTY79K6fdLh xfMw== X-Gm-Message-State: ALoCoQlwouvhRsn7uzLW12uHddHbbirIk0l1dY5v+0BafowxbBbdZ9J3dgTAvBvs/vzmr63+rV8M MIME-Version: 1.0 X-Received: by 10.152.27.130 with SMTP id t2mr8229617lag.28.1420664891017; Wed, 07 Jan 2015 13:08:11 -0800 (PST) Received: by 10.112.77.231 with HTTP; Wed, 7 Jan 2015 13:08:10 -0800 (PST) Date: Wed, 7 Jan 2015 13:08:10 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/x_xGcNJrMqbCDrsuCTrbOZRBqis Subject: [netmod] Y45: conformance-stmt proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 21:08:15 -0000 Hi, I hope we can resolve this issue on the mailing list, since it was skipped in the interim meeting. IMO import-by-revision is fatally flawed. The problem with representing the conformance dependency chain in the import-stmt is that not every module is using import-by-revision, and if A.1 imports B.1 and B.1 imports C.any, then the dependency chain for module A.1 is not deterministic. import-by-revision everywhere is going to be unmanageable, even if all the effort to update every YANG module in existence was made. Instead, a conformance-stmt much simpler than the SMIv2 MODULE-COMPLIANCE macro is needed: module foo { ... import ietf-yang-types { prefix yang; } import ietf-inet-types { prefix inet; } import ietf-interfaces { prefix if; } revision 2014-01-05; .... conformance 2014-01-05 { module ietf-inet-types@2013-07-15; module ietf-yang-types@2013-07-15; module ietf-interfaces@2014-05-08; } } Tools can generate this stmt or can be fairly easily generated by hand. Import-by-revision would no longer be used. There would be 1 or more conformance-stmts in descending date order, like the revision-stmt history. Andy From nobody Wed Jan 7 17:08:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F0C1A87A6; Wed, 7 Jan 2015 17:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.323 X-Spam-Level: X-Spam-Status: No, score=-94.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_46=0.256, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiv6feWjGsTE; Wed, 7 Jan 2015 17:08:10 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CB2051A8790; Wed, 7 Jan 2015 17:08:09 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 24A2786867C0; Thu, 8 Jan 2015 09:08:07 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 8265934135F48; Thu, 8 Jan 2015 09:08:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t081803w074663; Thu, 8 Jan 2015 09:08:00 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20150107143343.GB13482@elstar.local> References: <20150107143343.GB13482@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-KeepSent: 564401B9:F6EE8AA1-48257DC7:0005F682; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Thu, 8 Jan 2015 09:08:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-01-08 09:08:00, Serialize complete at 2015-01-08 09:08:00 Content-Type: multipart/related; boundary="=_related 000639E648257DC7_=" X-MAIL: mse01.zte.com.cn t081803w074663 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bpSL_PgYiyDLk0quE-g4ae9HSGM Cc: netmod , netmod@ietf.org Subject: [netmod] =?gb2312?b?tPC4tDogIFZSRlkgOlkxNjogbW9kdWxlIGFkdmVydGlz?= =?gb2312?b?ZW1lbnQgb3B0aW1pemF0aW9u?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:08:14 -0000 This is a multipart message in MIME format. --=_related 000639E648257DC7_= Content-Type: multipart/alternative; boundary="=_alternative 000639EA48257DC7_=" --=_alternative 000639EA48257DC7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCiAgICAgICAgV2h5IG5vdCB1c2UgZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5j LTAwID8gSXQncyB2ZXJ5IHNpbWlsYXIgDQp3aXRoIFkxNi0wMy4NCg0KICAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZyYW5rLW5ldGNvbmYtY29uZm9ybWFuY2Uv DQoNCg0KDQoNCkZyYW5rIEZlbmcgICC367PlDQpCTiBQcm9kdWN0IFRlYW0NCkJOsvrGt83FttMN Cg0KQWRkOiBaVEUgQ29ycG9yYXRpb24sIDUwIFNvZnR3YXJlIEF2ZW51ZSwgWXVIdWFUYWkgRGlz dHJpY3QsIE5hbmppbmcsIFAuUi4gDQpDaGluYSwyMTAwMTINCsTPvqnK0NPqu6jMqMf4yO28/rTz tcA1MLrF1tDQy82o0bYNCk1wOis4Ni0xODkxMzg1MjYxMg0KRS1tYWlsOiBmZW5nLmNob25nMzNA enRlLmNvbS5jbg0KDQoNCg0KDQoNCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiANCreivP7IyzogICJuZXRtb2QiIDxuZXRtb2QtYm91 bmNlc0BpZXRmLm9yZz4NCjIwMTUtMDEtMDcgMjI6MzMNCsfrtPC4tCC4+A0KSnVlcmdlbiBTY2hv ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQoNCg0KytW8 /sjLDQpuZXRtb2RAaWV0Zi5vcmcsIA0Ks63LzQ0KDQrW98ziDQpbbmV0bW9kXSBWUkZZIDpZMTY6 IG1vZHVsZSBhZHZlcnRpc2VtZW50IG9wdGltaXphdGlvbg0KDQoNCg0KDQoNCg0KVGhlIDIwMTQt MTItMDMgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgcHJvcG9zYWwgaXMgdG8gYWRvcHQgWTE2LTAz Lg0KUGxlYXNlIHNwZWFrIHVwIGJ5IFdlZG5lc2RheSAyMDE1LTAxLTE0IGlmIHlvdSBkaXNhZ3Jl ZSB3aXRoIHRoaXMNCnByb3Bvc2FsLg0KDQpGb3IgbW9yZSBkZXRhaWxzLCBzZWUgdGhlIGlzc3Vl cyBsaXN0IGFuZCB0aGUgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcNCm1pbnV0ZXMgYXZhaWxhYmxl IGhlcmU6DQoNCiAgICAgaHR0cDovL3N2bi50b29scy5pZXRmLm9yZy9zdm4vd2cvbmV0bW9kL3lh bmctMS4xLw0KDQovanMNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCkZheDogICArNDkgNDIx IDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1h aWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAg SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2Yg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBu b3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVu dCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFu ZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4g IElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJl cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg bm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 000639EA48257DC7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdo eQ0Kbm90IHVzZSBkcmFmdC1mcmFuay1uZXRjb25mLWNvbmZvcm1hbmMtMDAgPyBJdCdzIHZlcnkg c2ltaWxhciB3aXRoIFkxNi0wMy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGEgaHJlZj0i aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mcmFuay1uZXRjb25mLWNvbmZv cm1hbmNlLyI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS88L2ZvbnQ+PC9h Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8 dHI+DQo8dGQ+PGltZyBzcmM9Y2lkOl8yXzEwRDlCOTM4MTBEOUI1NjQwMDA2MzlFNTQ4MjU3REM3 Pg0KPHRkPjxmb250IHNpemU9MT48YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+PGZv bnQgc2l6ZT00IGZhY2U9Is6iyO3RxbraIj48Yj5GcmFuayBGZW5nICZuYnNwOyC367PlPC9iPjwv Zm9udD4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPTIgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+ PGI+Qk4gUHJvZHVjdCBUZWFtPC9iPjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzVmNWY1ZiBm YWNlPSLOosjt0cW62iI+PGI+PGJyPg0KQk6y+sa3zcW20zwvYj48L2ZvbnQ+DQo8dHI+DQo8dGQ+ PGltZyBzcmM9Y2lkOl8yXzEwRDlEMDdDMTBEOUNDQTgwMDA2MzlFNTQ4MjU3REM3Pg0KPHRyPg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+QWRkOiBaVEUgQ29ycG9yYXRpb24sIDUwIFNv ZnR3YXJlIEF2ZW51ZSwNCll1SHVhVGFpIERpc3RyaWN0LCBOYW5qaW5nLCBQLlIuIENoaW5hLDIx MDAxMjxicj4NCsTPvqnK0NPqu6jMqMf4yO28/rTztcA1MLrF1tDQy82o0bY8YnI+DQpNcDorODYt MTg5MTM4NTI2MTI8YnI+DQpFLW1haWw6IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPC9mb250Pjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48Yj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7JnF1b3Q7bmV0bW9kJnF1b3Q7DQombHQ7 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjIwMTUtMDEtMDcgMjI6MzM8L2ZvbnQ+DQo8dGFibGUgYm9yZGVyPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgYmdjb2xvcj13aGl0ZT4NCjxkaXYgYWxpZ249Y2VudGVyPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7H67TwuLQguPg8YnI+DQpKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8L2ZvbnQ+ PC9kaXY+PC90YWJsZT4NCjxicj4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj5uZXRtb2RAaWV0Zi5vcmcsIDwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W25ldG1vZF0gVlJGWSA6WTE2OiBtb2R1 bGUgYWR2ZXJ0aXNlbWVudA0Kb3B0aW1pemF0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGUgMjAxNC0xMi0wMyB2aXJ0dWFsIGlu dGVyaW0gbWVldGluZyBwcm9wb3NhbCBpcw0KdG8gYWRvcHQgWTE2LTAzLjxicj4NClBsZWFzZSBz cGVhayB1cCBieSBXZWRuZXNkYXkgMjAxNS0wMS0xNCBpZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGlz PGJyPg0KcHJvcG9zYWwuPGJyPg0KPGJyPg0KRm9yIG1vcmUgZGV0YWlscywgc2VlIHRoZSBpc3N1 ZXMgbGlzdCBhbmQgdGhlIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nPGJyPg0KbWludXRlcyBhdmFp bGFibGUgaGVyZTo8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PC90dD48YSBocmVm PSJodHRwOi8vc3ZuLnRvb2xzLmlldGYub3JnL3N2bi93Zy9uZXRtb2QveWFuZy0xLjEvIj48dHQ+ PGZvbnQgc2l6ZT0yPmh0dHA6Ly9zdm4udG9vbHMuaWV0Zi5vcmcvc3ZuL3dnL25ldG1vZC95YW5n LTEuMS88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQovanM8YnI+ DQo8YnI+DQotLSA8YnI+DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eQ0KQnJlbWVuIGdHbWJIPGJyPg0KUGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBS aW5nIDEsIDI4NzU5DQpCcmVtZW4sIEdlcm1hbnk8YnI+DQpGYXg6ICZuYnNwOyArNDkgNDIxIDIw MCAzMTAzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PC9mb250PjwvdHQ+PGEgaHJl Zj0iaHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iPjx0dD48Zm9udCBzaXplPTI+aHR0 cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KbmV0bW9kQGlldGYub3Jn PGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0K PC9mb250PjwvdHQ+DQo8YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBw cml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVz aXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQg cmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Ig b3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGlu IGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwv Zm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl IHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVj aXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3Ro ZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9u dD48L3ByZT48YnI+DQo= --=_alternative 000639EA48257DC7_=-- --=_related 000639E648257DC7_= Content-Type: image/jpeg Content-ID: <_2_10D9B93810D9B564000639E548257DC7> Content-Transfer-Encoding: base64 /9j/4R9rRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBXaW5kb3dzADIwMTQ6MDg6MTIgMTY6Mzc6 MDAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAoKADAAQAAAABAAAAxgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAAB41AAAAAAAAAEgAAAABAAAASAAAAAH/2P/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSA AAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAoACBAwEiAAIRAQMRAf/dAAQACf/EAT8AAAEF AQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAAB BAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHx Y3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm 9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS 0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9VSSSSUpJJDvvqoZvsMA kNaAJJcfosY0e5zklEgCzokQbMljZDGuuePzKxJn93c7bWz+29QbXff7sj9Gz82hp1j/AIaxv0v+ Lr/R/wDGoll2PjtAcQwD6LR/BrU4DWvmPgtMtL+Udy4lnXuou6uzpLqqen2WMFjLLybg+fo1sZUc dnqaP/w62KactoHrZAsPfZWGD7nOtd/01k9YZ0/qtIqvqMs1qvBAew+LIn/MVWjrXVOnsFOaRk0N 0ZmNBLgP+7DJ3f2//PqnOIyiOGIif0on/pRl/wBy0/vAxzl7sjOBNxyDaP8AVyQjw/8Ahj0oa8fn z8QFJ0x7RJ8DosZnXHlocPTsYeHCdfxVirrmM4xaDX5j3D8Pd/0VGcGQfo35M8eZxH9Kr7/xdAPH DgWnz/vUlCuyq5m+twsYe4MhRc19fur9ze9Z/wDRbio66bM16XuPBKkoVW13Viys7mu+XGha4H6L m/nNU0Eg3qFJJJJKUkkkkp//0PVUkkklIcvKow8a3KyHbKqWl73eQ8P5TvzVCih7njJyB+nIhjOR W0/mM/l/6Wz8/wD4tZ/1optyuh5zK/zGBzR4ljm22H+y1iQ65VlYmPbUQG2s9XIM6MaP52r+vv8A Z/6sUscZMQY7kmMvAU155oxyGM9BGInH+seKUZf4nobOZ1JrBtqPJjfzx9LZ/V/eWPkZQbvdu3bf pk8jzcqXWeosJF2Md9Fg2NPG17R7qnN/M/fWPl5toyfUa8tcQ14j+U1rz/1Sv4OV0B2vu5fN/EPU QPVRG3y1L9KLp3dXY36Jn4Kq/qz3fR9p8+Cs59ld+tYFd3evhrv+K/dd/wAF/wBtqq66DB0I0IVy OGA6a+Lnzz55H5tP6rpDNex5IGyeQ3T8PoqYzMh2tTvUjlvDh/ZWR9oPB1HgU/rDlroI4kwfk5OM I9h+xi4Mn6MiPB2sbrmZiWG2l+14+kOxj82xn5y7HofX8fqtewxVlsE2Uzz/AC6v3mf9QvPqbLbx +sVF1fe8+zaPE2Ha16NtsxiLsR7hY3VjmO9wkbXPa5nu7qvzHL48gquGf6Mh/wB0z8p8Ry8vk4ZE zh+lAmx/gy/Rk9/gWGzM6h6UGmu4NBB0L9jPtDP7D/8Awb1VoAgiQsv6s5+HmdJq+y1to9H9HbQ2 YY8au+l7nepu9Xf/AOjFfLzXktYfoXA7fJ7dSP7bP/PayckSJyiRRjpr/VelwyBxxkDYn6rG3rP8 oJkkklGyqSSSSU//0fVVF7i1hI1PYefZSVLqozn0MowLRRkXWNaL3N3hjRNlr/TPte7YzYz+ujEW QNvNbI1EmifAbp77KsXFsss1rqYXOnuANf8AOXnpe+ltuPUQym8tsNY/Nn3MZP8Ar/g1q9f6OMDE ruys/JzLbLNrvUf7IAc87a/d+c1v5yw8dwcJBmDB+K0uUxCMDMHi4jvWnpee+Mczk4ow4PbMB+9x S/Wb3w/1UuPU5u5ljt1FwDbWRB0+hYw/6Wp30P8Atv8APWb1FxpvFbyJaxg3djA27m/ctdqDm5oo 201ub67wS0PAc0R9Fj/3PW/MVqMzxXvblYM+SRGLhE9yL9PDXq+b91w2+rdpVW6z+qCR/nfRU3xx l3VVOHB3h9n9V1WP6rnf21Kz6yXlprtqqc0aFj2GAR2LN6G3rdbjtb0/FM+Fe3TxKk4pdm4MWfrj AH9WceL/ABp8P/QWf9lpgu9XI3fRc3bVWf6rz61jkvt4pP6Kuqp/8lvqOHxuyN/v/qMT/tfCbIb0 /H930y3c0E/yfapU29GubuHT2ADRwFjxB/kwhZPQp4SBeTFOQ/vYiD5w9yMP+ajbmvufNznPA7vc SZ8E1dvu31OIdyI0cEYO6V6gacB1bWk7XDIdB/qtd9LcoPt6DU7aabtw7C0mPmjddCF136RinVbD 2tv8HI7P1e63nYucwUNYbMktrcH+1th19Ntn7j93trtW0z66Pu6nj/aaWU4TbJ3AkvbuY+nfY72s dXus3v8AYuQGZgQPRxnkmNu58kn81W82i2kN9Zjmes0PrkEbmu7s/eVfJhxzlZjRI4V8OYz4RGMB OGMS4uGXCY/ZHi4YvqdF1eRTXfUd1drQ9jh3a4bmlEVHowzG9Pqqza21X0gVuDNGENA2OYPzfZ+Z ++ryx5CiR2L0kDxRBOljyUkkkguf/9L1VRP0h8CpKl1VtlmL6Nbix2Q9tLrGmHNY9wba5h/f9Lds RiLIHdEjUSd66PKfXLqdeZ9n9BrnY1b7Wtv4ZY9uxtno/nPrp+h6383v/m1yz8u2pwcHlpbw1ujR 8Qu0+veLVT03CsY306saz0mMYIAa5nsa391rfRauBtydn80xrT+8fc7/AKS2eT4TgjWw4h/znnuf xH71PiHGZCP935W3X1PqljgGEBk62GsbQB4/vI+VjYnWA9tL24/UGa2VkyHNH5z2/S/t/Tr/AMIs N2TeXm02OLmDQk9z7WqFQcx7bi5zbAd7HAw8n9/f+apzEdNCwfdqInAjFOI9PBHc/u5P34Oi7Bbq 3KZuyI22WEFrtPbv5/d/wn+EVMGnbtbWS3uXOjd5u2BbFGfR1KtuN1A+jkD+ayWe0E9v5LHf8G/9 FYq2Z027Gs97RqdHN+i7+Uz9x379SIl0Io/msx5SJGGS4z3Eb9P97H/V/wCg0QY+jWxv9ncf+nuR G22M0d7/AB7AHwbtRBXt/rfkTigmO06Dz/qt+k5OZDIHpbVeG2EmwBr+zx+R4/7+l9jufc2tlZtt t1ZW3Wf3nOP5jP6y0DhNph2U80A6hgAde4fyavo0f17kK7JJpdj0s9DGP06wSXv87r/pP/qfzSbv t9qY5v8AN+rxP83Hy/f/AMH/AMba5uZghzKbBflukPvbrXUOCzF/0l37+R+Z/gV6t9UYt+rHTHPA cW0t2k6xt9rTqvIrKSGkt1aB8IXs/wBXsU4nQun4zhDq8eoOH8ra0v8A+kqPxHSEB1Mv2On8NA4p n5iQOIlvDl3+vZSUW8k+akst1FJJJJKf/9P1VReJbxJGoB8RqpJJKcz6x9PPU+iZWNWN1rmb6Y7v YfVrA/rubsXjltkifHsvdG6Es+bfgvLvrz0F3SeqHNoZ+p5zi9h7MuMvto/k+p7shn/XKq/5taHw /MAZYifm9Uf+6aHP4eLhygWY+mXk846v0SGOh1n0nDkNJ+ju/e2qTGkmTqTySoV1k6kjzcSIn4q9 RiFw3SC0cu+i0f1rHrSsOXM8I1PmWDK50iZ7crY6Zdc79Tui6og6OklscN3D83+uq1Yx6xDW+ue8 Haz/ANK2f9BF332N2H21/wCjYNrf81v0v7SRHEK/Fo5zxgjh8pS04T+9H9L/AKDbf0vHEvDnNiSR AJgaw0uVIZBAP2VookavHutI87XfR/62reK3JaZrkgctJO2Pn9FPkYldgNtAAs7tEFpP/Uf5qA9J qR4vH/vmCJmP5wmcf0Zfof4blOq5Pc6k8koL2Qrr6njSxorJ4jv/AGkGysCfyqRsxnrqv0Xpp6j1 fFwQJrteDd/xTP0l3/Qbs/tr2AmBJ7LlvqN0J2HjO6nkNjIy2gVNPLaZ3a/yr3fpP6npLp3GXBkS Bq4/9SsbnswyZeEfLj0/wv0no+QwnHhuQ9WT1fT9Fk0ENE89/inSSVNuKSSSSU//1PVUkkklMXhx b7fpjVs8T/K/krHu6HldTw343V851zLY9aimuplYIO8Cv1a7sj9G7+bs9XetpRc3WW6O/L5FOjMx 20Pelk4CW9+QJj/0XyXqvSbug9QtpuDLqgWtrvYCZD9zqmXbi6vHu2Vu/Rf4T/B+xVXXMtcJYdrf ojdEf2W+1eqNw6HX5uPmVNsq6g5tu14Dmu2110PqM/6P7P6v9v8AkLneqf4vWAm3o9oZOv2a8kj/ AK1f7nt/q2+p/wAatPBzsCQMp4ZUPX+jJyOY+HSJOTEOLU+i/VH92v8ABeTr9L91w+YP/fVboYHE BsgnxAP5E9/ROr4ZIyMS5gHL2jez/tyn1GqOOQ14Jc5sHXWD+KvCQlG4S4vI8TkZccoGpiUf7w/7 56LA6c8gE4/r+G61v/nt4bWr2RiWOqIsw7dsfmuqdx+7tsVbplpIAqzbQ790Cuz/AKJrWk9vVC3a yxto/wCFx3NP+djv/wDRazcs5CepH143Zw4ccsVAyIIqqw8P/R4njLbGPBDhI8D/ABWn0X6v3OvZ l5uHffiiH00ez3nsbvXtq/Qt/wBG/wDnv+K+nqZ3Qr8nEtLMM25djdLLHNqY0z9OljXWWvd/4ZRf qtX1DP6VTk5ebY7HdLaaWAMO1hNX6TIb+nfu2/muYnZOZPtngkB+jL6/ucLX5T4ccecDJxS044aV D0/v+5/6j43Sdn9Ste6rHw212DSb7W+2eHvrxftH+b6le9aDGuawBx3Oj3OAiT47U1VVdTAypoYw cACAprOkQdgA7sIkaykZHx6f4vCpJJJNXqSSSSU//9X1VJJcXnf4zMPEzsnEODbYca2ykvD2gONb jU5wB/lNT8eKeQkQHFS2eSMBcjVvaJLhf/HVw/8Ayuu/z2Le+rf1u6b9YPUroa+jKpAdZj2xO06e pU5pc2yvd7P9a0+fLZoR4pQIA6rY5scjUZAl2rK2WN2vG4fx8R+65Aurzmsd9lsY50extwJE9psr LXf9B6w/rJ9d8boGezBsxX5D31C4uY5rQA5z62t93/Fq79WvrJi/WHEsyKK3UPps9Oyl5BI0D2P9 v5j2lD2skYDIY+g9VccJSML9fhoW1VblViMxlpcfpOqAdWD/AMH6X6zt/wCMrRRiYVzQ91Tbp1Bt Bef/AAbc5qwvrJ9d8boHUGYNmLZkPfU24uY5rQA5z62t93/FLW6D1dvWul09SZU6hlxeG1uIJ9j3 0zLf3vTSlDIIDJw8MZbEFETAyML4yNxIXJvNa1g2sAaBwAICksSz6zA2Ppxen5WRcA41thjA9rHe k6332esyn1Pz30omN9YqsjeG4mQwtrte0vFYa51JDbqfVZa9lVrXnb+m9NVvexk1xNw8pmAvhoec f+i6WTjsyaXUWE+nYNrw07SWn6TNzfd7v5KnXXXVW2utoZWwBrGNEAAaNa1o+i1qxj9aK68WvKvw shjL278dg9N731hvq23bG2/oq6a9vqet6f01Z6X1ujPxLMiyt+GccA5Db4aGgsbd6gt+g6nY7+cR GaBIiJa78KJcpliDMw0HpMgYy/6P9b/nukksav6xOddS+zDsp6bkv9OjPsc0NcTPpPdR/PVU3ub+ hts+nvp/0qi360Y7633MxrnUsZQ8Ebd5OQ+yikem57Wf4L/S/wCFYh72Pv8AgenX+6n7pn/c7bGO 8jwcJ/r8X6DtpLEH1kcWmv8AZ97csWCkUPdW0F5achzPW9TYzZjD1nep/pK1p4ORfk44tvoOM8kj 0y9tmgOjt9Jcz3IxyRkaBv6FbkwZMYuYA/wom/GMeL1R/rthJJJPYn//1vU7LGVVuteYYwFzj4AC SvBa92Vks9V4Yci0epY4gAeo/wB9jnO9rWt37l7P9askYv1b6lcf+49jB8Xj0m/9J68h6L0q3q3U qOmUvFT79wFjgXBoY11jiWtj9xaPw8CMMkyaHf8Au6tLnLM8cAL8PN6X63dN+pGJ0wP6NbWc82N2 MovdfLZ/S+q11tza2bPdv/0ij/ixwb7utXZ7QRjY1Lq32djZYWbaf8xjrH/ufo/9Is/6yfUzM+r2 LTlXZFeRVdZ6PsaWFri11jdHOfua5tb10v8Aiy61lZDMjpF8PqxWNsxnAAFrSSyyp5b9P3bX17vf /OfyE/Ia5WRhM5Qd5zOvCtgL5iPHEYyBoIvNfX3I9f615mstoFVLT/VY2x3/AIJbYp/UPrP7L69X XY6MbPjHtHYPJ/VrP7Nh9L/r6yeq2nP61mW1GftWXZ6Z8n2FlX/RLVc+t/RR0Xrl2NUCzGtAvxCD wx35rXf8Bc17P+21PwxOOOCX6UP+jwsPFL3JZhtGf5pfr3k+t9ac50yyn06m+WytheP+3XWL0z6u 1MwPqxgNscKm1YjH2vfo1pLPVue+fota5z143kWX9RzX22w6/Ntl+0QC610Ohv8AaXt2dlY/TsGX PpqAAqp+0P8ATrLo9jH2bX7fa39xU+f/AFeHFAn5Rr/gDhbfIg5Ms5AE8RAA/vPKtdl1Mc3odjci utzLcvIxMZ1e4Vu3bfXfdY7Of7v6Ox38z+j9T8xLJowrcDqnUKeo03W5gopyH1sOOaw+yut3rt9X dUy2sfpvWr3/AMtXcj633Y3pAfs7Jda8MZXj5hc7mPpOx2U1t/42xit9V+stGNS1+JVVnC5riIsA 3OY/0IY303+v722fQ/0SwiMQEryfKNvX6OL0gwjxPRXzIlD9VrOQ9XFivLwSjOUcs+D/AFfo/m/+ qPMWVYT3vrw2vtqZbc7HxqH2fpm2vrosxGvod6np5GBhfaPU/mdl/wDwi3a7Psv1KycjHufYbmPI JfY70t59D0a3X7r2Mw2/o/8Arfqqf/O6uux1bqsetzai5gNxjcHNZ6TrG0HY11X6RqLlfWZ9Gbdi Cmhwoa4Wg3ta4PFTcnc5tjWVsxd9teP69tlf6RDH7YEiMt2ODSMvRKfyqyHmJ8EThNQl7tSyxPHD H84/5/zOTZj9GqyPU6XdisOLutZcOoOsssDK3FjPs9jvSZuu2eo+yz9HUql7cNvSyzeNtjiaXQ21 r2YmMzDZ6Pr+p/PZz7a8ezH/AEtnq/olu9L+tLOo5NNFePUPVfsdF1RcGisusf6O/wBZ/wCsN2M/ R+/H/To+R1vMwsmmnqGJjsY8Gy003PtdXVXq7IfV9lr/AEbbNjGf8IiYYzEyE+GJ00jwx1T7nMQm ISxmUxHi4ZZozySjHiP6XF6uKLzZw+n1UZbHht7enUZXqSxjQLh6eFi+t6W31LXvZfbjWZO/I/wq 7jp2FVgYNGHU0NZQwMhogEge9/8AWe/3vQMbq3TcyvItx5fTQN1trq3MYSAXQHWtZ6j2NZ7tv0E/ Q87I6h0rHzchja7b2l5aydoBJ2Ru/eZtU2CEIy9MuLijYI/dj4/4rU5vLmyQ9cZQGOYEozP6eSPH H0en/Wf47fSSSVhov//X6z/GRkGn6sWVCZybqqtAToHeu7j+RSvMMHNzen5LcvCc+nIYHBtgZJAc Nr/ptc36K94XK0fWHqDLPtd+92JYzKvZU+tjA+qoudjV4VrX+pZkPZ6P9Ib6T6/Vs9itYObGLGYe 3xWSTr38OFr5uXOSYnx8NbUHzzJyPrH157HXDK6g6uRW1tbnBs/S2sqZsbu2+5y736p9ByPqz0TO 6hnANzbaza+sEO9Oulr31VbmfSs3OsfZs/74tav6xP8AXNV+I6sVP9LJsa7eyt/p/af53Yyl1VVW z7Ra6yv0bf8AtxVb/rVY1tbjQ6jbkV12NHv3NspsyGVh1gobW/f6DLrnfqtXq+r9pexLLzhnHgEB CF6xH5Kx8sISMjIynXzF81+q+M/J6/0yosJnIre8EGIYfXf/ANQvQf8AGP0Y53Rhn1N3X9OJsMcm l2mQP7EMv/60rd/XupMy7GNprLaLLC5geBNVGOy3J33Pb7dmZl0s9Rrf8H6f/CKwPrFbZkfZ6MJz 3WOFdG+xrC54qZlX72w/0qcdlnpWW/pP1j9H6f56WTnJTywyCPDwdLu/3lQ5YRhKBN8fg+W/VfFf k/WPptQaf6Qywy0xFX6w/n+TUvVvrAMnKoHTMWvc7Ka717Xe2tlI/nQ+2HbX5E+hX7fz7Lf8Eh1/ WfGsxm5XpOZS40jc4jT1a/tlv0d39Fxf0r9n85/gkJ3XuoX2VUUYno5D7KCGOe1wNVrcjILbHtn0 LW04jvW+n9P9D6yi5vMeYrTgFcOhtl5SH3c2PWQeIXp6v0f8V5+ro+d1HDzcqhvq47mBjfeZtbS3 1W1srdhY78ljrP0Vf9E/66rnXMcXZeNdj4loq2Y9GPX6b2sY07rXOo9G+lrXtps9D0/Tr/c3rq+n 5gzsGjMDDX69bbNjiCW7hO2R9JWFQ+6DhMeI6/Mf8b/vnSPxGfGJcFCN8I4uhEY+r/wt5RmPn05X StlT8LGbvofkBrrHn7Q5mW+r0rX5V2Kz1Kfs/r3Xex9n+DZ6azLcI512Za/Hsd6pdZsbTY2wevcx 7abrKqr3u9TAx2We+n06N/p2LvkkZcrxacZr/wBB4UQ+ISib4PV+8Dr85yS4j6perieS6VWf2x9t yKbrH4OI8saQXWMk+yjb9lwPfbV6noUfpf8ArabG6liOpuzLMx+L1fNLTZcMay30a2mWYVTbKfT2 MZ/OO/Pv9S5dckiMEgKE+5Ng7y/S9M4epaecjIkmB2jEcMh8sPXwevHkjwSn6+F51+WbPq31Cy7P +1MIfU3IfjvqLd7WV+m6hjA+332fSrrW3g4rcPCx8Ruox6mVAj+Q0M/gjpKWEKNk36eHr/3UpMGT LxDhA4QZGdentwx0hDGpJJJPYn//0PVVn0dA6NQ0tpxK2tLQzbEgNa5trWNB+iz1GMfsatBJJTSt 6P0u66y+3GY+y5pbYXCQ7c30nuLPoeo+r9E63+c9L9Gmb0XpTWPZ9mY4Wh7bS+Xl4sa2i31X2Fz7 PUpqrq9/+DV5JJTTd0vpjfXsdQyLmPbeTrLHhjb26/m2tpr9X/SbFh4+b0zNxcenPwCTa5lt1tbd tTLcqp+Y73+r6/8AMO25W32fpP0n6JdLdSy+mymwTXa0seASDDhtd7m+5U3dE6Y6o1GmGOcXwHOH uNH7O9sO9v6n+i/9SJKchmV0e61tlPTrqc7IZW7EAZUHxbRbXXfWx9j8Wh9OLXbTZ9o/M9On3/oq 1HpV/RcdjHspdZde+u1n6JtYaLKHDdVUHfoqsbEpuru92/1PUq/wlTFs39E6de4vcxzXlzXCxlj2 ObtZ9nit9bmuY11J9N+xNZ0HpNgcDjtAfijBIaS0DHBJbQwNPsb7vzUlOdT9ZMVmPQzCxSMep/ov aHVltdLKHZW+p1NtlVnpVsra6ttns/7a9Q4+stNWN6uTVaQyt+69jAK33UsN2Tj0Nda6zd7La2b/ ANH6tdlPrKw/6v8ATLGuFjbLC8vdY51thc82VNw7fUdv92/HYxmz/MTu6B0t9j7HVuPqFx2F79jS 97b7/Sr3bKvXtZuu9P8AnElJ8HObmesPSsofj2elYyzbMlleQ0/o3WN91V9aoXdfa36wUdLqfSWE mrIBd+l9V1b8mkVVz/NV11fp37P+1NH7ly1KManHNpqEG+w22EkmXkBs+7+Sxqr/ALI6eccYxqmt txyNXO3G0uNzrXWbt7nOe7/0X/NpKaeN9ZsbKqbZj491jrXiuitpr3PO11zw5vq/qzqWV/p2ZfoP q/R/n2KLvrb0xtr6i2wOra42NO0Oa9lX2qyl9Rs9Vrm1t2eps+z+v+h9berH/NzpW2Cyw2TJuNtn qkbfR9M5G/1vS9H9Hs3/APgil+wemRa1tbmVXNLXUtse2obtLPToa70q3WNb79jP/PliSkLevWW5 OPj04lrX2ZHo3i3aCxno/bPV9tjvzX1ez/1H6muqg6ZhjLGYGuF4e6zdud9J7GY75bu27fSpq9n8 hW0lKSSSSU//2f/tJ8ZQaG90b3Nob3AgMy4wADhCSU0EJQAAAAAAEAAAAAAAAAAAAAAAAAAAAAA4 QklNBDoAAAAAAJMAAAAQAAAAAQAAAAAAC3ByaW50T3V0cHV0AAAABQAAAABDbHJTZW51bQAAAABD bHJTAAAAAFJHQkMAAAAASW50ZWVudW0AAAAASW50ZQAAAABJbWcgAAAAAE1wQmxib29sAQAAAA9w cmludFNpeHRlZW5CaXRib29sAAAAAAtwcmludGVyTmFtZVRFWFQAAAABAAAAOEJJTQQ7AAAAAAGy AAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAASAAAAAENwdG5ib29sAAAAAABDbGJy Ym9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9vbAAAAAAATGJsc2Jvb2wA AAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAAAEJja2dPYmpjAAAAAQAA AAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRvdWJAb+AAAAAAAAAAAABC bCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAAAEJsZCBVbnRGI1JsdAAA AAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBSAAAAAAAAAAAACnZlY3RvckRhdGFib29sAQAAAABQZ1Bz ZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAAAAAAAAAAVG9wIFVudEYj Umx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAA4QklNA+0AAAAAABAASAAAAAEAAgBI AAAAAQACOEJJTQQmAAAAAAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAAB4OEJJTQQZAAAA AAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1 AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAA AAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD///////////////////////////// A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgAIOEJJTQQCAAAAAAAS AAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQwAAAAAAAJAQEBAQEBAQEBADhCSU0ELQAAAAAAAgAAOEJJ TQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAzkAAAAG AAAAAAAAAAAAAADGAAAAoAAAAAIAQgBOAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA AACgAAAAxgAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVs bAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAxgAAAABSZ2h0bG9uZwAAAKAAAAAGc2xpY2VzVmxM cwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJ RGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQA AAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAMYA AAAAUmdodGxvbmcAAACgAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNn ZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAA CGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAA AAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQA AAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0 c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAA AAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAA AAAEAAAACzhCSU0EDAAAAAAeUQAAAAEAAACBAAAAoAAAAYQAAPKAAAAeNQAYAAH/2P/tAAxBZG9i ZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEM DAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQR DAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAoACBAwEiAAIR AQMRAf/dAAQACf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAA AAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIj JBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITES BEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi 8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMR AD8A9VSSSSUpJJDvvqoZvsMAkNaAJJcfosY0e5zklEgCzokQbMljZDGuuePzKxJn93c7bWz+29Qb Xff7sj9Gz82hp1j/AIaxv0v+Lr/R/wDGoll2PjtAcQwD6LR/BrU4DWvmPgtMtL+Udy4lnXuou6uz pLqqen2WMFjLLybg+fo1sZUcdnqaP/w62KactoHrZAsPfZWGD7nOtd/01k9YZ0/qtIqvqMs1qvBA ew+LIn/MVWjrXVOnsFOaRk0N0ZmNBLgP+7DJ3f2//PqnOIyiOGIif0on/pRl/wBy0/vAxzl7sjOB NxyDaP8AVyQjw/8Ahj0oa8fnz8QFJ0x7RJ8DosZnXHlocPTsYeHCdfxVirrmM4xaDX5j3D8Pd/0V GcGQfo35M8eZxH9Kr7/xdAPHDgWnz/vUlCuyq5m+twsYe4MhRc19fur9ze9Z/wDRbio66bM16XuP BKkoVW13Viys7mu+XGha4H6Lm/nNU0Eg3qFJJJJKUkkkkp//0PVUkkklIcvKow8a3KyHbKqWl73e Q8P5TvzVCih7njJyB+nIhjORW0/mM/l/6Wz8/wD4tZ/1optyuh5zK/zGBzR4ljm22H+y1iQ65VlY mPbUQG2s9XIM6MaP52r+vv8AZ/6sUscZMQY7kmMvAU155oxyGM9BGInH+seKUZf4nobOZ1JrBtqP Jjfzx9LZ/V/eWPkZQbvdu3bfpk8jzcqXWeosJF2Md9Fg2NPG17R7qnN/M/fWPl5toyfUa8tcQ14j +U1rz/1Sv4OV0B2vu5fN/EPUQPVRG3y1L9KLp3dXY36Jn4Kq/qz3fR9p8+Cs59ld+tYFd3evhrv+ K/dd/wAF/wBtqq66DB0I0IVyOGA6a+Lnzz55H5tP6rpDNex5IGyeQ3T8PoqYzMh2tTvUjlvDh/ZW R9oPB1HgU/rDlroI4kwfk5OMI9h+xi4Mn6MiPB2sbrmZiWG2l+14+kOxj82xn5y7HofX8fqtewxV lsE2Uzz/AC6v3mf9QvPqbLbx+sVF1fe8+zaPE2Ha16NtsxiLsR7hY3VjmO9wkbXPa5nu7qvzHL48 gquGf6Mh/wB0z8p8Ry8vk4ZEzh+lAmx/gy/Rk9/gWGzM6h6UGmu4NBB0L9jPtDP7D/8Awb1VoAgi Qsv6s5+HmdJq+y1to9H9HbQ2YY8au+l7nepu9Xf/AOjFfLzXktYfoXA7fJ7dSP7bP/PayckSJyiR Rjpr/VelwyBxxkDYn6rG3rP8oJkkklGyqSSSSU//0fVVF7i1hI1PYefZSVLqozn0MowLRRkXWNaL 3N3hjRNlr/TPte7YzYz+ujEWQNvNbI1EmifAbp77KsXFsss1rqYXOnuANf8AOXnpe+ltuPUQym8t sNY/Nn3MZP8Ar/g1q9f6OMDEruys/JzLbLNrvUf7IAc87a/d+c1v5yw8dwcJBmDB+K0uUxCMDMHi 4jvWnpee+Mczk4ow4PbMB+9xS/Wb3w/1UuPU5u5ljt1FwDbWRB0+hYw/6Wp30P8Atv8APWb1Fxpv FbyJaxg3djA27m/ctdqDm5oo201ub67wS0PAc0R9Fj/3PW/MVqMzxXvblYM+SRGLhE9yL9PDXq+b 91w2+rdpVW6z+qCR/nfRU3xxl3VVOHB3h9n9V1WP6rnf21Kz6yXlprtqqc0aFj2GAR2LN6G3rdbj tb0/FM+Fe3TxKk4pdm4MWfrjAH9WceL/ABp8P/QWf9lpgu9XI3fRc3bVWf6rz61jkvt4pP6Kuqp/ 8lvqOHxuyN/v/qMT/tfCbIb0/H930y3c0E/yfapU29GubuHT2ADRwFjxB/kwhZPQp4SBeTFOQ/vY iD5w9yMP+ajbmvufNznPA7vcSZ8E1dvu31OIdyI0cEYO6V6gacB1bWk7XDIdB/qtd9LcoPt6DU7a abtw7C0mPmjddCF136RinVbD2tv8HI7P1e63nYucwUNYbMktrcH+1th19Ntn7j93trtW0z66Pu6n j/aaWU4TbJ3AkvbuY+nfY72sdXus3v8AYuQGZgQPRxnkmNu58kn81W82i2kN9Zjmes0PrkEbmu7s /eVfJhxzlZjRI4V8OYz4RGMBOGMS4uGXCY/ZHi4YvqdF1eRTXfUd1drQ9jh3a4bmlEVHowzG9Pqq za21X0gVuDNGENA2OYPzfZ+Z++ryx5CiR2L0kDxRBOljyUkkkguf/9L1VRP0h8CpKl1VtlmL6Nbi x2Q9tLrGmHNY9wba5h/f9LdsRiLIHdEjUSd66PKfXLqdeZ9n9BrnY1b7Wtv4ZY9uxtno/nPrp+h6 383v/m1yz8u2pwcHlpbw1ujR8Qu0+veLVT03CsY306saz0mMYIAa5nsa391rfRauBtydn80xrT+8 fc7/AKS2eT4TgjWw4h/znnufxH71PiHGZCP935W3X1PqljgGEBk62GsbQB4/vI+VjYnWA9tL24/U Ga2VkyHNH5z2/S/t/Tr/AMIsN2TeXm02OLmDQk9z7WqFQcx7bi5zbAd7HAw8n9/f+apzEdNCwfdq InAjFOI9PBHc/u5P34Oi7Bbq3KZuyI22WEFrtPbv5/d/wn+EVMGnbtbWS3uXOjd5u2BbFGfR1Ktu N1A+jkD+ayWe0E9v5LHf8G/9FYq2Z027Gs97RqdHN+i7+Uz9x379SIl0Io/msx5SJGGS4z3Eb9P9 7H/V/wCg0QY+jWxv9ncf+nuRG22M0d7/AB7AHwbtRBXt/rfkTigmO06Dz/qt+k5OZDIHpbVeG2Em wBr+zx+R4/7+l9jufc2tlZttt1ZW3Wf3nOP5jP6y0DhNph2U80A6hgAde4fyavo0f17kK7JJpdj0 s9DGP06wSXv87r/pP/qfzSbvt9qY5v8AN+rxP83Hy/f/AMH/AMba5uZghzKbBflukPvbrXUOCzF/ 0l37+R+Z/gV6t9UYt+rHTHPAcW0t2k6xt9rTqvIrKSGkt1aB8IXs/wBXsU4nQun4zhDq8eoOH8ra 0v8A+kqPxHSEB1Mv2On8NA4pn5iQOIlvDl3+vZSUW8k+akst1FJJJJKf/9P1VReJbxJGoB8RqpJJ Kcz6x9PPU+iZWNWN1rmb6Y7vYfVrA/rubsXjltkifHsvdG6Es+bfgvLvrz0F3SeqHNoZ+p5zi9h7 MuMvto/k+p7shn/XKq/5taHw/MAZYifm9Uf+6aHP4eLhygWY+mXk846v0SGOh1n0nDkNJ+ju/e2q TGkmTqTySoV1k6kjzcSIn4q9RiFw3SC0cu+i0f1rHrSsOXM8I1PmWDK50iZ7crY6Zdc79Tui6og6 OklscN3D83+uq1Yx6xDW+ue8Haz/ANK2f9BF332N2H21/wCjYNrf81v0v7SRHEK/Fo5zxgjh8pS0 4T+9H9L/AKDbf0vHEvDnNiSRAJgaw0uVIZBAP2VookavHutI87XfR/62reK3JaZrkgctJO2Pn9FP kYldgNtAAs7tEFpP/Uf5qA9JqR4vH/vmCJmP5wmcf0Zfof4blOq5Pc6k8koL2Qrr6njSxorJ4jv/ AGkGysCfyqRsxnrqv0Xpp6j1fFwQJrteDd/xTP0l3/Qbs/tr2AmBJ7LlvqN0J2HjO6nkNjIy2gVN PLaZ3a/yr3fpP6npLp3GXBkSBq4/9SsbnswyZeEfLj0/wv0no+QwnHhuQ9WT1fT9Fk0ENE89/inS SVNuKSSSSU//1PVUkkklMXhxb7fpjVs8T/K/krHu6HldTw343V851zLY9aimuplYIO8Cv1a7sj9G 7+bs9XetpRc3WW6O/L5FOjMx20Pelk4CW9+QJj/0XyXqvSbug9QtpuDLqgWtrvYCZD9zqmXbi6vH u2Vu/Rf4T/B+xVXXMtcJYdrfojdEf2W+1eqNw6HX5uPmVNsq6g5tu14Dmu2110PqM/6P7P6v9v8A kLneqf4vWAm3o9oZOv2a8kj/AK1f7nt/q2+p/wAatPBzsCQMp4ZUPX+jJyOY+HSJOTEOLU+i/VH9 2v8ABeTr9L91w+YP/fVboYHEBsgnxAP5E9/ROr4ZIyMS5gHL2jez/tyn1GqOOQ14Jc5sHXWD+KvC QlG4S4vI8TkZccoGpiUf7w/756LA6c8gE4/r+G61v/nt4bWr2RiWOqIsw7dsfmuqdx+7tsVbplpI AqzbQ790Cuz/AKJrWk9vVC3ayxto/wCFx3NP+djv/wDRazcs5CepH143Zw4ccsVAyIIqqw8P/R4n jLbGPBDhI8D/ABWn0X6v3OvZl5uHffiiH00ez3nsbvXtq/Qt/wBG/wDnv+K+nqZ3Qr8nEtLMM25d jdLLHNqY0z9OljXWWvd/4ZRfqtX1DP6VTk5ebY7HdLaaWAMO1hNX6TIb+nfu2/muYnZOZPtngkB+ jL6/ucLX5T4ccecDJxS044aVD0/v+5/6j43Sdn9Ste6rHw212DSb7W+2eHvrxftH+b6le9aDGuaw Bx3Oj3OAiT47U1VVdTAypoYwcACAprOkQdgA7sIkaykZHx6f4vCpJJJNXqSSSSU//9X1VJJcXnf4 zMPEzsnEODbYca2ykvD2gONbjU5wB/lNT8eKeQkQHFS2eSMBcjVvaJLhf/HVw/8Ayuu/z2Le+rf1 u6b9YPUroa+jKpAdZj2xO06epU5pc2yvd7P9a0+fLZoR4pQIA6rY5scjUZAl2rK2WN2vG4fx8R+6 5Aurzmsd9lsY50extwJE9psrLXf9B6w/rJ9d8boGezBsxX5D31C4uY5rQA5z62t93/Fq79WvrJi/ WHEsyKK3UPps9Oyl5BI0D2P9v5j2lD2skYDIY+g9VccJSML9fhoW1VblViMxlpcfpOqAdWD/AMH6 X6zt/wCMrRRiYVzQ91Tbp1BtBef/AAbc5qwvrJ9d8boHUGYNmLZkPfU24uY5rQA5z62t93/FLW6D 1dvWul09SZU6hlxeG1uIJ9j30zLf3vTSlDIIDJw8MZbEFETAyML4yNxIXJvNa1g2sAaBwAICksSz 6zA2Ppxen5WRcA41thjA9rHek6332esyn1Pz30omN9YqsjeG4mQwtrte0vFYa51JDbqfVZa9lVrX nb+m9NVvexk1xNw8pmAvhoecf+i6WTjsyaXUWE+nYNrw07SWn6TNzfd7v5KnXXXVW2utoZWwBrGN EAAaNa1o+i1qxj9aK68WvKvwshjL278dg9N731hvq23bG2/oq6a9vqet6f01Z6X1ujPxLMiyt+Gc cA5Db4aGgsbd6gt+g6nY7+cRGaBIiJa78KJcpliDMw0HpMgYy/6P9b/nukksav6xOddS+zDsp6bk v9OjPsc0NcTPpPdR/PVU3ub+hts+nvp/0qi360Y7633MxrnUsZQ8Ebd5OQ+yikem57Wf4L/S/wCF Yh72Pv8AgenX+6n7pn/c7bGO8jwcJ/r8X6DtpLEH1kcWmv8AZ97csWCkUPdW0F5achzPW9TYzZjD 1nep/pK1p4ORfk44tvoOM8kj0y9tmgOjt9Jcz3IxyRkaBv6FbkwZMYuYA/wom/GMeL1R/rthJJJP Yn//1vU7LGVVuteYYwFzj4ACSvBa92Vks9V4Yci0epY4gAeo/wB9jnO9rWt37l7P9askYv1b6lcf +49jB8Xj0m/9J68h6L0q3q3UqOmUvFT79wFjgXBoY11jiWtj9xaPw8CMMkyaHf8Au6tLnLM8cAL8 PN6X63dN+pGJ0wP6NbWc82N2MovdfLZ/S+q11tza2bPdv/0ij/ixwb7utXZ7QRjY1Lq32djZYWba f8xjrH/ufo/9Is/6yfUzM+r2LTlXZFeRVdZ6PsaWFri11jdHOfua5tb10v8Aiy61lZDMjpF8PqxW NsxnAAFrSSyyp5b9P3bX17vf/OfyE/Ia5WRhM5Qd5zOvCtgL5iPHEYyBoIvNfX3I9f615mstoFVL T/VY2x3/AIJbYp/UPrP7L69XXY6MbPjHtHYPJ/VrP7Nh9L/r6yeq2nP61mW1GftWXZ6Z8n2FlX/R LVc+t/RR0Xrl2NUCzGtAvxCDwx35rXf8Bc17P+21PwxOOOCX6UP+jwsPFL3JZhtGf5pfr3k+t9ac 50yyn06m+WytheP+3XWL0z6u1MwPqxgNscKm1YjH2vfo1pLPVue+fota5z143kWX9RzX22w6/Ntl +0QC610Ohv8AaXt2dlY/TsGXPpqAAqp+0P8ATrLo9jH2bX7fa39xU+f/AFeHFAn5Rr/gDhbfIg5M s5AE8RAA/vPKtdl1Mc3odjciutzLcvIxMZ1e4Vu3bfXfdY7Of7v6Ox38z+j9T8xLJowrcDqnUKeo 03W5gopyH1sOOaw+yut3rt9XdUy2sfpvWr3/AMtXcj633Y3pAfs7Jda8MZXj5hc7mPpOx2U1t/42 xit9V+stGNS1+JVVnC5riIsA3OY/0IY303+v722fQ/0SwiMQEryfKNvX6OL0gwjxPRXzIlD9VrOQ 9XFivLwSjOUcs+D/AFfo/m/+qPMWVYT3vrw2vtqZbc7HxqH2fpm2vrosxGvod6np5GBhfaPU/mdl /wDwi3a7Psv1KycjHufYbmPIJfY70t59D0a3X7r2Mw2/o/8Arfqqf/O6uux1bqsetzai5gNxjcHN Z6TrG0HY11X6RqLlfWZ9GbdiCmhwoa4Wg3ta4PFTcnc5tjWVsxd9teP69tlf6RDH7YEiMt2ODSMv RKfyqyHmJ8EThNQl7tSyxPHDH84/5/zOTZj9GqyPU6XdisOLutZcOoOsssDK3FjPs9jvSZuu2eo+ yz9HUql7cNvSyzeNtjiaXQ21r2YmMzDZ6Pr+p/PZz7a8ezH/AEtnq/olu9L+tLOo5NNFePUPVfsd F1RcGisusf6O/wBZ/wCsN2M/R+/H/To+R1vMwsmmnqGJjsY8Gy003PtdXVXq7IfV9lr/AEbbNjGf 8IiYYzEyE+GJ00jwx1T7nMQmISxmUxHi4ZZozySjHiP6XF6uKLzZw+n1UZbHht7enUZXqSxjQLh6 eFi+t6W31LXvZfbjWZO/I/wq7jp2FVgYNGHU0NZQwMhogEge9/8AWe/3vQMbq3TcyvItx5fTQN1t rq3MYSAXQHWtZ6j2NZ7tv0E/Q87I6h0rHzchja7b2l5aydoBJ2Ru/eZtU2CEIy9MuLijYI/dj4/4 rU5vLmyQ9cZQGOYEozP6eSPHH0en/Wf47fSSSVhov//X6z/GRkGn6sWVCZybqqtAToHeu7j+RSvM MHNzen5LcvCc+nIYHBtgZJAcNr/ptc36K94XK0fWHqDLPtd+92JYzKvZU+tjA+qoudjV4VrX+pZk PZ6P9Ib6T6/Vs9itYObGLGYe3xWSTr38OFr5uXOSYnx8NbUHzzJyPrH157HXDK6g6uRW1tbnBs/S 2sqZsbu2+5y736p9ByPqz0TO6hnANzbaza+sEO9Oulr31VbmfSs3OsfZs/74tav6xP8AXNV+I6sV P9LJsa7eyt/p/af53Yyl1VVWz7Ra6yv0bf8AtxVb/rVY1tbjQ6jbkV12NHv3NspsyGVh1gobW/f6 DLrnfqtXq+r9pexLLzhnHgEBCF6xH5Kx8sISMjIynXzF81+q+M/J6/0yosJnIre8EGIYfXf/ANQv Qf8AGP0Y53Rhn1N3X9OJsMcml2mQP7EMv/60rd/XupMy7GNprLaLLC5geBNVGOy3J33Pb7dmZl0s 9Rrf8H6f/CKwPrFbZkfZ6MJz3WOFdG+xrC54qZlX72w/0qcdlnpWW/pP1j9H6f56WTnJTywyCPDw dLu/3lQ5YRhKBN8fg+W/VfFfk/WPptQaf6Qywy0xFX6w/n+TUvVvrAMnKoHTMWvc7Ka717Xe2tlI /nQ+2HbX5E+hX7fz7Lf8Eh1/WfGsxm5XpOZS40jc4jT1a/tlv0d39Fxf0r9n85/gkJ3XuoX2VUUY no5D7KCGOe1wNVrcjILbHtn0LW04jvW+n9P9D6yi5vMeYrTgFcOhtl5SH3c2PWQeIXp6v0f8V5+r o+d1HDzcqhvq47mBjfeZtbS31W1srdhY78ljrP0Vf9E/66rnXMcXZeNdj4loq2Y9GPX6b2sY07rX Oo9G+lrXtps9D0/Tr/c3rq+n5gzsGjMDDX69bbNjiCW7hO2R9JWFQ+6DhMeI6/Mf8b/vnSPxGfGJ cFCN8I4uhEY+r/wt5RmPn05XStlT8LGbvofkBrrHn7Q5mW+r0rX5V2Kz1Kfs/r3Xex9n+DZ6azLc I512Za/Hsd6pdZsbTY2wevcx7abrKqr3u9TAx2We+n06N/p2LvkkZcrxacZr/wBB4UQ+ISib4PV+ 8Dr85yS4j6perieS6VWf2x9tyKbrH4OI8saQXWMk+yjb9lwPfbV6noUfpf8ArabG6liOpuzLMx+L 1fNLTZcMay30a2mWYVTbKfT2MZ/OO/Pv9S5dckiMEgKE+5Ng7y/S9M4epaecjIkmB2jEcMh8sPXw evHkjwSn6+F51+WbPq31Cy7P+1MIfU3IfjvqLd7WV+m6hjA+332fSrrW3g4rcPCx8Ruox6mVAj+Q 0M/gjpKWEKNk36eHr/3UpMGTLxDhA4QZGdentwx0hDGpJJJPYn//0PVVn0dA6NQ0tpxK2tLQzbEg Na5trWNB+iz1GMfsatBJJTSt6P0u66y+3GY+y5pbYXCQ7c30nuLPoeo+r9E63+c9L9Gmb0XpTWPZ 9mY4Wh7bS+Xl4sa2i31X2Fz7PUpqrq9/+DV5JJTTd0vpjfXsdQyLmPbeTrLHhjb26/m2tpr9X/Sb Fh4+b0zNxcenPwCTa5lt1tbdtTLcqp+Y73+r6/8AMO25W32fpP0n6JdLdSy+mymwTXa0seASDDht d7m+5U3dE6Y6o1GmGOcXwHOHuNH7O9sO9v6n+i/9SJKchmV0e61tlPTrqc7IZW7EAZUHxbRbXXfW x9j8Wh9OLXbTZ9o/M9On3/oq1HpV/RcdjHspdZde+u1n6JtYaLKHDdVUHfoqsbEpuru92/1PUq/w lTFs39E6de4vcxzXlzXCxlj2ObtZ9nit9bmuY11J9N+xNZ0HpNgcDjtAfijBIaS0DHBJbQwNPsb7 vzUlOdT9ZMVmPQzCxSMep/ovaHVltdLKHZW+p1NtlVnpVsra6ttns/7a9Q4+stNWN6uTVaQyt+69 jAK33UsN2Tj0Nda6zd7La2b/ANH6tdlPrKw/6v8ATLGuFjbLC8vdY51thc82VNw7fUdv92/HYxmz /MTu6B0t9j7HVuPqFx2F79jS97b7/Sr3bKvXtZuu9P8AnElJ8HObmesPSsofj2elYyzbMlleQ0/o 3WN91V9aoXdfa36wUdLqfSWEmrIBd+l9V1b8mkVVz/NV11fp37P+1NH7ly1KManHNpqEG+w22Ekm XkBs+7+Sxqr/ALI6eccYxqmttxyNXO3G0uNzrXWbt7nOe7/0X/NpKaeN9ZsbKqbZj491jrXiuitp r3PO11zw5vq/qzqWV/p2ZfoPq/R/n2KLvrb0xtr6i2wOra42NO0Oa9lX2qyl9Rs9Vrm1t2eps+z+ v+h9berH/NzpW2Cyw2TJuNtnqkbfR9M5G/1vS9H9Hs3/APgil+wemRa1tbmVXNLXUtse2obtLPTo a70q3WNb79jP/PliSkLevWW5OPj04lrX2ZHo3i3aCxno/bPV9tjvzX1ez/1H6muqg6ZhjLGYGuF4 e6zdud9J7GY75bu27fSpq9n8hW0lKSSSSU//2QA4QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8A YgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBw ACAAQwBTADUAAAABADhCSU0PoAAAAAAA+G1hbmlJUkZSAAAA7DhCSU1BbkRzAAAAzAAAABAAAAAB AAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAAAU9iamMAAAABAAAA AAAAbnVsbAAAAAEAAAAARnJJRGxvbmdHI0uGAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAA bnVsbAAAAAQAAAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFs b25nRyNLhgAAAABMQ250bG9uZwAAAAAAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAc bWZyaQAAAAIAAAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EWMmh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIg eDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3 OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0i aHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJs Lm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlw ZS9SZXNvdXJjZUV2ZW50IyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENT NSBXaW5kb3dzIiB4bXA6Q3JlYXRlRGF0ZT0iMjAxNC0wOC0xMlQxNjoyODozMyswODowMCIgeG1w Ok1ldGFkYXRhRGF0ZT0iMjAxNC0wOC0xMlQxNjozNyswODowMCIgeG1wOk1vZGlmeURhdGU9IjIw MTQtMDgtMTJUMTY6MzcrMDg6MDAiIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJ Q0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBN TTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjEwN0MwRkQ0RkIyMUU0MTE5ODY1QjgyMDYxRUIyNkNDIiB4 bXBNTTpEb2N1bWVudElEPSJ4bXAuZGlkOjNDRDI3QzlERUUyMUU0MTE5ODY1QjgyMDYxRUIyNkND IiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6M0NEMjdDOURFRTIxRTQxMTk4NjVC ODIwNjFFQjI2Q0MiPiA8cGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJk ZjpsaT5hZG9iZTpkb2NpZDpwaG90b3Nob3A6MGMxMzZiYWMtODYyMS0xMWRkLWJjMGYtZTgwNGFm YjAzOTg4PC9yZGY6bGk+IDxyZGY6bGk+YWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmRjOGY5ZTk4LTE2 Y2QtMTFkYi05Mjg1LWJjYWM2NGZhNDExNzwvcmRmOmxpPiA8cmRmOmxpPmFkb2JlOmRvY2lkOnBo b3Rvc2hvcDpkZmUwYWM3ZS0xNDIyLTExZTEtODE2ZS05ZWM3Nzc3ZmE2MzQ8L3JkZjpsaT4gPHJk ZjpsaT51dWlkOjJBRUY5MjNFMUJDRUUxMTFCRTVCRUJERTMyQTJDOUJGPC9yZGY6bGk+IDxyZGY6 bGk+dXVpZDo1QzhCNjgyRDdDQjlFMzExQUI2MjhFNDU2RTA5QTM3MTwvcmRmOmxpPiA8cmRmOmxp PnV1aWQ6OTM1NjI3MUVCRDRDRTExMUExQUVGM0FFNjQ4NURCNDY8L3JkZjpsaT4gPHJkZjpsaT51 dWlkOkM2NkM4QjBDNDFBNERFMTFCQTdGRUU1NDMzRDA0RjZEPC9yZGY6bGk+IDxyZGY6bGk+eG1w LmRpZDozRDkzQzE0RjJGRDhFMTExQUJDRkM5OEYwNTJCNkNDODwvcmRmOmxpPiA8cmRmOmxpPnht cC5kaWQ6NDU3NDIxRDMzODdBRTExMThBM0NDQTBDMUQzMTgwNEM8L3JkZjpsaT4gPHJkZjpsaT54 bXAuZGlkOjgyNTI3NzhDQTYzRkUyMTFBMUE1RDM2ODFGNUYwRDFDPC9yZGY6bGk+IDxyZGY6bGk+ eG1wLmRpZDpBNEU5NjVBNEMyMjYxMUUwOUUyMEFGQ0E1NTUxNDNCRjwvcmRmOmxpPiA8cmRmOmxp PnhtcC5kaWQ6QTdFNDhDOUVDMUQzRTIxMTgxRTA5RTEwODQ2NTM2QzU8L3JkZjpsaT4gPHJkZjps aT54bXAuZGlkOkMzN0M1Qzk2QkM4N0UyMTE5NjkzODdFMUU4ODY0NkQ5PC9yZGY6bGk+IDwvcmRm OkJhZz4gPC9waG90b3Nob3A6RG9jdW1lbnRBbmNlc3RvcnM+IDx4bXBNTTpIaXN0b3J5PiA8cmRm OlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImNyZWF0ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9Inht cC5paWQ6M0NEMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQt MDgtMTJUMTY6Mjg6MzMrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hv cCBDUzUgV2luZG93cyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3Rh bmNlSUQ9InhtcC5paWQ6M0REMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0Ondo ZW49IjIwMTQtMDgtMTJUMTY6Mjg6NDQrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2Jl IFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0 OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6M0VEMjdDOURFRTIxRTQx MTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQtMDgtMTJUMTY6Mjg6NDQrMDg6MDAi IHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6 Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNl SUQ9InhtcC5paWQ6M0ZEMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49 IjIwMTQtMDgtMTJUMTY6MzY6NTYrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBo b3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFj dGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6NDBEMjdDOURFRTIxRTQxMTk4 NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQtMDgtMTJUMTY6MzcrMDg6MDAiIHN0RXZ0 OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdl ZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0iY29udmVydGVkIiBzdEV2dDpwYXJhbWV0ZXJz PSJmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5waG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0iZGVyaXZlZCIgc3RFdnQ6cGFyYW1ldGVycz0iY29udmVydGVk IGZyb20gYXBwbGljYXRpb24vdm5kLmFkb2JlLnBob3Rvc2hvcCB0byBpbWFnZS9qcGVnIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDoxMDdD MEZENEZCMjFFNDExOTg2NUI4MjA2MUVCMjZDQyIgc3RFdnQ6d2hlbj0iMjAxNC0wOC0xMlQxNjoz NyswODowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBXaW5kb3dz IiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06 RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo0MEQyN0M5REVFMjFFNDExOTg2 NUI4MjA2MUVCMjZDQyIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDozQ0QyN0M5REVFMjFFNDEx OTg2NUI4MjA2MUVCMjZDQyIgc3RSZWY6b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjNDRDI3 QzlERUUyMUU0MTE5ODY1QjgyMDYxRUIyNkNDIi8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpS REY+IDwveDp4bXBtZXRhPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDw/eHBhY2tldCBlbmQ9InciPz7/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlu bwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAA AAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAA ABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAAC xAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNo AAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHly aWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJ RUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVog AAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpY WVogAAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAA AAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNv bG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNv bG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJl bmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5j ZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAA Vx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAA AAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcA fACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwEN ARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB 2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLg AusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0E OwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXV BeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H 0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woR CicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcM wAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+z D88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMT IxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbW FvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwb FBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+U H78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwk qyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoC KjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv /jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3 NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9 Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RH RIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JM KkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRC VI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZd J114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9 ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9Fw K3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pG eqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOF R4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBu kNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByc iZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjE qTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2 AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NY w9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzR vtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A2 4L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070Dv zPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t ////7gAOQWRvYmUAZEAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAgICAgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCADGAKADAREAAhEBAxEB /90ABAAU/8QBogAAAAYCAwEAAAAAAAAAAAAABwgGBQQJAwoCAQALAQAABgMBAQEAAAAAAAAAAAAG BQQDBwIIAQkACgsQAAIBAwQBAwMCAwMDAgYJdQECAwQRBRIGIQcTIgAIMRRBMiMVCVFCFmEkMxdS cYEYYpElQ6Gx8CY0cgoZwdE1J+FTNoLxkqJEVHNFRjdHYyhVVlcassLS4vJkg3SThGWjs8PT4yk4 ZvN1Kjk6SElKWFlaZ2hpanZ3eHl6hYaHiImKlJWWl5iZmqSlpqeoqaq0tba3uLm6xMXGx8jJytTV 1tfY2drk5ebn6Onq9PX29/j5+hEAAgEDAgQEAwUEBAQGBgVtAQIDEQQhEgUxBgAiE0FRBzJhFHEI QoEjkRVSoWIWMwmxJMHRQ3LwF+GCNCWSUxhjRPGisiY1GVQ2RWQnCnODk0Z0wtLi8lVldVY3hIWj s8PT4/MpGpSktMTU5PSVpbXF1eX1KEdXZjh2hpamtsbW5vZnd4eXp7fH1+f3SFhoeIiYqLjI2Oj4 OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6/9oADAMBAAIRAxEAPwDf49+691737r3Xvfuvde9+ 691737r3XvfuvdYp6iClhkqKqaKmp4UMk088iQwxIv6nklkZURB+SSB7siM7BEUlzwAyT+XVJJI4 UaWWRViUVJJAAHqScDooHenzY6x6O2vujdjbU7V7Ow+zcY+V3LlusNi12a2phaVZFgByG/stNgti CQTuqvDBkaipjB1NEB7HnLft3vPMd7ZWIvbKzuLh9Ma3EwSRzx7YVDzcOBMaqfJuod5697+VuR9q 3Td/3Tu26WdlHrmksrVpIIxWnddSGK1rWgKpM7itSvQd9FfJv5HfKfZW3u1uouounNm9WbjesbGZ nsft/Nbg3fVQ4/IVONrYanZ2w9iTY7B5OnqqV1enqcy0iEcjkezbmXk7lPkrcbrZN+33cLje4QNS QWqJECyhgRLNMGdSCKMsVD0HeQ/dD3H91tk2/mzk3lLZbTlO5ZtEt3uEs07BHZGBt7W1KROGU1V7 io8xno5GDpO0vEr7lz2wmqCvNPgdq7gjgRiDx91kd3zSzBT+fFHf+g9gC5k2TVSztbrR6vKlf2LE KftPUx2MPN2iu57jt3iekVvNQf7Z7kk/7yvSkji3Imoy1uEnuQVCY2updItyCxytXqufzYe0ZazN NMUg/wBsp/59HRmibstddxbt9kbr/wBZG6eV16F1hTJpGoJfSXtyFLc6Sfpf2nNK44dLxq0jVTVT y9fl0z/x6kikMWQiq8SwYKsmQh8dHIT9NGRiabH3Y/RTKrn/AFPtR9LIw1RMsg/onP8AvJo38qfP pD+8oI2KXSPCa8XFFP2OCU/IsD8unoEEAggggEEG4IPIII+oPtN0YAgio4dd+/de697917r3v3Xu ve/de697917r3v3Xuv/Q3+Pfuvde9+691737r3Xvfuvde9+690GNTv6ozmRrMB1zRU246/HVclDm tx1ck0Wy9uVcPFTRVOTp1aTO5ymayvj6Eu8LnTUy03BJym1pbRR3W7yGGJ1qkYoZpAeBCn4EPk70 qMor9BWbmGW/uZtv5ZgW5uI3KSzMSLaFh8SlxmWVeBiiqVOJXi83WDY1HWPHV7uq5N45BDrVcnDH FgqSS3P8N23G0mNgCkDTJP8Ac1ItzMfbDblJGDHYRi3iP8Jq5/00nxH7BpX+j0qj5fgmZZ95mN9c j/fgAiU/0IBVF+RbW/8ATPU3eu3Nn7p2duLaG+aDE1+ytyYTIbd3Disu0UGKrsJlKOShraCoLvCs UUtLKygqysnBUggEU2y53G03G0vtreRdyhkWSNkBLB1OoEUrUgj0NfPpRv22bJu2x7ns3MEEMmxX Vu8M0chCxtFIpRkJqKAqSKggjiCCAetfDFYPt/8Aladl53OdFZw/IL4kbnypye6tgJWyVG49nqfH E1fJJBBLTUWboKRViXMUqyUeRgiVK+GF1hkTLeWPZ/ezZLaDmixO0c9wR6YpytI5fOlCQxRjkxNR 4yaxMwLA8vpz7gfc45r3HeeQLo80+x11N4l1aKxae0GAXOlSEkRaKLmMNDKi6biOMiMrbZ1j88/j 925t2HcOy8pnq5BHGcpiJsXTU2cwNS45pMxjZMkJYGVrhZUMlNLa8cjjn3Bm6+z3OWzXTW19FApr 2sHJRx6qwTP2GjDzA6zT5E+8/wC1HuPs6bxytuU8ygDxYiirPAx/DNGZKrnAcao34o7DoVKT5KdV VLhJ8pksdf8AtVuJqig/4M1GKwAeyaX255ojBKW0cn+lkWv/ABrT0PYfdjkyVgsl5LF83jan/GdX Ql7f7A2TuohdvbpwuUmb6UtPXQit/wBjRStHVj/Yp7Dl/sO9bXU3+2TRJ/EVOn/ehVf59CzbOZ+X t5IXbN5t5nP4Vca/94NG/l0r2UMCrAMrAqysAQwIsQQeCCPZRwyOPR4QCCCKg9M0+MnhVpMLUrj5 v1CmljaoxcpHOmSkDxvT6/prgaMgm5DWsVKzqxAuU1r6jDD8/P7GB/LpDJZyRgtYTCKT+EjVGftW oK/ahX1IPDqNjtwCatGHytJJiM0UkkippGM1FkoorGWow2REccVfHGpBeMrHUxDmSJVKsbTWumP6 iCQSW1ePAqT5Ov4fkcqfJiagNWu5eJP9DewGC/oSFJqjgcWiegDgcSpCyLxZACCVH7SdGnXvfuvd dG9jYAmxsCbAn8AkBiBf/A+/de679+691737r3X/0d/j37r3Xvfuvde9+6910zBQWYhVUFmZiAFA FySTwAB79xwOPWiQASTQDoCXqs13PUvTYityO3OoqWpkhrM9j6iXH57tFoGKS0e3K6Ax1mC2D5VK y5KF0rMsARSPFS2qakTBLfl5A08aS78wqEYBktq8DIpw8/pGQUi/0QM/YgBMt7zvI0dpNLbcnKxD SoSkt9Q0KwsKNFaVqGmUiS4/0EpDSSUXaen2/tDBRU1LDjNu7dwlGsUEEEdPjsZjaOEWSOKKMRwQ RLfgAC5P5J9kf+Objd58Sa9lb5szMf2knoYom3bNYLHGsVttsCUAACRoo4ADAA/y/PorPYfybjon nx2yqZQELIc/k4Tpe3GvHY6QLdRbh5/r/wAc7c+5R2D21aYR3G8ycf8AQkP/AB9x/gX/AHrqG+af dxLYyW2wRAAY8aQcfmiH/C/+8efRNN19qZHM1D1eczVXk57tpatqWkSL/CGEkQU6f4Iqgf09zBtf K9vaRiKys0jT+iKV+08T+ZPUB73zxcXkrTbhuDzSDzZq0+wcF+wAdBTlO0aBVbTWRpMisNBkA1rY ggc25H1/3nj2KLXlmeorCSh86dATcOfbIBqXaiYDhXj/AKv+L6JLvzGbBXcLbz2LlZesN9wu8rZT bbLR46vdzqlXJ4eMpSslS3+cMYCSfWSOT3Ju17Zu0lqLK9g+r28j4XyR6UbjjyrkeRHWH/PuycnH eX5t5I3x+WueEJPjWxCwSkmpE1uCFo5+IoAr8ZI5OpuC+T2aptOL3lHRz18Q0LncFIJMfXqvAlmo lPko5X+raBov/YQe6XPIccR8VY3jgJ/EOHy1cP25+Z6KNo+9TumySpsvuXZxR3QOlb61Ou1m+bot WiY+dBTz8OMdKIfJfDpKp/iMccsbBlYS+OSM/UMpBV0PHBHt9fbm6li1JCXiYeQqD/kPUhx/eJ5d k0SxbrEQaFWDj9oIPRkesf5iu6tlzU1PUZyn3dgkKLJhtw1bVEyRCylaDMkvkKN1X9IczRA/7rPu POZfu9bZvCSSR2LWl8eEkS0Ff6UfwN86aW/pdTHyX98272OSKGTd4r/bRQGKd9Rp/Qly6n0qXUfw 9W19D/Kfqb5AUvh2nmoqHdVPB58jszKzQRZunjRQZaqhCt4cxjkJ5mpy2gW8ixkge8U+efa/mrkK XXutmX2tmolwgJjJ8lbzjf8AotSv4Swz1nv7W++nIHuzBo5e3RE3tF1SWkjKJlA4slDSWMfxpWn4 1QkDoddxbfx+58RV4bJfcpBUqDFV0FTLQ5PHVcZ10mTxWQgK1GPydBOBJBNGQ0bqD9LggO0upbOd LiGhYeTAFWHmrKcMrDBBwR1Ku5bdb7rZzWVzqEbDDIxV0YZV43GUdD3KwyCOgu6l31msv/efZu8Z YqvdvXm6KnZWbzFPDFTR5edMXi9w7fy1XRQ/tY+o3NtHO0NcBH/k/nlmhTS0OknW+7bbwfR7ht6l bG7hEyISTpGpo3UE5YRyo6Z7qBWNQ1egnyfv99dndNk3pw+77bdm2klACiQ+HHNFIyjCNPbyxSin YWZ0FClCNnsOdDrr3v3Xuve/de697917r//S3+Pfuvde9+691737r3RHe6e7abL/ACe6F+ItFEz4 zsnG7/3z2fXCQxJV7U2Ht+oqcfsWlkjdZXO49xT08mUtZTjaWSlbUKmQJI/LvLrwcm8z89yGk1m8 ENsPSSaQBpjX/fceoR+fiMHxoFYK5354ivPdDkH2fhWtpuaXVxfNWmqC2hd0tVI4+NKFM/l4KNEa iVwpzMlkcZtzFvV1RSkoKKOOGKGCMAn9MNLRUdNGBrlkbSkUaD62AsPYCtra4v7lYYQWmckkk/mW YngBxJPU0Xd3abXZtPOQlvGAAAPyVVUcScBQOq2++u8spWStR5F2xBLNNSbe8qFsJQqzLTVOVMbN HPn8io8g5K00BATlizZF8i8kWsSCa3Hi4o0tP7RvMJXhEnD1dsnAoMTfc33JunYwXT+AclYa/wBk n4WkpgzScfSNKacsSSNdg984XFU2MbMSxmhyOONS1XSlY62GaGsrMfPPGCwhnMctIbxkAMDa4Nj7 m3l/kW9upLoWaHx45NOlsqQVVgD5iobj5enWLnOvvHsuz29k+63Cizlh1F1IDqQ7xswBNGoUytBU GlQeiV9pd55XEQwV+MmXM4DKaxitw492bGVLLy9JOf8AO0GTg/3ZTShZFtcXHPuZeWOSLS6aSC7X wL+KmuJ/jX+kPJkPk61B+Rx1ij7ie8u8WUcF3sy/W7Lcg+DdRn9FqcUb8Ucq/jicBhxyM9FGz3dm 58k7t/EWp1JJAhYhh9foxJNx/X3Kdpyps9ooH04Y/PrHPcufudN5dmfcWiQ+SYI/M9IWr7HqsgPH l6uoqhyFqVlYVEV/9jplF/wf959mC7bBanVZRoh/hp2n/N0WGW+3IBN4nlm9H1HUP8hHSfqM3PH/ AJXRVbVUSnUJoJHE8J/5uxgiSMj+v09vieGQGC5hCk4KsAVP2VwempOVS8bPEBNbnjip/wBspz/k 6cqTsehq1Wl3LR/fwAaUyNIy0+Vpgfo2oFYqoA/htJP5J9k0mySWjtcbDd/TyE1MbVaFvyNSv2j+ XQXuOTLm3ZrjZbjwZeJjerRN8qcV+0Vp8un0Y2fIU75HZuWi3FRxjVNSRyCmzVGDzpqKGQqWI/qL X/APvycwi3kW232zNtOeD/FE3zDCtPzrTzPRYL9bGZLTmCyeyujwfLQv81ccPzrTzI6asN2bu3ZG 6sDnsLns7tnce2aqbJYquoKqrx+XxuSURwQS0jK0U8c2mRh/RlJBupI9mV5tey75t9zZ31lBdbbc JpdWVXR1PEHiCP8AAcjPUh8u7lzDsNxbb7ytv1xbblBNHJBPBKytGyktrR1OOGc5FQag062YvhP/ ADTdidmbCy2I+R+4sDsHsTYm3KrP1u46qSKhwe/NvYxP8pyGOp4kCx7xpgAtTi6ZGNXI3ko0ZS8U POT3p+7funKu7QbnyHZzXnLd5OIxEKtJayue1HY8YG/BKx7B2ymtHftH92777fLXN3K9/tnvHvNt tvNu1Whma6ekUO4QRjukjQfDdg4e2jBMx77dMtFEcb4nY7dm7aHt7vbfe38htOX5D7+pd2bU2VmI mpM1t3q/bO0sBsfr47gpAxbH7l3BicC2XqoQxamNckZIeM2hHnuSw2+XYeWNru0nG02pilmQ1SS5 kleafwz+KONn8JTTu0E8D1kr7Kxb3zBZc5+43Me1y2R5n3IXNtaSjTLBt8FvDa2XjLXsnmjhNzIo NU8VVrVTQ2dHO6zS4+oLGenRZIZXIJrKRjpScHi8sTeiUfhrNwHX2A5FBUSr8JOfkfT7DxH7PI9T TBIwd7WUnxFFQT+JfI/aODfOhwGHTj7a6V9e9+691737r3X/09/j37r3XvfuvdMmfyFTQY8jHqkm Vr5o8diY5QzRGvqgwSedV9TUtDCj1EwFiYYWtzb2ptYkll/VNIFGpvXSPIfNjRR8yOkG5XMtvbUt gDeSMEjB4a24E/0UALt/RU0z1Sj/ADFWy3xg+S/wn+W2MgyGR2hsit3B1rvyWMPLVT0WfqKvJ5mS ocDxy5Xc+Cz2cqEvYPVUo4Fx7yO9oo4OduT/AHH5DmZE3C5RLiAcACgCpTz0xvHCp/ot1gD96vcb 32Y9zPYX3ot4pZdgsJ5bK8IqWKyl3lr5NLcQz3brXBkjr6dGF7Y+VuGzGdl3rgszFV9V7Boo6/Hz UcqCDfGTzdFJBjBTSSKRoyvnP27lS0FJDLNYM1h7lL2wuoNvi2q6tCOZNxajVGbeNGDMTT+Cg1Ct GdkStBXofc9++u1XN5JzPt25q/JG1xCRGQjTePMhEWknFJdXYSKpEryUBNOqtflZ8g8V2HR1PZ/W AnlxuP8A4ftzfWMnRIcptvLyiT+D5eujp5p4qnCZqImlhq0IUVFN45ArOgOUPtdyBc8vSx8t8zlV nk1zWzjKTRiniRqSARJGe9kOdD6lqA1MAPf/AN7IOc7SfnL25DS2kBS2v42oJLWYg+DM4UsHgmFY 0lU08SLQ+lmQGtrfe+a/ObG2dka2reWWnzm9cRJ6zpCIdvZmBLA/QPmZbX9z/tVhbbbvO729vEAj Q27j7f1Yz/KNesPN8n3PmTlblm+3K4aW4S6vYjXgB/i8yinpWZ6dA9iu0cjtpquCP7fJYXJKseZ2 /kg02KykK/pM0Vw0FZEOYqiIrNE3INrgmm4bbb3/AIUjVS8j+CVcOh+R81Pmp7SOI6d5anv9mE1v Giy7ZPiWCQaopAPMr+Fx+F1oyngeIKf3DNjMjTT5zZdRPU0MamXJbfq3EmcwF/1E6QBlcWpPpqIx qUcSKDc+621xdIwt79R43k6/C/z/AKLeq/sx0bXWxbaGW4sWKW7n4H+JD/Dq4MP4Tgnzz0EFRun6 2l45/tX/AOK+1+tfXpVDsX/C89Ny7vmgkEkFQ8Ui/R0cqf8AWP8AUH+h49tSeHKpR0BX59GcGzPE weOob5dSxvOirDbIKaeU/WtpAFuf9VPT30Pz9Stj7SFLiDNs+pP4G/yN5fnjox/dNvc4uYNMn8aj /CvA/lnpV7Xg3pla6Gp2PTZbMzxHVHX7cjqZXp+RxPLDYQc/qDnT/Xj2zPuW2tG8O6aI0plZaU/L 1+VM+nQX5p27l7ZbF25jv7JNvfFJnQavsRzqJ/0oJHlno0+FyqTUa4rt2s2ZBuVJFGPgnrMVU5JK TxAv/GmpDNQYusMlgoMkfkBsRqHICvY/Bl+p5Y+qWybDU1hS1fwcGYU44NPWnWPO47PdieXcfbqw 3V9iCapWWOZYq1wYtYV5Ep56WpTBpwacs2V29WYvcPWNTj3m27kqbK/dYSejyGRxmVx1XFksZPAr SVUbR09SgkEOk3I/Sykj2psprPcBPZ82iR45kKKsoZY2VlKPqFF7iMazwHmDQ9CXlLmK8sN02y+3 q5uLXebZ45LR5UKKrRvrDUZQC4cAhnBHkeGdv/4CfLzFfMLorHbxn+1oex9qTxbU7V2/ABCKDdFP TrJFl6SkJ8sGF3RSAVdMCLRP5qe7NTsx5m+9PtlP7Yc43G1wlpOX7kGazlOdUJPwM3AvCexvUaXo A4HX0pfdv96rX3u9ubHfpjGnM9rpgv4loFE4WomQf75uF/USlQreJEGYxEkyPatZLt7bi78pQxqN g1Ue4apFJUVW21Ipt3Uc3NmjO35ZqiMG6rVU0Lkege482ONbq7O2P8F0vhj5ScYiP+bgCn+izDz6 lXm+Z9u2xeYYQfF25xMw/ih+G4U/LwSziuBIiN+HoSo5I5o0lidZI5FDo6EMrKwuCCOCCPZOQVJU ihHQoR1kVXRgUIqD1z966t1737r3X//U3+Pfuvde9+690nIwa/ck8rKTT4CkSlguPS2TyiJU1jjn 9dLjlgVT/Spce1Z/Ss1UHvlap/0q4H7W1f7yOixQbjdZHI/StkCj/mpJRmP2qmgA/wBNh0Rr+Zll djn4x57ZO76OnyFdv/KYzE7UjdddZjM5jaiPLxbjx6i0pqcR9sEAUjyNUCJrpIymZPu/7Nuu5c/2 19t8rR29lC8kzDgUYaBG3lRiamvAIWFCARi999HdOV4vZPd+XeYoUkuN2mjhtQcvHMhEgnQDJaPS FoCNXiCM1VyDrOz7q35jtmS9M1tfAuO2xncsVSlmSVo8mdFFPFLXQySLV09Aadkp1v8AsrJIo/VY Z+bJHtFjuzb7dWrm6khTSSD8GWFFNKa9QavnRa8B1wU3n3I5l2PYbz2r5gvym17fdzEeFR28XCFD IrUdE0nw80QNIoIDUCa2Tid67SzZzFHNgs1jclR1OG3TtXIy1sWP3TtrIhUymErZhTusZlRRJBNp 1U1THHMhDIPYl3zmDZ98tBaPBcQzxuJIZlCloZV+CRRq8uDLWjoWU4PQK5K94Nr5K3n6mTbp5trm jaG6hbSY7i3koJInXUDkUZGHckipIvco6CHvnb6ddbep8ZRVklZt+u33lsttasqWjFc2Kr9uYXy0 GSjQkJlcRPSCCoKjxysgljJRxYy5Z3l95vHuriMJerZokoFdOtZJO5a/gcHUvmK6TkHqfYjydvXL iyck72l9sv7weRK9s8SyRRfpXERo8ciaNJNNEmnXGzKRQl2S3IRq/c/259jNpMfLpVZbLXT2dJ/G 5zP12ShXa1PmMjlke1PHgaOtyFdrPGlYaCKeQhr2IIIYcEEe0k88US6p3VV9WIA/n0dXW3bbY2ck m9XEEFiR3NM6RpT5s5Ufz6Eyv673ZlKT7/d9Jgupso+grVb53Bhdq0ObZ2ADfwCprG3DSVr3uTFR tG5/APtAd7sJKrbu8s3pEhcH/bUCj7S1OgPa84cv2Nx9Ly9cXXMFiK9tjbzXTw0zTx1QW7oPINMG HqR0ichjesNp1j0G69/7l3TlobNJhet9n1ENK4P6dO6d5vi4ZIH/ABLBj50I5BPtia83MGn0aQD1 mcV/3lK/8eHQq26fn7maBZ+WuTLSzsmwJr+6DuPttbISsCP4XuIz606k0vZ2y8FEKzA9XbXw9NG7 JDney81XdgZ6qmjsSmPwEQw+3RUL9WLUMkUN/UTwCmCXFypafc53j9IVEan5BzVj9ur7fTpVN7Zc 17i/0/MPuBctKRVoLCOOwiVT5ySDx7vT6DxVZ/IDJDTmfkhvLMkQ1G6sq+NQGODAYcU21tswRlSm kYnCwUkNQQp+roLn8Ace6rtNs2rTaRxE/iJMsn+9tw+dOjnZPaPkjlmVbyy2CO43UZNxODPKSfPx JzLIPlQin29Z5d24ur2/STV001BPW1BkpmDLKqGRdLGeIBXceJAwYjgOCPqD7MIbS5sIxPE6yOT8 PA0xwPkaf4ejS4ji3TcprBonSGJRVhkVHAf6WppQeanhnrrEbnzW2aiLJ4jIy0308dfjprwSof8A dc6DVG8bflJFKn/H26ZrLcka2uYgT5o4yPmPP8xnoPb/AMl297bvDuFnHcWh9RUfaDxU/MEH59WS /B352dl9E9r0eV2JisPX7h322E2ZmcFXRmPb2/kqsvTw4XHZDTUUr4bMxZKr0UdfHIRTtO6svikk jeHPdf2r2Tm3lyS33G7kWytNc6MDWS3IQl2TB1oVFXjI7tIIOpVINPZDmn3Q9g+cRuPtWy39nfmO Cbbbk1S4BkGhUeq6JFYkRyalZCzA61Z0a2T5L/znd0S0We602v8AH3+765Ham5dldl0PYmbrKbcu D3RkaHJYDN4nCQ4mCOGnj2/UuR5q2ITTyKUempytzjNyj93O0je23q85rE2meOa3a3QGN4lKyI7l ia+IPJDRRQh3r1lr7gf3g1/uSX/Ke1e2L2TPaTWt/HfSMLiG5ZXhmiiEYXSIGxqlQO5BDQxEZu7+ MXenXffPVWz93dfZ+DLUuS2ft3PVlAzxpmMJLk3yuIrKHOUKSStQZCDc22cpA63KF6djGzJpY408 5ctbtyxve4WG62pR0uJEDZ0vp0sGQ0FVMckbDz7hUA1HXRf2q595b9wOUtm3jl3cVmhls4ZWWo8S IuZI3SVQTpcTwTqRUiqEqStCTF+wn1JfXvfuvdf/1d/j37r3XvfuvdUwbk+U/wDMO7j3hvna/wAQ vjdtzDdf7e35vTbkXenaNTHT4zd64Dc+Uwcea2lRZfJ4GjqMWaahjRZYYMwJTETdP0DIWy5K9qNg sNtvefebppN0ltoZPo7cEtFrjVykpRXYNUk0JipXz49YQb57q/eU5w3bfNp9lvbS1i2KDcLmL96X xAScRTSRrLAsskSFNKqKqlzXSfhPaKq/mDvb5kUvYo2/8ke0dvbj3Z1gcRJjqHZdNiaXB4fJ7roK LcDUdAaDbWAp6nJ0WMipZ6mSVZPDqhVXJYe8q/aLlzk5+XP3nyLYtabVuYkDmYu0siQM0WpqvIQj OXVApGrvJUAdc1/vL7/94W453Ox+5/Oltdb7sTwmFbVY1himuo0uNKeHbwq0scQieVnDaKxhWJI6 K5gIgQrG5Z2MrszFmd5GLu7sSS7u5JYkkk8+xtcTSzyvLPIWk4En5YA+QAwB5dc6t7nmlmmeaQtM SakmpJ86n16FfGxcL/gB/rc+0HUeXr5brLunbez9xYGop98Y7GZDAUQOUqTlS0dPQikR3at+6jki mpBDDq1OrrdSQbjj2/bXd5Zza7GR0nPaNPnXypwPSvk685jh5o2mz5X3R7Td7yeO2V14frOqDWul tSgkMRpYilQKjolGT3n8T9i7myGLz3S2UpMziqkwVEVfBR52jW1pIaqmpa/dE1HPTVULLJDIIyJI 2BH19iUy8x3UCOu71iYVx2n7CQoII888esyLv2Z+81eQtaw+59g0VSKpK8DHy+NLRXp/tusm4PkH 8ZNxUjY2XI9zbSxLR+NsTsOWTZuJCadJV6Pa2VpUmuPrrD39oUj3O3bWRbySV4yDxG/awPRVtH3c vvEbRcC+t7Hlbcr4GomvWW8lr8nu4iR/tadATUYz+X7WySzzbl7loqyUs0lXW02Rys+om5aR6rDZ RZTf8sG9qn3XfyAC8IT0HaP5UP8APqV7XbPvp7XGkMXKHKtxEvAK8Kj8lFxEB+Q6Urbd+GkVDSY3 Md19jVFA8QqcZi907XqppsXA91QxrR7LpaujpqiM3SKU2ZbOoAsfayPfd3t1RJtttZPMamJYfmX1 Cvz6IJbj73E9xcXVj7U7Wk4bTI9ndRokpHEEfWtG7KcFkFQaqxJqOkbVfHD4w7khkzmL+VObWhWR aWNJtjNURY1C5Wmofs6eioKikgjuFXVGoa+okkkl79+73KPF/dSMgNO2QY9BSpp+zoyi9z/vCbFI m17j93GM3RXUSt4QZDSrPrZ5FdjxNGNOGAKCDVfE7pHCTUtTV/Lba0EEjOaanz+1Wx0dVKkeuOOV m3BCzRIxUyKApK+m6k39ufv3coSpuNkYD/TjP8v29Xi97fdzco54IPu2bq0qgamguGkKgmhIH0xA JFQpqQDmhpTrPS/FHa2ZoZpcP8rOq82Jcn9ya1aMxoZRTmKenYRbglCuA6EKOFUAW+ntxeZLt0Jb ZJzVuINRw/0vSW497uattuoo9x+7zzJbFYNOg6iaaqq2bYVHxZ8ya149O1F8W5NvOrv8iuqzTyMA 8LMVjqE41Dw1GYVGYr9COf8AH2xccwJIoE2zzBxwNaEH5GnV4PffeZyfp/ZLmWnmPDZh+dID0r26 42Ng4Iwe4Nsyy07Ry002Lqscr01RA6y089II8tI0csEyhkNiQw9pId4m1F/3c7seOokggihBFMgj j1s+5nPG6Oo2/wBoN0goQV1rMpUg1Br9OtCDniOl9vPK1m65qjduQyD5ur3VLU7iqM86sP49U5Or qKitzCMQBIK6v8rFluuvUB9PZBaW8NlGthbxiOGACMIPwBQAqfLStB9lOo6v5d+bmLdL3mW0mh3q 7ne4lWUEMWuGMpbPxBi9a+f216uY/kQ9i9e7Z7F7g62ysWYoux+yaPC121cjI1Q+2s1g9j0eYyGX 27CqAU9NubHHMSV416jPRGTTo8LeTGT7zm0brd7ZsW7wGNtotGcSKKeIjzFFVz5mNtITHB6Vrqx1 F/u8+aOXbHdubOW7pZk5l3JI2hck+DLHbLK8kQHATIHMma6o9dNOnv2fPeGXXVrr3v3Xuv/W3+Pf uvdYKp2jpal0bQyQTOr8HSyxsQ1mIX0kX5492QAugIxUdNzErFKwNCFP+Dpj2ft6i2ntPbW2MaCK Hb+CxWHpS1tbw4+ihpVkkIuGll8epz+WJPtTf3Ul9fXl5N/ayys5+1iT+weXSHZtug2jaNs2u2H6 Fvbxxr9iKFqfmaVPzPWlx8+99ZPefyz+QTVGSWgxGF7R3XgY5aiR44UTAVi7eMhjT92pqZIcPGgU AnRGq8Ae+tHs/DYbF7YciW0NuZtzl2yCUogBb9VfFyeCLWQmp8yT59fO995rmO83v3790mPiS+Fv d1DHGnE+A/gVPkKrCo1NwVVHl0Wza3cu1cVJHisi2YehoqdIm3JNSxGnYxluaqmifz08QSwVvW7A crfknO6cu3rvJdqIVmlcnwVJJFf4TSjZqSMAeR6xn3T2p5n3pJ9x22G38d2LGHWV0g+kj0QsTWoq o/hJ8hWh+R/StFA0sm+6GQxrdqenosrJVtb8JTtQoWP+xt/j7IW2Hd1IDWTD5kin7QT0A4vYr3T3 W48C25WYGtNTzW6J9uoy8PsB6bfkHW7z3105HluoKmh3PtTKUrVu4kwjPU5vMYSALL4cRpbxzU9P PEwrqUAVZ06bWEinW3eBa3pF6pSdcLXgCfM/5Dw/l0J/YG25O5J92ZNu91baaw5otpPDtDPpW2hu GqtZieDupH00xYwd2okEo4pty266jt+nG3KsJD2Jtunel2rJVSLDLuHb1GCTtTI1EpVTlcNGrSUc jkaotUZNlB9yPZ26CMxwsKnPyYnjT7eukO6Rz8qbkm93kbPyzMQtwACzW0nBJwBUtE+FkAGGKsAa 06DzP9S9i4Z6L73HPXCukEMX8CnfJCKoYahBUrDGrwsQDZyPEbH1e1T2U66ax1r6Z6W7V7i8pbmt z9LuHg+CKnxh4VV/iWpoR8gdX9HpR0PW+68CqyQYmonzQs38RyFRTUmGwrfX/IhX1EMeUyUZ/wB3 spp4W/zYkYBw8LCSMV+nBk9SFoPsrxPz4Dyr0UXPPmzbmWR930bZ/vuPW003+n8MExRn+AESOPjK CqmMdlZRJJJ8vvTCUc8sjSTtJuGpytZJKxLO8i48VTSSsfqS1yfbLbbCxJmMOo8a0J/kD0rXncaE i2zZr+SJRRQIvCQAcAPEKAD0x0vOv6egwefFRS7yymRqPtKiGTx0tbj8VGJSkaPU1VZUqXJkISJS lmkcW59v2tht8UupUUtTyWg/M/4Pn0GebN85g3LaDDNtohg8RSKyiSU6akhUVTTGWIOFB8uhF3nk JZqGCiqKjH1ddNOsuKos5Uyx0s9VGrca4yGVjG5C6iI2YgH2oubCxdAslrEWrgMME/l0EuWNy3WC 6luYLy7jtVSkrwULqpp/FXzAJoCwAJHQRQdi71xiZfC1NFSY2sho62fHwU1ItDHRywwGR1+2RXWp DRI8iSavUygXIPBeLeBBJEbJFahoACKfl59SPJt1lett25Q73cTWzSIsjM/iFwWoDqNNNCQpWmAe AI6B2LJ7qrJ5Jp8zWvBEPJW11TKziKP8lpba3lf6KgN2P+8E88FlDRvpleZjRRxJP5+XqeAHUq28 xlTwo3EcAGdICgD7BT8vPoxvU9FJu/HZbdWcmm2l1ztSRU3DvTIoPtppBbw4bCJZTl915GwVKaEP oZgz24DE9xDNbSxQxsr3EnBB5etfRB6mnUZe4POljsMtnsGz2h3Dnq+FLWyQ1Yr53Fyw/sLaP4nk amqmlPMjaH/lu/C3oP5/fBCPdUMWd6s3xtfuHsHZuI3jiqls9Vtg8TT7fqsVjNxYLI1SY2upjj8s k7R070ssdXLI6zWkkD4ne7XufzP7Y+5jWSeFebPNYQSGFxoGpjIGZJFBYNqUirBgVABXAInX2w+5 3yV7ve0cG48zbxdQe5q7jOZ9yiJdWYpCfA+mdgn0sSlVhRDE6kFtYDupur+InwQ60+H2wqXb+Oyt Rv3dkm/4d9V2+83jafF1aZ2fC1OzKeLBY6kqKsYagg25l6qlEZqKh5fvJy7kOqpjlz77m7xz/usl 3NALWx+lMKwoxYaA4lJdiBrYyIrV0qBoWgwScxvZX7vfK/sjy1b7VaXjbhu37wW5a6lQRt4pja2A iQM/hoIZJE0l3LeK9WoQqnz9xh1kP1737r3X/9ff49+691Er0WShrUYEq9JUowXhirQuCFtzcg8e 3IiRLGRx1D/D0zcgNb3CkYKN/gPRN+6+xOyt+75x/wAYvj3lV2vuuq25i91dz9yGliyEfSHXWalq aTDUuAopw1HkO29/mgqlw1PNePH0lPNXzIVEAcfcu7VtG17dLzjzVB41iszR2lrXT9ZOgBYuRlbW HUvisMuzLEprqpDHPHMPM3MO9Qe13t3efSbs9qk+47jpD/uyzlLLGIlPa1/daHFujYiRGnYU0HrT A+VmCh2B8g+9dly5HOZHH7J7Y35tynrtwZKTK7jzC47cuRpqWqy2VnVZMhmclBEJ6upZQZJHZ7XY D31Y9vbyO85C5Pv7S2hjuLzbbeVhGulFLRKWovkik6USuAAowOuIXPfKEXLvuf7h7QZp5YLPebyI STOZJ5QlxIqtLIRV5HA1SORkktTIHRSMnQbq3CpNJjzS45NRjeqdMbjYF/46GSpZGlP5L2dj/X2M UtilWAJc8WPE/wCx8hgdIk3rZ7IpFcXY1DhFGC7fZRa5+bGvQay4fZVBl8dHurfuJqHbI0iS4jC0 9RkYJSahB9vX5MaKelpZD6ZGtcKT7owjBAeUeWBn+fQoh3Dma8sLttg5TnVRC5EszLGRRT3JFlmY cVFcmnQyr8wD0bvKmotp42DdtC8UUO5sFS5daDB0sUNQFjjokpqeppoNx00CtolQKI1IjlDA2Um3 zabHcY/DZQLlRhx+H5H+IfLy8iOo9m+703uty7Lc8x3z2F4CTbTtDrnYlfx6mVjbMxFUNdRq8ZU5 Y3EWxeofkph4u3ejn27idyeWd92YqXCYyhzM2UqqZ2+wz7Rr91g82sx1LPGzUlchJDEEv7C22bvf ct3SWe5RarMnBpXHqp8x6jiOoJ/rpz97O3re2nvCL242ZUVbK6WaWSOOJGFGiBOm6taYMbAT2xoA MeGSU9rQ5mgp9wbRphVUW68VJTyZbHJJU0WUpKCGbXUy09liapFkXUI2P7T6uQReTFvLe+tC+3zq 9QD2nNPP/iusjeSoLM3Gz8wXfhS8vXKt4E3bJBKzCi92QOJpqAIcaSAwIBYI8VPVEPUSTVDHnVPL JMxv+dUrOTf2i01yxJPU0PfxQDTCioo8lAX/AAAdPdJtuSeSOGCHVJIQEUAAfS7MzGyqirckngAE n24sRJAC9FlxvSRI8kslEHH/AFeZPkPM46dqvExJAuOpBqpUdZamcKR9/VqColN+ftoAxWFT+CXP qbi7LQaF+HzPqf8AN6dILfcHaU3lxiciir/vtfT/AEzcXP2KMDLJUYRn5fU9l03csxAH0UFieP6D 22UJ4r0Zw7mFwhAzXGOlLisfJLJjKXccM1TTGeKDEmKJ59w65WEa0tBEiyVFVSThtLI6kWJ034Ht O14GPhRqHK8WJoqf6ZvT5f4Oq3FvFbwXe4xXItkKFpFJARwMliCQqMKVElQMZ6FXMdDbO60p4Nz9 5V1didvAR1W1+nNvyq3YG65mjDody1igQ7TxMhsHqZytU8Z0xqjfUOGV55pY9oPjPWjXDD9NP6Kf xU8guPM16j2P3n5l59duW/aexhe5QlbjdJgfoLUVoWhU917cAcEWsStliy8Cx9t9mbi7JqMdSSUe P2rsvbKPT7M6+23G1JtnbFIQRqhhGlsjl50/4EV04aeZif0qdPtda2EdmHYEvcP8bt8TH/IPQDHU v+33JOzcmRXlwl1Nf8zXpDXl/cnXc3L+jN/ocKn+zhSiIKfERXrdl/4TSUtXD/L13PU1QIXIfJbs uelJB9cFPtTrjHu4v+PuqORf9dT753fevkV/c60UcU2mAH7TJOf8BHXUX7tcXh+3twwFFfcZWH/O KAf4QetgPI2MMA0a71+OsvIsVrqd9fH/ABzC6v8AYe8aovibNO1v+OnqeLr+zjGmv6if8fU1/Lj1 P9tdKeve/de6/9Df49+6910QGBB+hBB/1iLe/cM9aIqCDw6L78etpHCY3s3dWRXy7p7E7m7Jze4q 6VLVM0G2Nw1PWu0KIuw8go8VsjZOOhhjvoX1Mou7Eijmm++pm2eyixZWm3wJGBwBkQXEp+1pppCT x4A8B0APb7aPoLbmTdLgV3Xcd4u5ZnIyRDKbOBfXTHbW0SqOAyR8Rrp1fzdMXN1F85+7qGlxdMh3 bX4XsjHZGqjaUTQ7y29jKmumpo2sv7ecpKuIsDYvG3H199Pvu6b9HuvtBypIoBubaN7ZjxIMMrhB 8v0yh+wjrj996nkOay9/OdlubiQbZeSx3caL2hvHhjaQk+f6wkH5HPVLO9t5ZfKmT+I5OqqluSIX lZadf+CU0eiAf8k+5hmmdviboHcs8ubfYBPo7GNG9QO4/axq38+gXpq6+UevYB4cJA+WdTyj1MDp Hi6Y/j/KMrLCCPygb+ntIh1OXPwqK/5v506lKe08Lbls1NJ7thED5hWBMrf7WIOa/wAVPXrDg8Cs kS5TLyywUUsjsrIFNfl59ZMyUCOCukyE+WpceKIn+29kO0jqNch7P5n7P8p4de3TdjG5sduRXulA rX+ziWmDIR8vhjHc39Fe4Dh132Dvbr3ceO3JsTKS7ZqMcDFBQUeqbF1dHIytPRZqimJjzcVXpHma fU5IBQxlU01urO33GA291CDB5DzB9QeIPz8/sx1FvOHKXLPN+zXmy81WK30M2WkfEquK6XhcZgKV OgR0UDDBwW1Wm7a3j1P8ucRQYrdNJFsXuLE03+4qtpHQVbSxIS0u3a6coc5iXNzLjak/cRKToJF5 CCJrLduVJxe2TmSwrx9Pk48v9MMH5cOsH9y2f3A+7te3txs0h3n2vuXrNDJXQATQeMq1+mnAwl1E PDcgax/ofRWO0egNzbEyzCvx8QWod3iyFAjfwTLKG5rKCV1AopzcGalk0vGxuLggkd7RvFlvkeu3 IS7HxIf8K+o6njk33O2Lmra/qtov3kt0A1RyU+ptyeEc6CutfKOdKxuBSoaqgNkwwpY3pYkvK48d XMByQDc00R/EQI9Z/wB2Ef6kcnXh6Rp8/M/5OhM25eO6Tu36Yyg/5+Pz9B+EfPhNh2hPIiyzIlJA xAWaounkYmwWCK3lndjwAoNz7SySxKSkdXlHkvl9p4D8+lUd1Iy+JJIEh9WwKf4T0LmF6Gro8fFu PdVZj+uNrsA67m3rEy5SuS2rTtjZ8Z/imRqHH6GdUU/W/sOXO5rNK1rArXNz/vqE9o/5qS/CB6gd AbcvePZrK7k2Xk+wm33mUY8O3oYoz6zTmsMSjzJLsPQdQ8h2PtfrlKim6P29PDnpY3grO3d6wU2S 3rUB1KSnbOMdJMZtOnkH6WVHqNP1sefdl2S6vAp3mUCAcIIqiMf6duLn+XSCLlTmLnmaO99198Eu 36gy7VaMyWYpkfUy1Et0w8wSI68KjHRWczVZavqKvK5OrqsxX1sjfxmbLTzV02V1sWjnrJ6h3mkn QkoJL6lGkDjj2epGsMaxxRgRKKaQKCnlgdTjtsO32sNvYWNvHbWkQ/REShFioKFUVQFCnB00oc16 D+t2lFkkmnxkyxKLD7SqDeSGU3Ji86gq0Vv0uRyPr7baAOCyHHoehdbcwSWTRx3sZLfxpShHrp4g +o/Z19Az+SZ1N/oi/ltfHzHTQyxV+9aXdnZ1f54TBJN/frd2ZyuIqPGwDCObbf2LJfnQR75SfeI3 dN393OajE+qG2aO3H2wxIrj8pdfXW37v9hcWPtPytJdIFnuke4oM9ssjNFnzrD4ZJ/Z1aZVupqcd TksGlqJJrKLgpTU8jMWP4USun+xI9wxGDolbyAp+0j/JXqXJ2BltYq5Lk/kqn/KR04e2ulXXvfuv df/R3+Pfuvde9+6901UCLTVWSo1iihRqj+IQ+Ow8q14L1MjoOfK1ekrMfzqB+p9vykukMhYk00n/ AGvD/jNP2dI7cCKa6hCADVrFPPX8R+3WGJ+0dawv/CjroSq/hXSnyiw1E0lPjzWdNb8qIogft4ay Ws3RsGtqGTkQ/eHL0zSPwJJoEvdgPebP3Pub0R+ZuRrmWhel5ACeJAEU4Hzp4TADyDHy6wU++jyG 10/KnP8AawVMYNlcEDIFWltyaeQJnBJ8ygrkdafO4q95HZEDSO7hERAWeSR2CoiKOWdmNgByT7zd lYnHr1iPsVmigSPQRqKkngAMkn5Dieptftr+51DQUme8FZmMs38ZqcNBJIY4/CGp8bT5apTQftaQ yTO0UR1TzPbUqR6i+8QtkVJMyNkj/BX5fIcT9nSW13z+sd1eXW1a49ugHgrMwFTXukaJTXueiAMw pGgrQs+kc6RKjITipq380rKiA6USOONBaOGCKMLHBTxL6UjQBVH0HuqhnJLH/V6D5dM3Lw2kXgwL pjBJ8ySTxLE1LMeJYkk+Z6EnEYy+n08m3tUi17iOgXuF7TVnoVMBh6pqmnNAs4q4pEmgkpTJHUQS xENHPFNEVkgeJhcOpBU839qNCaSZaaKZrSlPnXHQH3G7EySxSIHjcFSpGoMDgqVIIYEYIIIPVnvR 29cx2JiMvsPsiLGbi/h+LgqFrauWM5WvpmmFLpyFLEtpKmk1KVrFaOfkawWOr3GfMm3W+zzW267M 8sYZyDQEIGpXtJ8j/Caj09OsLvdXlCH243Ha+ceT7mTb7qe4ZPBjykR06jQ1IVH4GBwyHIFFGnp5 yPxi2bVyLNiMrkMVUtKuqWWjx2R0wmQFljUxUmmcR+lZH1kHkg+00XOl+tRdW6ypTgGZamnnxx6g U6T2f3jOZbeNxe8vWErhO1k8SIhgPiIJkUgnJAC0/CR0AlVvDAbNyFZjevNsUtLnqCoqaCfeO73p 9xbnFTSzPTzvi6VlbDYe0sZ0+JHNh7HtvsVxuUMMu63+q1dQwhhrHHQioDH43xxqR1IP7l37m2CD ceeOYJp9umRXFpa6oLbSwDKJWr40uCKhio8ugX3GM1uKvmyu4MlX5rJTX8lbkamWqnsedEbSMRDE PwiBUH4HsQwWNvZxLBawLFCPJQAP5cftOepC2Y7bs9rHYbRZRW1mvBI1CL9ppxP9Jqn1PQeZDC2D WT+vFve2SnEdC+z3KtKt0g6/FqHYMtlIKuPyUI/of8eR/Qj2naOh/o9Cy0viQKHPEfb08dQdQ7l7 m7k6z6V2TSmfP9o702/tCll0l/AuYro6ety85S4hodv4wz1kzfRYYHYmw9hzmjfrPlLl/eeY74/4 nZ2zzN/S0qSqD5u1EUebMB1JXJGwXnPXMWycu2hP1t3cpElBUJqYAuw81UVZz5KCfLr6WuydoYXr /Zm0th7bpxR7e2VtnBbTwVKLf5Nh9u4ulxGNg9IAvFR0aA8c298Wtz3C53bctw3W9fVeXM7yufV5 GLsfzJPXc3atttdn2zbtosU02VrBHDGPRI0CKPyUDp2jLTZOoYraKjp46eNyBdp6kioqQD9dKRJB /sSf6e05osKivcxr+QwP516dWsl3K1OyNQoPzbub+QTpx9s9Kuve/de6/9Lf49+691737r3TTkV+ 3lpcokbO1IWgqNJIP8Pq3iFS5UA6xTSRJN/UKjW5Ni/EdSvCThsj/TCtP21I+0jpHdDw3iu1WpTD f6RiNR/2pAb7AacegW+Uvx72l8qvj92j0HvS0WH7G2vV4mmyiwrPPt7cEDR5Ha+56ONiNVXtzcNH TViLcCQw6CdLH2IuSuar/knmnZeaNuzcWkwYrWgdD2yRn5SRlkPpWvEdEXOvKu3878r7zyxuQH09 3CVDUrokBDRyAescgVwPOlDgnr5mHcfV27/jp21vvrHtHEHHdidU7nq8FuDHSB2oabK0c2vDzY2W RVGVj3DTeKvo51BgGOkE41sVC9f+Xd92zmTZtt5j2mcS7fcwrLGfSv4SPJ1YFXX8DKwORjkrzDy3 vGybjufKG4wtb3KSvDIPxMq4eQHFINJGhsGYslKRtVgjgqK3LVsuRyVTLW1tU/knqZ3Lu7n6AE30 RovCqLKq2A49moLOxd2Jc9F88VrYW0dlZQrHaxiiqooAP8pPEniTk9DBtra+Wr4Y6mkxtTNTM2la kIEp7g6TeeQpEAG+pva/txZoEYo8qhhk1x0CN0uGUH1PkMk/kKn+XRlOv+ra7OP5EQVlNTc1tVDO lJhKEKCWWu3FUiPHqyn9SQtK49tXG6W9uVEkwjrwFC0jf6SMZ+wtQdRBzdzjsnLi6dwuC1+/wQJ3 SsT6RrVz+wD+l0PdDjutNtJ4KzJ1e7apbasFs5mxWA8g+iZLc9QhyGSRTwftwB7bRN43BtVrai2h /wB+XHfIfmsQ7V+Wo9RHf8ye4G+Bl22wh2fbz/os413BHqkCnSp/5qselZFv3cJpxj9r02O2JiQw YUW1KZaSqmsbq1dmZRJlK2TjkmRQfyLezS25XsC3jbi8l5cU+KY1Uf6VBRFH5H7egXJyps/jG832 ebddwp8d02tR66IRSJB6dpp69CttDtHfFFVwNmal9wY4qsU0M8FLDWKL/wDAinq4IYWaoQfiTUrj g2PIK925K2Ke3kFkn093xDAsV+xlJPafUUI+fDoBcwci8sXVvIm2W4tL2tVKlmQ/0WRmPaf6NCPm MdSN99Nbf3pG269kzDF5GoDVFVjPD4qSqqbl3JhZkkoKwv8ArRToc8ra/JFtHMd3slwNp36piXCv xKjyyPiT58R59L+WPcneOX2i5b52t2ZFAWO4aurRwAc0pIlMLLTUvB9QFVK7klpMdXT4nKU9bRZW ml+3kggqJ5onnOkLHE5mVlZyw9LhdJ4J9ydHcW80aujVVhUEGoNfQ9TDbLdzwJeWskb2bDUCyqCF 9SKEEeYKkhhlcdJ3IYStcsSZKOPn9uSSOqqWH+1HQYof9gzn35ozQ+Q/b0a2m52qgAASP6gFV/w1 P5gdB1lcS0IezBz+WkU6z/wZgxv/ALb2ldKGnQxsNwWTTUUHyOP2U62Kf5CPwsq3zu4PmlvvEeGg oKXL7D6Pjq4SHrK2qL0G/N80gdVYU1HTq+Fo5Vusjy1448ak4Jfe59yYkhtPbLapwZiyT3pU/CB3 QQH5k0mcHgBCfxHrp39yf2unb6z3V3e3Ig0vBYhh8THtnnHyUVgVgaEtMCAUHW0NXVkOPpZquoJE cQXhRd5JJHWKCCJfq81RM6oijlnYAfX3ghFG0rrGgyf+LJPyAyfl10PuJ47aF55D2r+0kmgA9SxI AHmSB1xoKZqWmVJG1zyPLUVMn+rqKiRpZbf7QjNpQfhFA/Hvcr63JHwjA+wYH+z8+q20RhiCsayE lmP9JjU/kOA+QA6m+2+lHXvfuvdf/9Pf49+691737r3XRAYFWAZWBDKQCCCLEEHggj37hkcetEAg gjHQPdldw9cfH3Z1duztvdNNtDZuLqcbjqDN5CKvyEuTrMxUmkxO3cVjcVS1+Zze4Zan9mCjpYJ6 qoQKyqxEmk+2nYt15nvo7LZLMz37hmZAQoUKKs7MxVESmSzEKpqCRioT37mnYeRtqm3DmfcRa7TE VVJGDOXLmiRIiK0kkoOAiKzsoDAHuprX/wA3z417Z+f1NtjvH4y9I/JhO+tqUsGEyOTyfxk7J25t DtTYflQxirr904XBy0+7Nqx6nxldJTsaiiaSjc2+2MOWHsfzPde3L3HLXOXM+0jlWVzIFXcIJJLe alDRYnYGOTAdNQCuA/8AHqxL95brbef4U5i5L5A5nn5mjRY9f7ou4oriEHAMk0aEGPUWVghLLVKE hNOsPsnaLzbi/gVdn8dQT071tPVJ99T5LcMeQoHaKegGEnp6Wlx1RTyROJVkilkhMbKfV9M05buz htRc2m3a1IBDMO0g8G1AkEGopSta8eufXOfNu9bbZXU8u2XwuUcK0bxPbxIK0Ot6mRiDQUBQEngO jJ023IdqUcdY7Tb0qzMIaCDO5CixVDTyMrSCSs8tVCKtABZIIdINuRbn2XRXA3O4IlfwEAqdCs5p wooAOn5sfy6h6fn7dt8QbbbuNrgCEyywo88z5oRGQh8MZFXYMR5NXqe0vYmf8MORh+5x8JBpcTj0 xTYajUfpSkx9FLJAgUcAkM3+J9iaz/q/ad8c2icjLsXDn7WYD/N0HYLnlTYhM1g0a3T5eWZWaZz5 l5ZU1H7AQvy6WmJwuXiC/cbfkX6cnFzp/vMIQez2C82tiNG7p/zlX/KeiDcOY9vkroubVv8AbKP8 BHQm4ajgEtPDU44RyzOEihjjyBqJWJA0xU8Zmmkb/gqm3tbPcxxxFor8MAPVD/MdBC4uzfyiG0tY 5HYgYYgCvqdVB0ffp/oTP7ljp56LacVCkgQnJ7kqZJGAP5pMBjllqXt+BPU0p/qPcHc38/Q2LSRt uBNPwoAP2uxA/YrdZR+1fsK+7Rw3tztWuZ6Eu7FgK/woFqfzZfz6NxD8Q2p6VqzI5TP1lY0Dohij pMXiqTWB66fD0NOiStGRwamWpcD6ML39xFP7nC5cQiOERg1ySzH/AG5OK/0Qo+XU7c1fdK5Z5s2K Tbd8s5tdCY5UVUeB6YeOi+X4lcsrjDDzBFu4+r22llpsPurFUU/3SzSY7KikieDJwKQjyEspkWeP UBKpPkQkckFSZS5U5rWaGNo5SbSvctcoT5j5eeMHjg1HXOrmTkvnT2A5nPLHMjtNskpLWtzHXS8a mmpQSSNNQJrdqmNjVKqQXJbuTaVbjpKiox8E+SxxZnGN+7pf4hSoByKOaQk1UYtcRSHWPorH6e5b s+bNtcRW5vhq4VZHH/Gjj/eqfb07ZczcvbpOTKr21yxwwWkTH+koB0E/xKKeq9GG+Dfwe3F82u1Y sRRwZDC9S7SraOp7X3swaOTF0RYTJtPEa4Y4m3luCJCkMZDijgLVMgKrGksee9Pu5tntXy49y0yS 8y3Kstpb0yzcDLIK1EMRNWONbUjU1JK5h/dv9ht+95Oa4rQ20kHJ9myve3daqErUQwsBoeeahC8R GuqRx2hW3Xtq7X2Z1XsjBbR2xjsTs/Yux8DRYXDY6BoqHE4PBYilSnpojLM6pHFDBEC8sjFna7ux YknkruO4bnv+63m57hPJc7rdzM7sas7yOak0HqTgAUAwBQAdd1ds23Z+V9lstq26CK02SygWONQQ qRxxgACpPAAZZjUmpYkknrjgM9tzsGix+5Nt5ah3DthKieXFZfGTJWYfMVdLLLSGvxtdFqpcnj6S RHEM8LSQSy+tGOhW90ura72uSW0u4GivCAGVhR0BodLDirHFVNCBgjJHTdhf7dzDFb7ltt2lxtas THIh1RyMpK60YdroprpZSVZsqTpB6WPtB0dde9+691737r3X/9Tf49+691737r3XvfuvdMWf23hN zQUMGbxePyRxOWx+4MNJXUVNWviNwYib7jFZvHfdRSilyeOnu0UqWdQWF7MQVNtd3Fm0jW8zJrRk ahI1IwoyNTirDiDj9nSK+26z3KOFLy3SQxSrLGWUMY5UNUkSoNHU8CM8RwJ6l0NbJKzUtbGlNkIg xeJX1RVMKsFFbRknW9M+oXB9UTHS34ZqSRhQHjNYj5+YPofn/hGR6C8E7OTDOoW5Hl5MP4l8yp8/ NTg+ROtb87v5YtV8zPkh8pN9/GHF7I6k7K6twvWmE3HU1dLVUFF332jufAP2DuUVWRpp/wCHbLy1 JsvM4SnbJpRyNk66dvvHUBqhcuvbD3kj9vOVuTNu5xlub7Z72S4dACCbK3jfwI6KRqlUypKwj1jw 0A8MHCHB33a9kD7z+4fOs+wwW9p+4Y7VSjAiPcL+eL6l2kIOhfBt5IACUIklclyMsNZHsXrHuDqT fOR627o2lvLZm89vzaarbG7qerSppkdisdXQSO81DlMVVBb09dSSTUtTHZo5GHvO7lbd9g5g2yHd +Wry3ubCUYlhoQaeTUoysPxIwDKcMB1z+5y5SvuR91vtr3jYv3duYNXRkEZIJNCCBR0NKqykqwyp PThhofAVLoENvyVHP+JH0t7GCg0APDqItzk8XUA1ehdwmSSLQHy0tOvHop6ieEn8WaRD5Pz/AGdP tR4FrJXxoYyPmoP+EdR7uVk8hbRt4dvVlDfyOP216M/1RnNtPmKGHObgooqBeHGUr3jgIuP1vVuA RyfqfYO5psbNbKZrHb4jP5aEXV+VBXos5T5Uiv8Amu1G9bMv7v4trRQh4ceA6ui6J2p8ad0LQxT7 j2K1VIIwf4d2OcLVlja5Axu5sfKHJP4F7+8Oudr/AJx25pngsboRCvG31r/xqNh10z9s/Zz2N3KG 2E9hZRXBAzDf3Fs9f+bF3EQfs6PjH8bOrq2iZsDmeyaeHxMUnwHc3YU9KLJ+pVO5chSlf9ha3uFG 533+KYfV29mXrwks7cH/AKtqeskF+7v7dfTn907vzNAlMG35g3cr+Qa8kX+VOqmfmB8bd1Uu5I9w bO3JkNw4unxq0dTjt6blqa7NY+WCaaR5qLK5IGKooJxJqMbsjxyBjdgw05D+3vNMN7ZC1u7NI7gt UGJAqGoGCq8GHyqCKcOueP3nPuzb5ccxW/MPLfMl1uG3R24jaLcbySa4iKsxJjmmw0Taq6GZWRtR 7gw0kv6p6jx24u/es+qe/NyZLpTam/JoqtN3ZXGGmp6/EzrXDGS4fIZX7bGRUG48jj3oKfKv5qOn nbUyuFI9jDmnmG42nlvfN15ds49y3GzFDDHIG0v2lg4Srao1YO8QpIQNI0kg9QH7Vey237t7ncoc ne6O4z8vcv7i2r6mSLSJIjrEZieXTGI55EMMdz3wq51EMFI62Mdq/H/4w9ObewGwOu/kF3qMXXxV OY2v1x1N3NlavLZ6OukkmqcxQ4bq+ipc1W0tZUIRLk5nWlSwElQiINOGG78689817heb3v8Ayztr 3i6Ulubu0UKmkAKhe5YopUcI1Go+SEnPa3l72n9puQtp2vlrlb3P5lO3srSW9lt+6yM8ocktIkVg iSMrNXVMxCDAaRVAoKOG+G/W266ynyu/NlZqsxMUiTR4ntXsnfHc+8MsEd2H8bqt57t3Ttfa0Eq2 8lLiUqKiQf8AKbGpeFg5ce4G72UbwbZuMSzkU1W1vDaRL/pBDFFJIR5NLpUf77OGA9272T5Y3OWK 637Y7h7QEEJf311udzJQ/wCitc3FxBADjUlvrc/7/UakJ3qKio8bR0mOx1JTUGPoKaCioaGigipa Oio6WJIKakpKaBI4KampoI1SONFCIgAAAHuOJJJJpHllctKxJZiSSSTUkk5JJySck9TvBBDbQw21 tCsdvGoVVUBVVVFFVVFAFAAAAAAAoOpPunTvXvfuvde9+691/9Xf49+691737r3Xvfuvde9+691D q6GnrRH5VKywOZaWpjIWopZipTywSWOlipIYEFXUlWBUke3I5GjJ0ntPEeRHz/1VHl0zNBHOF1ij qaqw4qfUH/D5EYIIx0BKYSfqzsXdnYlSoqNsdmQbeG/62jglK4Pc+1Md/AMLvWoplaVocZl9sR0u OyhGpKM42lnFoXqWhEhuF3ra7LakNLyzL+CCR3xyNreIHzZZNTx+beI6/EE1Aj6V+V9+3Tfphq23 cVi+pdQaRzQp4UdwwzRHhCRTHIj8KJ8IZCkjvL43dC/KLaUW2+5evttdg4V4GmwuTqIzFmsP95Fd chtfdWLlps1hpJUZX10lSiSgDWHXj29ynzxzdyFuLX3K+9T2V1WjqDVHofhliYFHpwo6kjyoenuc /b7kf3K2pNv5u2G23CyK1jdh3pqHxQzIRIlRmqOAwpWo6oh7t/kALTVldm/jX3DF9vIZZabY/cNL PIab+2kFFvrbNJI0q3JRFq8PIwFi8xN295ecn/fIYJDa89cuMWFKz2ZGfm0EpFPUlJh8l8usFvcP 7hSXDT3ftvzUiA1K218poPOi3EKn7AHtz5Vc8eq+90/ywvnL1vPItf0dl9y0kRbTktg5fb27qSeN P92R0mJyQzUakC4EtFE1vqB7yQ5f+8Z7ObyqaOcYbaU/huUlhI+1nTw/2SEfPrCnnT7oP3gtikmP 9Qp7yAcHtJIbgEeoSN/FH+2jU/LpC7X2B2fsTc1FSbk613njslHULDJi63auVeuLXAZBRLRS1Dtc fQKb+xlunNPJu9bZO9lzXtzwFahluIqft1AdY7Qche5PKXNVhLecjbulwslDH9LOX+Y0hCSflTPl 1cx0h1ruLdGOoRlfjnmczBMkYMu4+o3gpXBA5as3HgqSmAI/Jf3hzzrzJsNncT/Sc+26ODwhu9R/ ZE7H+XXUX2p2Lmjc9vtBfe19+6FRmfb3Qfm08ar+09G8k+GmGyMCSUvQe3Nq1rqp/iG1s/DsavjL Dk+bZ248XLG6/wDBWsfwfcPv7pG3dgebLi6jH4ZYzMp/5zxtjrJAe0lxcRq0XIUFrMR8UUyW7D/n BMhH7D0pti/DXc20suMtRzYGqkKL9q3cO++wu+6DCSK5YVOI2XVrsLFwVqG2h6nKZDx2Gkg3JKN4 9113K2a1rLFF5izhgsWcejzjx3IPmEjjr5jpdtHsnu1ldpeeDt7SjKtuM93uqxn1S1Is4gw4gyTT UPA9VlfzZviR2juDdXR27J+5cz3D2R2lvnB9LbF6nptkYnblFiqGfH5fNZ/NbahxGTq5abCY+alh lr3qY52p45hJPVmNEVZQ9juftms7HmSwTl+Pb9os7Z7ua5MzSM7BlREkLqKuwJCaSAxWix1Jri19 7v2M5q3ve+RN9ueeZ965l3G+j261sBaxwJEmiSSSSERSMViVghkLqzIH1STlVUC+vo/4/dQ/HTZt HsjqHYuB2ZiYYKda+XGUurK5ysgj0tkc/m6kzZfOVzszHy1U0jKG0rpWyjGDmTmnfubNwk3Hftyl uJyTpDHtQE/CiCiovyUD1NTnroXyJ7d8ne22yQbFydsFvZWiqocoKySsBTXNK1ZJWP8AE7EjgKDH Qzew/wBDbr3v3Xuve/de697917r3v3Xuv//W3+Pfuvde9+691737r3Xvfuvde9+6914i/B5B4IP5 9+690HuQ2HJBC/8AcbcVfsKpMrzinxtFjsntyeaRxJJ91trKQS0sMcz3MhoJKCZ2JJkuT7NI9zDs P3larcpSlWLLIB8pFIJI8tYcD06IJtiMSH9yX72L1J0oqPCScmsLgqAfPwjExOS3QFZ/F/K6Pd1R Llsxt7c/WcVNRpjsd0umM687Bq6vyytkm3KvaU+8cRVUhiWIU/8ACc5hZlYyeRmGj2JLWbko2KCC CWHdyTqa71TwAU7fD+nETA1rq8SGUcKAZ6Bd/be5w3R2ubuC45dCrpXb9FrdM1Tr8X6wzoVpp0+D cW7A6tROOlvBuvrLK/w7D752vurC1wcUlPR9rbYzdZSSzj+z/eSqXO7KyE7k8GLISn+nFvZc1nvE Piz7bewyR8SbaRAQP+aY0TKPtQdGq7hyxdeBab5tdzFLXSFvoZHUn/mq3i27H/Syt8uhsxeFwuGg EOExOLxVMwBEWLoKShgI+oIjpIooyP8AYew9NcXFw2q4nd39WJJ/mT0M7SysbKMJY2kUMR8o0VB+ xQB06e2elfXvfuvde9+690joNhbVj3c2/Z8VBkd5jGy4Wk3Jkx97k8ThKiZKiqw2CkmDR4LGVs8S PUxUiwireNGnMjRoVXtud6bH92LOU2/WHMa4VnAoHenxsASFLV0gkLQE9E0ewbUu7HfpLUSb14Zj WZ+544yatHETiJGIBdYwushS+oqCFj7QdHPXvfuvde9+691737r3Xvfuvde9+691/9ff49+690Tr 5H/zAPh98Rdz4HZnyM7uwPWG59zYH+8+CxGUwm8MtUV+B/iFXiv4kj7a25mqeGE5CgmiAkdHLRmw tz7HHK3ttzvzraXF/wAr8vyXdpFJ4bsrxKA+kNp73Uk6SDgEZ6CHMXPvKPKVzBZ8xb1HbXMsetVZ ZGJWpWvYjDiCM+nRdv8Ah7L+Vx/3lztD/wBA7tT/AOwP2KP9YP3e/wCmKn/5y2//AFu6D3+vR7Y/ 9NZD/wA45/8ArV1mp/51f8ruqqIKaP5dbKWSomigjao2t2ZSU6vM6xo09XV7HgpaWEM3qkldI0W5 ZgAT7q3sL7uorOeSrigFcSQE49AJSSfkASfLra+83tizKo5thqTTKTAfmTGAPtOB1YxsHsHYnam0 cLv7rPeW2N/7H3HTNV4Hd2zs5jdx7dy9PHNLTTSY/L4moqqGp+3qoHilCuWimjZHAdWAi/cts3HZ 72423drGa23CI0eOVGR1NKjUrAEVBBGMggjB6kSw3Cx3S0hv9tvIriykFVkjYOjDhhlJBoQQc4II OR0Xb5J/PD4k/EHL7YwHyP7pwPV+Z3lja7Mbax+UxG68vUZTGY2qioq2sQbZ2/m1poYqqZUBmMZd r6dWlrCflX265052gu7nlbYZLyCBwsjK0ahWYEgfqOlTQVxWnnxHQe5j565T5RmtoOYt5jtZplLI GWRiyg0J7EamTTNK+XTV8dP5hnwy+Wm8Mr1/8eO+ds9lbzwu3p915HbuPxe68NkYtu0mQx+Lq8rD Hufb+EStpqWvytNHL4GkaMzoWADA+3uaPbLnvkuxh3Lmflya0sJJRGrs0bLrIZgp8N3oSFYitK0N OmuXvcDk7mu8lsOX99iubxIy5QK6nQCFLd6LUAsAaVpUV6NlufcuC2XtrcO8d0ZKDDbZ2ng8tuXc WYqvIaXFYLBUFRlMvkqkQpLKYKHH0skr6VZtKGwJ49gy0tLi/u7Wxs4jJdzSLGijizuQqqK4qWIA 6FVzcwWdtcXl1IEtokZ3Y8FVQWYn5AAnqs3/AIey/lcf95c7Q/8AQO7U/wDsD9yx/rB+73/TFT/8 5bf/AK3dRt/r0e2P/TWQ/wDOOf8A61dWiUNdS5Oho8lQzCooshS09dR1Cq6rPS1cKT08yrIqOolh kDAMARfke4ikjeKR4pFpIpII9CDQj9vUmxusqJIhqjAEH1ByOiz7n+bPxF2dkM1idx/I7qDH5Xb0 lXBmcYm98LXZGiq6FWNZQNQ46pq6qbJUzo0b00aPOJlMWjyAr7jPcveL2r2me8tdw9wNqjurcsJE +ojZ1ZfiXShYlxwKAFtXbTVjqZdn+737479a7fe7V7U77LZXQVopDaSojq/wvrdVURsCGEjEIVIf VpNemranzz+Gu9IsLJgfkl1QZNwmnTF0OZ3RSbYy0k1W4ip6arw25/4PlsXWSyEKIaqGGXUQNNyP aXbPe72k3hbNrH3C2vVPTQskywuS2AGjm8N0YnGl1Vq4p0t3r7tfv3y++4LuXtPvem11GR4rdriM BRVmWW38WORQM643daVNaA9OO/Pm38UOsN3ZrYe/+89kbV3ht2eCmzeAylVWx1+NnqaOnr4IqlIq KWMNLR1ccgsx9Lj2o3v3j9sOW91vNk33nSytt2t2AkidmDISoYA0UjKsDx4HpLy193r3q5w2Pb+Z OWfbncb3YrpS0U0aoUkCsyEqS4OGVl4cQenXsX5hfFzqbcuO2d2H3z1ntndOQz1PttsDVbnoKrJ4 XKVMElRE27qXHSVkmyMUIoyXyGY+xoIyVV5lZ1BU7/7se2vK+42+079zvt1tuck4i8IzKzxuQSPH CFjbpQZln8OIYBcEiqLlX2J94+dtput+5W9tt3vNmitmn8Zbd1jljUhT9M0gQXclTiG18aZgCVjI UkGAxGXxOfxePzmBymOzeFy9HT5HFZjEVtNksXk8fVxLPSV2PyFHLNSVtHVQuHjljdkdSCCQfY7t bq1vraC9srmOazlQOkiMHR1YVVlZSVZSMggkEZB6jG+sb3bLy627crOW33CCRkkilRo5I3U0ZHRg GRlIIZWAIIoRXopO3f5gfw73b2rR9Kbb7wwGZ7GyWdk2zjcTRYXeEmIyWdjd4hjcdvI7dXZVdNPN GY4TFkXSeUhIy7MoMWWHvr7TbpzNDyft/OcE3MEk5hRFjnKPJw0LceF9OxJFF0ykMaBSSQOpv3X7 sXvvsnJdx7g7t7d3NvypFbC4kkeW1EscJAPiPa+P9WgAOp9UAKLVnCqCQKuV+SvReF3nh+va7sfB tvLObvyuwqPBY+PJZiop93YLALunM4bNTYihrqPbc2M27ItXPJkZKWGOF1JcalBE117h8l2e72mx TcwQ/vaa7e2WNQ8hE8cXjSRyFFZYikRDsZSihSKnI6Bdl7Se424bBf8ANFvypcDYbaxjvGmcxxK1 tNMbeKWISujTiScGJFgWR2YEBcGiKf5xfDhNwQ7aPyf6LORnxUuZSpTszakm31pIqpaRoZt2R5Nt rU+VMrArQSVi1zxXkWExguCc+83tKL5NuPuRsv1BiMlfq4DFpB00M4fwQ9eEZkEhHcEK56EC/d29 +W2x93Hs9zH9KswiKmwuRNqK6qi2Mf1DR0wZliMIbsLhyF6Yt7fzAPh115u+t2Huvvba1HuzHS0l PWYnHUG5dxtFU10MNRS0q1m28Hl8fNVSxVCftJK0ilgpAbj2i3j309pth3WbZNz51tk3SMqGRFml oWAKjVFG6kkEYDEitCK9GXL33ZPffmnY7fmTZfbe8k2SVWZZXe3gqqEqzaZ5onCgqe4qAQKgkZ6O J7lnqCOv/9Df49+6918+f/hRr2Ed6fzLNzbbMgcdR9PdT9ehQFBiGSxeQ7W8bEEliT2cWubGzAfQ A++ln3Xds+g9qbS6p/ubfXE3+8stv/1g6wE+8PuH1nuRc21f9xLOCL9qmf8A6zdE++DH8rb5N/zC cB2DuXoeo63ocT1tmMHgs9Udg7ly+3fucjnqKvyFNDiP4btnPpWfa01AWqNTRGPyx8HVwN/cL3e5 T9s7nbLTmJbpprpHdBDGr0VCAS2qRKVJxxrQ+nQQ5I9sOZef4Nwudia2WK2dVYyuyVLAkaaI1aAZ 4UqPXoAPl58Q+5fhF3LX9Gd50GDpN40mDw+5qSr2zmFzu381t/OrUDH5bE5A09FUtTtU0VRA6T08 EyTQOCltLMJeSedti5/2KPmHl6SRrFpGjIkXQ6OlNSstSK0KnDEEEZ6IebeUt45K3iTZN7jQXgRX BRtSMjVoymgNKgjIBqDjrZH/AOEsvZe/Zs98q+oJsjX1nWVBhNh9h0OLm88uOwG9a/I5Xb1dVY9r /b0VTunC0kS1Kn1VAxUJW3ie+LH3v9p21bbk7e1iVd2aSaEsKBniCq4DeZEbE6f4fEb1HWRn3X9y vzPzTtBkY7aqRShTWiyEshI8gXUCvroHoeiYf8KW+wxuz+YHt7Z0FQGperOgNh7eqKVREfDmtxZ7 eO+Kud2W8okqMPuPHLpYgBYlKqNRZh391LbPovbW5vmXvvNymcH1REiiA9MMj/t44wDfvIbh9Xz9 b2at22thEhHoztJIT+aun7P21S/A35TZn4ZfLHpr5C4z7qfGbM3RBT72xNI5Emf673BHJgt9YZYy fFLVVG3K+eSj8gZIq+KCWxMY9zH7i8oQc98mb7yzLpEs8JMTH8Eyd8LfIBwA1MlCy+fUWci80Tcn c1bPzBFUxQygSKPxxP2yr9pQkrXgwU+XX0Dv5p/cWH2x/K6+VnZu3MvSZLAbz6Dqdu7fzdBJTz0W UxPeRxHXWIyFDPMVjkp8lSb8jeGRf3LSBo/XpHvmt7P7HPd+7vJ203UDJcwbkHdDUFWtNU7Ageam EgjhjOK9Z8+6G8Q23tjzTudvMGgmsCiMKEMtzphUgnyIlFDxzjNOvnLfHfr0dt/IDozqkxecdm9x dZdemHWkfmG9N64TbZi8kiSxx+QZK2plYC9yD9PfUPmfc/3Ly1zDvNafSWM81fTwonf/AJ96548v bf8Avbf9j2qlfqbyGKn/ADUkVP8AL19WDsnPHavXe/dzrOaZ9u7M3Pm46gUWWybQyYrCVtdHImNw KSZ3IurwArT0StVzH0QgyMo98UN/vl2zYt53J5Ci29pLISEeQjRGzVCR/qORTCR97HtTuI666cq7 cN35n5c2po9a3N/bxFdccdRJKiEa5qQoCDl5T4a/FJ2g9a1nXu6PjT8b9rV/Z/aOJp+38/tPC1eG 646Kxfxu351V1HNks9lqiauq92djdr7W3lunf25JaeunmpqzcNRU/ZIhjhilaOmeHn3sm6e03t9b ScxcxxzbobWIx21guzT2loWlclmlnvUlkupqMxR7udtAFFVisZTq9zXae6/uru1vyjyfePsW3Xtw st9u8m+Wm47kEhjUIttZbdPaW9lACiLJFZRx+KTqd0DTLI9d0Yrqnuzvzr/BfH/ZCRddfIBts7a7 Y2H2X8ct77e692Nm8bX7Yj2lP11vLZu29mb92XPubII611RQVdPjjKrT10zUkzwRruY7bkHnPnba rHlPbbhNj33wYbm2uNmmS0gkVohCYLiIWt1amVh+o8L+EW1PO3hMVCHkDeOcvb/225j3D3K35m5q 5Z+on269sN8tZr27ikS4Nyt9a3U11Z3YgQgwpNE84UiO3QTxrIz9L3Z8g2+ZW6flMNo9P4zrbLfK 7bvwkyuxd0UuT3Dvui6r6+hq94dm7vo5mwuIoMFnqDHU8mUniaWXw5Oojp5ZGgppDMevzduR90dy 9zfDhj2uXmKPl57Wa1SSZYLVTcXUiv4yeHpAaWRyCySsqMjKjBitOSfbAewuzezZ3jfZea4OTp+a o7y3eOC0fcb0rbWFs6+JK80LuVt0YKuq3RpUUSSror52vkOz81i8Fv8A3f0D8Vt0bi2Hkt2b83dt jem6d1L2b8k8n8uxWU/Xa0EB6ayNZvKTZRrTVYmCirJ0oqwiol8cisFhXbW2e8tbTfd02Hb7m/sZ JrmaG4gX6zdn33ULXSKs1wbfVrgWORhFJ+o2lgQMm94l5RsLvc+Wtj9x+crLa9yhtbO1ntYLf6DY o+WtDXuo/vNEtRd6BHcvLEhlirEmtSCdgD5Xbf3F0j/Lw2P051hSZjZXYO4W6c6X2Zt/bnZmRwy0 m8975jG0eW29XdhptXK57J7bUzZBal6fHU9XkadNCmk8hkizM9x9uh5O9k9m5P2iW9sLm4ey2+3W 3mpKJrh1UxtKe5ozWQS6SrulQrLWo5p+zW87Zz996HmDn7nCW33Hlq2/ee6XU09hHLqtbWJ2jmSy +ojhjnxCYw8zxwOdRE2gK5LPkPsj5d7L6d6E6P3vF8F8dsLAd4dKbR2Ft747br7q2p3htjdMe6YM bQ5zrrM7yTceJG7se9ZUy1VTkaCpMjzSzyjzkP7jbn/YeY9n5R5L5N3fceXY9ng3iwgtItrS5h3C K4EwRJLaSe7lQTKWYySSRSHud2UvQ9T77Y80eyO989+5PuJy+fcSbmW65f3W4vJt7g2q52m4tzbl 3hvorUQSfTOFjWOOCaPSESNP0wV6BfovObrq+zqrtuGi/vAMFsv5/fLrEVtBQVnZ+ayFX2Tuui+N XXVRV7Xq6bbUe9VWm2VJPNRyV9EskXnZZgsk8igHlG8spN+l5rs5r26mgtOY98jP0yXLP9XMu0Qs 0fjL45X6clYyyCRNbF4wz0HnuJFssfKEPJDyfSi4vuTeW5Ud1sIkSwgffb1UuFM5tCWugqyrDKVb wwYyUjUlt60n7Uzm69udXZjZ25KHZmwe29ibuTe8/wAO8VW76y1XkKiv3ruDbneElX2BCdudYY/B 5RKhMa2RytFWbfhWWWmp4IAksd7DLNeXm1cuS7duq2dlusE7TPy7B4zMxa4aK/c3xZLMRPrMLM8b WyhjGESjStzXc8mWGz7tzhY7vbSb9ueyXdqbQczyJZxKipawz7SFsj424PLGUM4gt5YrxmRJZJJC yHy+EtX8u8Buj4lbd293Fsfa+zfljm+9Pkl27sSi6xweay2z9s4LdEVbTQUO8sqy5bdlX2nSmGgW rlgxI2+raoo8h4NDzj7SSc52O4+3e37Lzt4G1czy3+7T25262LxxRzBnDztM8hN0KRxuB+iMgNpo ccfvAN7H7ttHvPum6cg7jeb/AMmW207Ftl4+4TRR3M8tuUZntYx4duu3tqmMavc/WkUdrbxNS7GP vOfrlr1//9Hf49+6918vj+aB2Ee0P5hvzG3aJBNAO/N/7VoZ1ChKjF9e5eXr/E1EekkGOoxm2InU mzFWBIBJA64+0e2fuj2y5GsqUb92wyEejTL4zD8mkI65le5u4fvP3A5vu61X6+VAfVYm8JT+aoD0 Yb+Xx/OG7o/l09V7w6r6t6n6k3pQ717AqewMtn9+LvR8ytVNtzb23KfEU67f3ThsauMoYcCZoyYD OZaqXW7KI1QMe5fsfsPuhvFjvG77ze28lvbCFUh8LTQO7ljrjZtRL0OaUUUANSRDyB7vbz7ebXeb Xte1WkyTXBlZpfE1V0IgUaHUaRpqMVqxqaUoT/5bfLft/wCe/wAgqrunu/MbYxu4s9Dg9o4mlxlJ WYfY2wNo0FXP/DcNjYHlzeYhwOLqcpU1lRLNLW1cktRNIWdmCgb8l8l7J7cctJsPL8Er2sZeRixD SzSEDUzHsUuwVVAAVQAoxSvQR5s5s3fnvf23ne5oluJAsahQViijBNFA7mCqWZiSWYksc8Ot73+S x8GeuPhr8VKfObU7H2Z3PvLv+bFb63z2r13k/wCMbDzFJiYK/H7V2rsvJARNkNvbOFdXqaiaKGqm yNZWGSOFRHTw87ffn3C3TnrnFre82uewsdtDQxW8y6ZlLEGSSVc6XlonaCVCKlC2WbOX2a5I27k/ lZZ7XcYby8vysss8TaomCghEjPmkdWyQGLs9QMKulr/OE7D/ANJ38zH5hbiE61C4rtWbrxWURBY/ 9EuAwfVrwBYfQGp5dnMjf2i4Jf1lveePshtn7p9qOR7XTQvZib/spd7iufXxa/Zwx1hr7u7h+8/c nm641VC3Xhf84FWCn5eH/nz1XpmNr7h2/QbXyebw9fi8fvXAzbo2nV1kDQwbg29T7j3BtCbMYx2/ 4E0Ee59qZKhMg4+4opV/s+5Ngu7a5ku4bedXlt5BHIAalHKJIFb0PhyI9P4WB8+o/mtri3S2lmhZ Y5o9aEjDoHePUvqNaOtfVSPLq9HdX8wcdn/yJIfi7uLNPVdmdX/Ibqrp56WokSWtyfSkuP3x2p15 lS9VMZZKPbWR66kwBWmT/JKehoFewqLnHqz9tP3T94hubrW307Td7ZcXNRwW61RW8y4HGRZxN3Hu LyEfD1N91z/+8/Y0csXE1dytdwgt6Hi1tSSeJs+SGExY+ELHX4uixfyTuuz2V/M8+KmLkgaWi23u zcfYldIGVVpR13sXdG8MZPIWjlJV8/iKOIALcvKougu6iz383P8AdXtJzjMGpJLCkI+fjzRxMP8A eGY/YPPgQ17L7f8AvL3M5WiK1SOV5T8vCieRT/vSqPz8uPX0aOzo+zpdjZ6Ppup2PR9kulAu2qrs imztZsuBjlKH+KyZmm21UUualIwn3P2whcD7vxGS8esHkfzIvMjbJfLyhJZJzEQvgm7ErW4711mQ QkSH9PXo0n+006qrUddP+U25TTmDbm54i3B+VgX8dbFoluj+m/hiJpw0Q/V8PXqB/T16aNpPRHa/ 4L7u74qpsp81+6avuKnp8VmqDanWewMIOuurtkZLN4utxD7tpaJKrIZLdG88RTZCY43IZG7UTSH0 SAKFhWf2T3XniV7n3k5xbd41ikWCztY/pLK2eRGjM6rqZ5riMM3gyy5jJ+FsUyAt/vB7L7dwpZ+w 3IibHK00T3F9eS/W390kUiyC3ZyqJb2sjIvjww4lA+Jamq96M6e+XXTG49r7Iynd/W/a/wAedvU0 uKpZN4bHy2K7pxW28fip6fbOEocrt3I022cvU4+ohpYJq6vWSSWmEj+PyaEU95K5S91+T9w2zZbn nTbt05At1KA3Fs6bgkKoRDGrxOIZChCK0soJZNR06tIAd9wed/Zbnra933+05A3TZvcy5YSMLa7j k2uSd5A08rxzI08aupkdYoSFV9K69OpiRnL/AMun5a7kqMlt3I9odD4fZVH2L3vv3bucxtFv7J73 zGT+QkU22915velFU4/GYRs3tzZtfUHDiinQRZAp5ppYlBEKXf3ffdTcZLjb7jmXY4dmTcNzuYpE W6e5kfdAYZ5LhSiR+JFbs/geGw0y01uyjrIKy+897M7VFa7nbcpcxT78+17RZzRO1mlrHHsxE9vF asryS+FPcon1PiodUOrQiOel5jP5avbGM3N1V3HD3ntQ9wdI/wBz9rdY7equu8TkurcD1JsqCqxO K2VX1FXQ/wB6s7uI4qqef+8EwWsgrJZGhjSUQ1UJ5bfd05ptty5X5uTna1/rbsvgQ2cTWiPZRWNu GjS3YsvjSy6GLfVNSRZGYoqtolQO3X3qeTbraecOR5Pb68/qTv8A9TcX8y3siX8243RWSS6RVf6e GHxFCfRrWN4lUOzJrhc6Py/6H7F7x2/1JP1XunaW2969Pd2bO7mwkO/cdkcps7NZDaFHmoaGhzFP hx/E08VXlElSSEhlCuFKSFJY5h92eR+YOdbDlV+WNztbfedo3m33CMXKO9vI8CyBVkEfeKM4YFc4 IBVirLBPsn7icse3+5c5x837Re3Ww73sFztkps3SO5iS5aIu8Rk/TNVjKkNgkgkMoZGLZtv4rfI+ l7FrOxs51h/Liptz5Sr3Pm8lvbbHV3bUG/jujPUuTqTn6HP5PP1D0WVq89WLJU1i/wCU+KSUo2th eOtu9sPcOLmCbmG95a9vV3KVppHuIbO+F140qufFWV5TpdpWBeQd+kvpNT1Ke6+7/tdNyxByvt/N vui20wpBElrPf7cbP6eFo18F4UhUNGsKlY4z2aggYaR0HO2P5cHbeP6r7R2nW736o25ubsvaOwel KOPY9Fvt9p9edGbf3LW7n3jRbel3XXZnc+d3ZvHIV0jSff1Apw0khMnqUIH9t+7zzXb8sczbVNvW 12+5blaWu3KLZbkwWu2xTNNcLEZ2kmlnuGYk+K2ipYlsigo3b70XJdzzfyjvMGwbzdbTtV7eboxu ntBcXu7TQLBbPMLdIoIbe2RFC+CmuiqAmCWTWQ/lv/Iuq21hcxR7+6UxnamU7B7y3TvaOkh33HsX C4btbp/HdP7Yx2xpBQfxutn61xNHPPjhXwwgzVY8skqQslQWz/d59wJNus7uHfdmj5nlv9ymuAou RbRx3tglhClsdPiMbNFZohKq9z9zMEIkNbb70ftjDut/Yz8ub9LyfDtu029qWNobuWXb9yfcp3ux r8JBfSMiTGFm7Y+xULhozv8AVHxWy3WPfeyd8w5bBVvW3VfxH2l8bNhY8tV/3qky2K3NS5ncO7sv RfwuLD0UuXosXTRGWnq5ZZWMmpEBJkmjlf2wuuW+edm3tLqB+Xdr5Ug2i2Tu8cukyySzyLoEamRU QaldmY6qquS0Ac4+8FnzZ7db9y/JZXEfNW8c6XG+Xj9v04jkgaKG2jbxDKwjeSRgrxqqjTRmNAp2 vczdQJ1//9Lfc3PuCg2ltrcO6sqxTF7ZweW3BknXTqSgw1BUZGsZdRVbrT0zEXIHtRaW0l7d2tnC P1pZFRftYhR/M9MXNxHaW1xdS/2USM5+xQSf5Dr5IW6dxZDd+59x7syzI+V3RnsvuLJtGuiNshms hUZKtaNf7KGpqWsPwPfaWztYrK0tbKEfowxqi/6VFCj+Q65P3VxJd3Nxdy/2ssjO32sST/M9byv8 vf8Aknfy+Oz/AITfGbs3vP49HefaXZPU+2+wtz7mbtfvXbhyi73ik3RgpP4Ltnsjb2BohT7bytHC BTUcUbiPX6yxkbnx7l+/nuXtHP3Nm08vczeBs9revDHH9PaPp8I+G/dJA7mrqx7mJFaYpQZucgey /IG58l8tbnvnL/jbpc2qSu/j3KavE717UmRRRGUYUA0rmtTqPfzE+qekuj/mt8hOp/jpm48905sj ekOI2lVQ5qXcUWOmO38LWbo2umcqJ6qpyq7M3hVZDEeaWWaZ/sbySO+pzmn7Ybxv/MHIXLO880W5 j3y4gLSAqE1DWwjk0AAL4sQSSgAA14AGOsTvcLatl2TnPmDauXpvE2eCYLGdWuh0KXTUSS3hyF46 kk9uSTnra3/4TC7r3TJ8Pe/8fuLIVH9wNn95zT7Znr5SaHEVFdsPb+V3lSUk0shFLRQBaOskiULG ktVJLy0rn3hx97azsxzvy3Laxj95T7eBIBxYCZ1iJHmT3KDxIUDgB1lP92e6ujyhv0dxIfoIb4lC eCkxI0gHoB2sRwqxPEnrS37b3zUdn9q9m9lVhc1fYfYO8981RkSOOQ1G7dx5LPzmSOICKNzLkDdV 9IPA49547Lt67Rs+07UnwWttFEPsjRUHH/S9YbbtfNue6bluT/HcXEkp+2Ryx/w9bPX8xf8Al8rJ /Ji+B/fO1cKw378b+leu8h2JFFAHyFR133nSY7d+5I6lqfmpOxeyd0xTIuhkgpK6vmMllYtiT7X+ 5ZHvt7i8uXk/+67db+ZYM9omtC0aUrw8aCMg5qWSNaZFMl/cPkAH2c5G321h/wAf26yiMuMmG5Ak etOPhTOD8laQ19dUbUwUpqOlirFbnSWUMFYj6EqHNj+Ln+vvMj5+fWLHy8utj/8A4TGddncfzf7Q 7AqYDJQ9b/HrcMdLMrKPBuPee89l4nH61aNy0Uu36PLjgqwYKbkXBxa+9nuf0vt/tG2o1JLrc0qP VIopWb/jZj/n1kV92nb/AKjnbc79l7Lbb3ofR5JI1H/GBJ1tN/zIe9sT091EYd14r5V4bZOSnxFd uLtv4tZTD7a3LsqWPc2FxWDwlRuXKmWogl3dl8lFTinpIJZZ4wyOUR/VyA98eYH2nlsWktnzHHts rI0t5tE9vbTQFZUVIzLO6keMzBdMasWAKkgNnsb91P27u+d+d/G2i+5Ln5ghWRINt5hjluLe7Bt5 ZJZRBEApFtHGz65XVUajKGZcUg9/d2ZrblNn9sdCb5/nXZLszae313rvmLuXN9o4DGdabGRZqkbx 3TtHCdeSbjqcHVQUU4SeqqcNQIEaRqpgjIcS+d35msYLmy5F3r3Vl3+GLxpvr9x8OO2hyfFkhjQy uhAahZ4Ix8RkIBXroZ7Z8i7Vus227t7l8vfd9h5SvLn6W0O1wWE0l/dmi/TW9zNeiBZVLJVI47qY 1CiEFg3R9ZP5gyVvwMx++Nu717kxUeEquvtk0HyF3t/oy643h2vuunwOc3X2fLsXCdt17YPdEO1q jAHDVAo5MnVVlVLJHRidoDPJNE/ufvR9n7aexvN1S7h+khXcpZNugnu5fDklu2hS6maFxC0fgNRp HdmYRB9HiNjUn3aI7f7yF1sO67HsE31KXt0+y2v7wvrXbrdporbbxdzbagmtzcLN9UniLBHFGqNO YxII1JL0z8r/AJIbuqt1UeP+Q/cHZWb3/W7yzu1NjbT76+KtZueq2xJtKoqsVEu333XX762bnsPi aOSuyNFt+jx60LQSPHDFMsknuGOWObPdy8k3aM82bzfXN5LO8MEO57IXMRhPhjSbhp4JEUGSRLVY lQqWRVYM3WQnPvs77Q7LFss0/tlsG02G2R2sNzd3Oz8xLAtwLkLKfGFslpdQyyMsMEt7LOZg6q8j xlE6O78X/kd3bubpjaXyd3kPkPjesenviVvbcmQ3NuTeOztw9Tdr57rTa256ap3LmsMKGp7ZzO8M zlBJNpq50kM+PVWLuqiSXvbzmb3Duth2nnLe4t7i2va+W5mZ5byzmsb2e2hlXxZFBa7eaRzqJkcA NGNTEgase/eD2u9udq583v2k2B+VpubN952tIEggtbqDcttgv7i3YQRS6l22K1ijotY0ICTEgKpJ StiD5x9lUWwex6F/kN8xKDdO9tvfH7ZNfj8/g91Z3sGDufsWm3X2Jlanp3aU+4+vM5tLaeQoNu47 H0dTh2nJx+WhL0korqVkg9OcfcSHZd/tzznzMm5Xtrt0LCSVJbhb6fxrmZrKP6u1a3hIjiiRoWJM UwPguJFKZYS/d/5LuOZuVLhfbLkOXZ9vut6u0eGW3hsm2qya2sol3S5FvexXNyjzzzyR3QX9a2cL On08wYwXRvyW+T2Q+THR/TXePYfye647P7S7vwfblR1zuzqXfO3ttVm1IqnL4qXZWHzm4++MBIvT 9LhaOsnloU29LevgLVUdeaZQwu5O3/3el535U2PnLe99st2vt6jvZLeSLTCYQXQ20btu6N9CIw7G JbRqyisiz+GKxl7i+1Xs1a+03uFz17d8scn7ryns/Ls22Le2+5Wk1wtwVjkF3LDBs0wO5tK0SLMb 1aQuBC9t4xoeL507NzvUAxUPX3yz+Z+Z+RPyM7FqtudE9NYXtXAwbTfcGayf8Ry9XJhsT13DW7e6 s6+xlYXqJmq4IKKnEEUlTEjNMkr+73Ku9bFA8vLHuZzbPzvvF4yWNkt/BHbh5H1OdH06MlpbI1SF caV0KWAJcY8fdz5i2rndrpuavZTkC39ruVtrWfd90l26ZrnwYo9ESiWS+Kz7jeyLRFEbvK/iOsTs BGxiNudlfPfZ+3NvdXUPxNbfea2xSY3Z0vfvYnyJ6zp9v7xbCJHjarszNbZwQrt9xU25UpTWrQ+B shEKhUmLSq5YX7fzD74bTt9hy1D7XfW3lsiQHc7rdbQRT+HRDdyQx6rkCbT4gj0mVdQDksGJi/de Uvu077uu6c5XHvYNt2+8eS6GzWOx37TWvikyLYRXE2izLW5YRGbWIG0FowEZQA++f+8ctX/IX+XN 0FQZ7J4+s7I77qd8bnpMDUZehp8ttzqmnwFfm8fkhQTEJispjM5XKkdTIUcRsLsVPtD71NvG5c4e x3KtjcukVxvf1N14chjDRWgjLoy6wzI6vKNPdwNfmJfuzbNt1p7Y/eo9ybvboZItr5aFpbNMsTtH PuLTJE8esf2kckMJLRgEahwBHVrvvI7rC7r/09wn+Z/2B/ox/l5fMbdiyeGc9BdgbWoZwbNT5PsD Dy7AxdRGdSWmp8juaJ0+o1qOG+hkT2k2z97e5vI1kRVf3lDIR6rCwmYfYVjIPy6A3ubf/uz2/wCc LqtG+glQH0Mq+Ep/IuKdfL399ceuZXQoU/bfdGQxlNs6k7N7QrcPLR0+Co9q0+8911OMlx8cSUlJ hqbBxZJ6V6NIEWKOnWIoEAULYAeyl9l2GOV759ptFnDFzIYow1eJYvprWuS1a+dejNd23mSNbNNy umhIChBI5FOAULWlKYApTow3x3/l1/NH5Q7pwu2uqPj12XU0eXmplm31ubaed2l1rg6OpCS/xPOb 8zuOpNv0tMlI5nSKOWasqo1IpoJ3shDHM/ufyHyjZz3e88zWgdAaRRyJJO5H4UhRi5NcVICqfjZR noQcve3vOXM91DbbVy/clHI/VdGjhUH8TSsAgFM0BLMPhVjjrebp/j1tT+Vx/KD7z692tlY8xn9h fHruXdO5t6pSQ0R3n3Ju7Z+UpRnmpKmRkgxwz1RQY6hicyTR4ujp4380ykyc925mvfd73t5e3O7h KW1zudrHHFUnwrWOVToqOLaA7uRQGRmI0qcZvLy/a+2PtJvm32soe4g2+4d5KAeJcSRsNVDwGoqi g1IRVBqRn51+0tt5DeW69s7QxK68ruvcOF23jEtq15DOZKmxdEunUt9VTVKLXH+v76eXt1FY2d3f TH9GGJnb/SopY/yHXPa0tpLy6trSIfqyyKi/axCj+Z6+sbmupdi7k6iyXRm4MNHmOtsz15U9W5bB V2iRMhs2s2621qrG1DJGiapsO5QsqrZjdQLC3GiDetxtd7i5htpym6x3QuFcfhlD+IGH2NnrqpNt Njc7TJsdxCH257cwMp84ymgg/auOvlsfLL48bo+J/wAkO4fjxu7yS5Xq7emSwNLkZEWP+P7cl8eT 2huiKNeI6fdG1K+iyEacMiVIVgGBA69cmcz2nOXK2x8z2VBDeQK5X+B/hlj+2OQMhPmVqMdcw+a+ XrrlXmLd+X7upltZioP8SfFG/wBjoVcelacetqn/AISv9dmj67+XnbEsBYbj3p1f13j6lmUrGdl4 PdO5cvBCojDKZxv2haQlmDeNLBbEth598Hc9e6ck7Mrf2UFxMR/zVeNFJ+zwXp9p4+WUf3Xtv0bf zbupX+0mhiB/5pq7sPz8Va/YPztS+fGA7B+SmR3Z1piqDE7S6I+NGFm7X7i352fQ7wptgb03VS7X gztDs/Gy7GH98s1i9nbCzdZlcjJibyrXeGmDQ1CxOeQvvpYb97i3G68uWsEVryRy5Cb6/ubxbhbW 4mWESLAhtv8AGJEt7aSSeUwZ8TRHVJArHr993LcuWvau12bmu8uJr33D5rnG37ZaWD2zXlrbtcGJ 7lxd/wCLRSXN3FHbwLcUUxa5aSRF1FYvxr/l17l+Rzb83ztjBdF0vVp3bQ7S2/nMtB8k8HBPQ4rF 0jZ3dvU+Jz+5aHcVbBVSZLVfdAq4GyFP40hhhWaE42+3X3f9x9wjvm97bZbIvLP1awRSON3jBVEX xZ7FJZllYMXr/jmtTKmkIiB06yy90/vObV7Xjl3l/dtw5hfm76J7maKM7HKQ8kjeDbbjJDA8KlQl P8Q8NxC+pndyj9HD31gt99gfCf4kbKy3SncMeZ6Vrqt92Q7e6t643nhcPmegqjO9azUW8sDv3ce2 qWtxuZqMe9edEk9LWrBIKuGXUhWW97sd8372a9qtmuuTd2F5szt44isrS4jjk2wy2ZW4iuZYVZJC hlwWSQK3io1RSEOX9w5e5b9+veffrPn3ZDYb9GotzNf3trLLFvAivg9tNaQTsrxK4hyqSRF18F0o aoz4L4b5OU+16bfuB6IXdG7K/b+5dwbVk3/1J01sLYFVWbr3TTbbMlJ3LSVo7Pp8ZiNn5qpq3xNP i6damGmqKKJQjLIxP7J2fuRHtke+2PJAud0kt5pYDdWO32tqzTziGq7grfWBI7eR3MCQqHVJIVAU hie/eDvvaeTd5eXNx9wzabNHcwQ3As9x3O8vFW3t2no22Mn0BkkuYo4xcPO5R3juHJYFQgOt+vN6 9ZfD35J9R7nm7Tr++chvrb/xai27U4Xcc+x9jbAfPZreuZ3Hs2aKh+1rNjZvZWP3Bma/LNGivBTQ AiOKWOSci5d2DeeW/aX3E5T3J9zk54kvotlERjlNtbWviyXEk1uQtGtpLdbq4lnIAKonwqys4k5o 5m2Hmz3u9rOdNpj2iP27j2+bfzMssAu7u88GK1iguQX1LdxXT2dtDbgkh3koWdGWMNqXp3J7ywdP vY9edp/ICCfvLsXK7X3buTpP5D1FPv3qLbe0dtdX9bZOrzfSNNgNybOyNFWbWnqYcYWpWFNFTeRQ A0XsOx8o3O72Ue8/uDc9+Rt7u3hnm27dSLmxighs7R2k24RTW7q0LOsNUOhY9QABXoUy88Wmx7hJ sI5m2jluReX7KOe3g3TZlNpuU9zPf30axbq00FyjLcJG04Eg1tLpJJD9Gm+D3VGNHzSxGdbqXC4a HYPTe463MU2KpvkNOer9857J4iPC0+74fkI246/Db7ze1aqc0VFjq2ndaJ5nlTyI6CTfZbla3HvF aXp5VhhSw2iVpAg3U/R3MrxiMTjdfFaO5kgZvDjikUiMuWGoEdRD94DnK6PsRe7eOc5533LfIEia RtmH19pDHIZTbHZvASW0iuFTxZZ4nBlEao2llYrPoL5ddBVXdPZ3yZ+Tm6d17S7fyGQynXXWHWeS 6l7ezY6U6kw1bLHT42OswGwMrin3du+raSqys0czspYxr4lllhU35F91+RJeceZfcf3J3O6tebJJ HtLOzexv5P3dYxsQEDRWrp487VedgxIrpGkMyAj9x/Zb3Hh5D5T9qPabaLO95Jijjvb++Tcdti/e m4yqCzlZryOT6a2XTHbqygGmo6yiOXfqLN/HTJ9ydYJ1p/MS+dm8d1zb9wk0exuzB2/uPY29aUVf mrtqZbH5rp3am3cVj8xCrRSVdROsVHCWdAjqkkavlS99vrnm/lpeXPvAc73m6G+jItrz6+W2uF1V aB0ksIIkSQVUuzBY1qRpIDKi50sPc+05H5tbmv7snt5Y7Ou3Sg3dj+7YLu1bTRLiN4tzuJpHiNGW NELSNRW1KWVjN5zCbK7H/mb7JyMW9ap94fHn4/5rKTbDG065qKnffFVkMHNnJN7fxP8Ah0dZU4jf FMkeO+z8zRxvL5SvpWSb2y2bmH7yOzXC7yx3bYNhkc23gNpBuWaMym416AxjuUAi8PUQC2ojAifb 7/fuV/un7/avsKDZOZuZIoxd/UJrItFSURC18PWVWS0kJm8TSCypoBybHPeQnWL3X//U3+PfuvdV g/KL5x5/pvuvefWmC3/8XNg4nrzp3aHY2Wm783FuXHbi3juXdWa3zCuzdjYvbGUiyFbLQ4HatLUT PDQ5CeJ8nDeEq6B/de6FTGfPnqjEYrbdP25h98da70TqjYvaPbeJOxt5bj2t0pT742vWbgxuK3/v jEYCXCYSvyNXjZaDHUlQYslka+SCmipTUyiEe690t6b5p9JVOK3JVhezqbcG19x7W2rWdcZDp3s7 Gdp1uZ35SZbI7DixPXuR2vS7kr6TeGKwNZV0lSIBTxU9JO1S9OYJ1j917oI9w/zD+p6DcHTs9HXt idjbw/06QdirvLbG7ML2PtHP9N1+1NmnYWP2AaNdx1+/sp2ZvKkxMeOho62arljljplkkUlfde6S vYf8wuo25vndm0ML1fu+mptsdv8Axl6qiyGe6/7ByGVy9f2/TPvTsHHUe1cJio8zJu7bHV8sFbi8 VAKmrq6h9Tx+NlT37r3QzP8APj4/ig2NPD/pNrcxvzJ9gYel2dQdTb8rN57ZruptxYja/aH9/dvQ YV6rZFDsHKZhf4lWZAw0cUcE7JK/iYe/de6z0Hz3+N2Qxm582ud3rQ4Tbuwa3tPHZnM9WdjYPGb+ 67x2Xw+3q3d3WNVlts0ab9xMWe3DQUqfw/yyztWwSQpJBNHK3uvdL/sP5V9NdZZvdG19xZbP1e7N rVnX2Ifae2dn7n3VuTcO4+0aTdWR2VtXZ+JwWLrqndG5MljNl5CrmpaQSNQ0cP3FUYYGEnv3Xui4 7g/mLdcHdHUqbEwu9937Q3ZVd+Um+6Wh6n7PrOydvVfRuH2r/GMdQ7Fp8FDm6Keh3Nu6Glr6ivpo 6OD7Spj8glTj3Xuj57I3lt7sXZe0ewdo1xym099bXwG8tsZNqaqomyO3tz4qkzeFrjR10NPW0hq8 bXRSeKaOOWPVpdVYED3XulR7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6//V 3+PfuvdV29kfC7tPePZXyI3ht3vjr3bm2vkbRbXwm48BuH440+/dz7Z29tzYFLsB8dtbeOS7bxmM gqK2lNZWLNUYSeOKrrCTDIiBT7r3XDP/AMvTbWX6n7l6rpew6+Cl7Kz3QddtzJZjbce449s7c+OO z+r9sbA2juzF1uehTsXG1dX11LW5RmmxX3j5WVVSJ0Ez+690H8v8ufcqYSlOO7F6gxebyu/Ruzf+ zsN0Lkdr9IbvwlLtObbO1to5baeze2dudi7mouva7J5DL4189uvKwTZGtlL08cfhSD3XumLB/wAq fE4Ta+x6CDuOGDenU22sp/of3xhuraLAnr3tDLfITNd61XYuO21j96DFTUU1DU4/bMmFQ08LYiil C1CCoWKn917oxO3Ph/uKg7tl7P3H2bhs1tqD5FZ75JUe0aPYmQx+Srd4Z3oVujKWhzG4KrfWUo2x u0McRVYrw49JEOtJGdpPIvuvdBb1j8Udg5bc3yA2W/dGQ3puig6x7j6N7Nkodi5ba+X2pun5Y763 F8iN2blxu5q7MZDG1+SrNsb+wNPHT0T1Bphi4ZKip80pp4fde6h7j/l9dh772O2G3931trMbq2b1 Psvp3pauwHUE+19n7S2xs3sXrnsGvr927ZfsfO1+6c92C/VOHx2Uko8hiaSloBPHS048hPv3XukX 238d+5OtN8YnvWDP7y7b7rzfc+V7SXenV/SOIzO1tjJQ9DUvSmF63q+nc33Li8lk9sZfDZHKCgyy bgimxlZJFLXPJ/lFVP7r3S++Ovwp7E2vsJdzb+7DfE9zbz+Pvcmxdwz1G38duHI7S7P+QPam5u3N 679qc1jc/RUG4Kyjr8piaOWgpUpaeZsMHWrImBT3Xuju7fi2P8dOoetdn5vcNDids7HwXWPUODyV ZC9GuSyOnAdd7QxtHj4XrZ/vs7lZKWCCnjaZg8oGoqC3v3Xul1tfeGB3lT5iq2/PXVEGC3NuHZ+R krsJnMJpz21cnPh85BRrnMdjXylDTZGmkjjrqUTUNToLQTSL6vfuvdKb37r3XvfuvdBRs/vHqnf/ AGJ2Z1Ps/eNFnOwOnjt1exdv01HlYm28+6YchPh0GTq6Cnw2YkcYudKlaCoqjQzx+GqEMrKh917o V/fuvde9+691737r3SW2tvXa29RuFtq5mlzSbV3TmdlZ+SkWfxY7dO3nhizmGeWWKOOeqxVRMIpz EXSOYPGW1o6r7r3Sp9+691//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691TNtv48717K7spsj 2f132LRddbh+QHzV763tTfd5/ApnsThcbsf499GbWzstBV42sqo93bGpKzJ0WMSdYqjHoeJqaaov 7r3QBYj4v9wbj+PW/jvzr3uev3X138F+uev+mdlV2U3mJh3J2buXtDfddXQRUGQoZs9mulTm9sY9 PukmGKWhdGiR4Wv7r3Qv0vUvd2U7iqcfmNl97ZHvTFfLvZ2a2t31lczuOk6l2b8RevsxtaWOnw+V ps7R7Tr/APSFszb1XRZjbEUT5TKZfLSyZAvAkc3v3XuklW9UfJ3E9a9k0ua2J2Pk9v8Axx3L2h0t 0LQ4Ws3xJuzd2E7l7jy/95/kLHj9k1OP3zuXEdefH3cVFhcRQ4p/v6gnLrSzwyuksPuvdBttD407 2ytVSYvsLozsDKdT5v5u9JZGTbmJ6r3ttHC0XXu1+kNyVGS37S9a5rfu/s/tXA7n7By2MocrXVGX nqVp6ItXJS1aNTj3XunOn6m+QM3XmRwHa3TPyF3hvDdXx/xGW+NOK2fl9z43bXW/yH7j3t2n2D2P ubsfOYzcGOpNg722LujeWDaPI5sRCjxuOlggBcMj+690PVH8cu0MvuuDtPd+G7Gy3bWV+fXTtFT7 iWu3tRYjb/TfSGB2bgNzb8pcBBWUGIx2B7Rx/WmRp6nKT0xjyVLlqSK7BotXuvdWgd9bz3xsLqbe G4Osdl5PsHsn7CLEbB2rjaKWsjrd35+rgwuCrc46GOPH7UwlfXJXZaqlkjSDHU0zBtehW917qomn +Nnyj+NG4a93av7kXsv4nfIbq/cXYHx72Zn9s9mUPYlduuPtHEdi7uzm69+bgpc92Rl9w773JPha iA4qE1WqnjhQmnQe690hOuepu4Nvbdx2H3J0521U/HGt7v2onbFb11sztvrzsjuLY2y+n92Pg6/c Xx4zu+d0btwlDmO0cliqbc9ViWiOfSiWSSPwQCST3XumPtLof5LZrMU+1tv7E73666zqOtopfjz1 lFid0d4Uuyd9bx37vbO5erzG/wDbve3UOM6W3zs6myeLmx9duKTK0uHx3koaWd2o9Fd7r3RiKf41 9nZTcFJ2Fuuj7V3F2jP88+ksTQburqjeOOgwvTPR23th7d3L2PFtmgyy4HF0Xa2P61r4q7LNHPHX x5WmVncaCfde6Nx/Lu6vpesPj39tVddbi633ruXsPsvdHYGL3TjcpjsvWZ3M75z2Qx9Qpyp82QxV BtqroqGjq1VVqIKUOdbl3b3Xuj2+/de6/9ff49+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X// 2Q== --=_related 000639E648257DC7_= Content-Type: image/jpeg Content-ID: <_2_10D9D07C10D9CCA8000639E548257DC7> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAAlAS0DAREA AhEBAxEB/8QAHQAAAQUAAwEAAAAAAAAAAAAABQAEBgcIAgMJAf/EAEEQAAEDAwMCBQIEAwQHCQAA AAECAwQFBhEABxIhMQgTFCJBFVEJFjJhI0KBF1JxkSQoM2JygrE4ZXaDkqGjs8H/xAAbAQEAAwEB AQEAAAAAAAAAAAAAAQIDBAUGB//EADoRAAEDAgMFBgMHBAIDAAAAAAEAAhEDIRIxQQQiUWFxBROB kbHwMqHBBhQjQtHh8RUWUmIzQ3KCwv/aAAwDAQACEQMRAD8A034lfGTcOyW57lsU2iU2oR0xGpIe kuLCyV8sjAOOmNfUdndkUtuod89xBBXmbVtT6Lw1oUf2f8c917kbmW/bcy3KXDiVF5Tbj7LjhUgB tShjJ/3dbbZ2LS2fZ3Vg42WdDbTVqYCFEnfxG7wRJkNItijLDa1IGHXPg/PXXc37PUTnUKy/qDry FK7K8dF0XZZ1+VddCpTL9u09iYyhtxZS4pb6WyleT0ABJ1wbT2JSo1aTG1CcRIPktae2udiLhYBQ p38R+9mkFRtyhjCScKccz2/x13/27RJ/5Fh/UH6Bbh2tuqVfG3luXDLaQzJqcJuU600TwSpQyQM/ Gvi9ppijWdTabAr2abzUaHLO90+MC5KD47qHsW1Rae5QahDbkrqSlL9SgqaWs4GeOMp+3zrnWq1J WqzDtyizqpU5SIVOhMrkSJLysIabSOSlE/AAB0RZO3d/ESty0rJ2yu60YJuK2rxrRpjlSeJbTCSh wJdCk9w5jKgD8DPzoisDfbxbUfYTdLa+06hT36oxe8hyOJUZXJcU8m0NL4/zJUpZBx9tEV/JWTn9 tEVVp3Vqo8SQ2/8ATx/o5ohqQfVnzS5yAwPjHUd/30RWfVJTsGmS5LDHqn2WVuNsc+HmKCSQnlg4 yemcayqv7tjnxMCVpTbjeGzElU/cviXiUCx7TuFuiLmqrgWtcREnBjIb6OqKuB5cT07DP3GuggNr tpE2IBJ4TEevHMLJsupOeBcEiOMT+nzUiuPd9VKr1ZptPpbFRTTKS3U1yX6k3EaKnHAlDRWscUgp PLmVY+MayJIbUJHwOa3z/ThrkrNh3dx+YF3gP1NuWalLd9UFLzEWVWqXFqTnlIMJc5ouBxxOUIAz klXxge7uNbObDyxt4JHlnblrw1WYduB7rSJ9n6p1CuuiVKrSKXErECVU4+S9CYlIW81ggHkgHIwS Acj51m3eGJtwru3SA6yhNr7xPXPGoT7dHjxm6jUpMBwPVRtCmg0SOaEqCS6Tj9KRkaimQ9tN5sHs LukadOJyGqVNw1B/i4N6zr+2uilsO/7YqEuNFi3HSJMqVnyGGZzS1vYJB4JCsq6pUOn2P21YAuMD 3r6I7d+K2ninKrroiK4miqrEBNYUMinmUj1B9vL/AGeeX6evbt11Dd6cN4R26AXWlC9zr3/s4sep XEIX1Eww3/o3m+Vz5OJR+rirGOWe3xqhcQ5rQJLjC0Y3GSORPkJUVoe8FcTd1Hod2WU7a/1gOCDK TU2piHFoSFFKuAHHp8/fHTuRq0NJc0mCBPgM78vek85duCoBLTAnrkpzTL1t6tPlmn16mT3g0Xy3 GmNuKDYPErwkn2g9M9s6qbAuOQz5a+l1rBDgzU2jmu6h3TRbnQ8ujVeBVkMkBxUGSh4IJ7BXEnGc Hv8AbUwYnRVkTCidY3jpMW6rao1LdhVwVaW7EefhzkK9GpCQr3JSFZJ+xKe2q0yKj4/LhLp0sJU1 Pw2FxzBaI6kj6KUt3hQXocSW3W6cuJLe9NGfTLbKHnckeWhWcKVkEcR16atBkDU3HTihtJOmfLrw XJ+66JFrLVIfrEBmrOgFuA5KQl9eeow2TyPY/HxqBvSBpn5T6X6Id0Am0/x6oVam51t3tV6rTaNU 2ZkmnL4OhC0+/tlSBnKkgkAqxjPYnRu/T7wZTH79Dpxg6I/cf3bs/duo14TxTfcfcdFhNUyPGpj9 crlVeMen0yOoILygMqKlnohCQRlWDjI+MkUkuf3bBJiegHu3GFaAGGo4wB6nIe/WAhdn7rzqpdf5 Zui2H7SrbzCpURtctEpmS2n9XFxAA5DqSn7Dv8a0GFzXEG7bnpx87freM3EsLZFnZHnw8r+xMpg3 3bVUmxocK4aVLlyUlTDDE1pbjoGclKQrKgOKu390/bQAmY09/UKzt34rJwq66IiuJoqqxATWFDIp 5lI9Qfby/wBnnl+nr27ddQ3enDeEdugF1pXW1elvv1L6c1XaY5UPMW16RExsu80DK08M5ykdSMdP nUAgjEMonw49OakjCYPuckzG5dpLp0+e1ctKkxIDfmynI0xt3yU9gVBJJ6noB3J6Dro4hrcZy/VS AXOwDP3Plqg9O3bp9xN2xJoaYtQg1iQthxbtQZYdjFKeWPKJJcX1GUJ9wBBOrhpxtY7VpdxyAMfQ kWBCzLhgLhoQPMkT9QMypO3dlDeraqM3WaeusIzyp6ZSDIGByOW88u3Xt21Vu8CW3j+PWys7dIDr T/Pomz1/2vGlemduSkNSfPVG8lc5oL80EBTeCrPIEjKe/UffRu/AbecuaO3ZLrQj+iKvdzLPskU2 rXVcluUupPQIi31yZkZK1cEJJCckdvjGurZ620B7aFNxElYvawNLnBYQ8Elpm/fEEqvKjhmBSUPV JTaE4QhbpKW0AfGApXT9tfddu1fu+xCn+Yx5Lx9jbjrOedFLfxCrIt6y1WcaDRYVIMlEtTxhspb8 wjgRnHfudcv2fq1Kwqd44mIVtuY1obAzVs7yWLbts+Dyr1Gk0WDTZ02iwPUyIzCULe97R9xHfqSd eVsVarW7Tax7iYJj5rp2hoGzSBoot4IbJsa49nZcm5aRRZ04VR9AcqKG1OBHFGB7uuO+untuptFP aQ2kTEDzWeyNpmnLlR34oF7X/Ze7G0ln7VXFVLcbq9NMaNT6LLVHaecVI4NjCSB8gDXyRcSTOeq9 cRFsli2s2D4iWfE1TaBUJtbVvEuOlcWQ5PJlhrgopw7noOIV86hFrP8AD3uHdK6PFHfm1u71yVmu x4tuzItQotWmqkNBZcZQroSRnitQz+50RUfVtt6/QtofELsx9NnVBdj3LDrNKWy0pYQFvGOpIwOh cacaVj546Ir/AKM5VfEJ+IHshRa1CfjSbBtSHLrEV1PvjSm2fNUlY+FB1xpJB+Roi9UGkjBP7576 Is9JAHjoJ+fymR/8o0RaK0zsUWYrM2eqtQvq86PVoD7VvQIk6LR3XmFJaV6pfLk2o9FYGckHI6A6 wa0/cnf5gBo54SXA+ceC2e4Damn8pJcf/ZoBHlPOya2xZV0Sdi9wJlXpE4XHUm2ITcMxnPPcajob bQQg+459x6DrgntrbajioNw3LnYj4uHpE9CsqAwVyDk1paOGRy628VM7L25M/cy8qnUqIUSEU+nI pc6dEPFt0RgFKaUofqSpKclPUEa0rgmnX7s7znvg8jMeBnxWdIgHZg8S0NuPEWI49VW+z22lxUy+ 7fZqMKs06bSZbjrz4tyOiOsZUFgz/NSt1KkqIGQrv0BAzq9FzZxCwwkQbaRlqQYjztcqKzXXaTMu BnPWczlz/Wyktn2lXIyNvPOo1Qa9LcdSfkc4rifJbVy4rXke1J+Ceh1xsBFKiOFF4PUgwOp4LWvc 141qNI5jj0Qi3Nqn4G11mTU2rJYudu6GnpL3oViWhkPK9y+nINhISevt7H5zrsaQ2ts8ZRf55/v0 Va++Nqm8zh+WXzyQlW19z/2jToc2NWWpTtcM5ipwrcjymiOYWhwzluoWgdOqM4GMYJONY7FuCkHZ tzmw53/MD4zlEqds3+8w5Oy16CNIy06wr88RFJm1zZ6vwqdDkT5joY4R4rSnHFYfbJwlIJOACf6a zLcVWloMQvwsbrakQCZ4H0K42tshTKBXIddmVu4bjqENpSYn12eZCYxWMKKBxGCR065H7ZAOprGK dQMFyCJ1i9vf1K46YL2MxWyMaTb0VZ23tDOc8Nk+NBoHorvneZ54fY9PLfbEnkWitQCglSEDAJwe n31euQ0UoEtbhJA118wT1ta662720VjOZcAeo05HyXXSrPn3fcNWm2nZtQsKALbfpzrU2P6Ey5K0 q8sJSP1YOP4h+3XHTUVWucysZkOiB0IJMZCRLYyvzdGVIhr6IIu3M8iIzzN7+HRC7Rt1527dsEQd uKrbj9HUtmrVJ6nltDznl45FYGVpyCeasfqwNaGKtV7mGGuY4AG18Jz4ZxObtbhZOaW0e7ddwcDP LF8+eggcU3odJuWNQrItJ6z662/Q7rblS6gYhMUt+cshSFjqpOCSVY4gAdeo1NFwfUo1DaGOBniR 78cpWm02btIF8ZkRwj15I4u2l0q6bkp1Y2wn3VWajXjPgVppPlMpYUtJRylp9zPDiTxH+BxnWWyj dpM+FzSZPzxf7Tw/+rKdouXuNw5oAHyjl1+l1L9mreRam5t+QnbXkwFSJjkmHVRTw3FMc8f4KHsf cg8R09p+RjVqFtlwZEOPiMh5Qek2zSvevjN5DecGL+fHjmiu79IrFNuy0b3pFKfrwoin2ZlOi9X1 MupCSttP8yk/3R1OR8ZIpTd3VVziN1wg8oMj1vwhWeO9pBgN2mRz4j5W+tghlMeq+6u6lAuFVtVW 26FbseThdajiPIkPuo4cUt5J4gdeWcd/nVHtwUq9Vx+JuEDpck+n63ilQ4w2kBrJPTID68uFppmw 7dXcll2hTqPZMxqvqrQnG6kxk+QGUPOcip8HKSOOPLOP0gjJIz2U7VqLvhDQC7mIy5zPh8OUptNz tLTcuJA5G3l+6dq2vuf+0adDmxqy1KdrhnMVOFbkeU0RzC0OGct1C0Dp1RnAxjBJxrDYtwUg7Nuc 2HO/5gfGcolTtm/3mHJ2WvQRpGWnWFZdo2Q7SoW6deVaDNSuJyrTzT0VOHkyGSn2hBUMqbXyWCEn Cu2dYgmnsdNrReLjXMZjOwEgcclqYftUk2hsdQDkdDpOmqhFsWXOuC6qhJNl1CjQalbEmKuPJorU SOJmQrihttPRIUAUF0lZ4j3HAxeo2KNdrTNgW8bHynOwvF9ZVKbpqUC4RDr8Ijzi9ybEyABcItZN Anu0radmNatUor9LqLyKkqRTFMfxPIA89XTqk5A5qxkpx8a6KsvrNLDA7t4HI4QPCTJHHPNc43aL muEnG09RiJ+Qz4IJSrCq3prftlqxqhAvSDWxLl3apgCOtoLUsrEodV5SR7PuPv01FAt7yi9owtYN 4cdCI1n9vhutNoBis07xed08NQeUe96yfVzatyo2bu5OetV+TXn6645TXlQVqkLa81JCmemSkgr6 p6Ed841zU5Zs+z4bOBvx0z9810SHbQ/F8OAdJwn5zC09TgtNPihwKDgaTyCu+cDOddVWO8dGUlcV AEUmA8B6LOfj0vv8q7Ju0lp0ol1+UiGAD1LQ97n/ALDH9de12Hs/f7WHf4rn21+Gnh4oR+H3Yf0H aifcT7fCRX5hW2SOvkN+xH9CeR1t9odo7zagwXDQs9gZFLGcyoB+JifdYv24TP8Ao3r0fs1/2+Cx 7QsGq3N/z/qUSj/3LA7f8TOvH7Pt2oOp+q6a99m8lifbHwyX3vJasit2u1EMBLy4p8+X5R8xKQT0 /qNfZbZ2lseyVO6rNkwLrxqNCrUbiYU48fchjbXxF+Fh64ZKIMahR4blQfzyS0lqWguLz8gcSdfm lZwqVXPbkV9OwFrACgV6+JPbaq/ig2zuTGuqI7ZUWmtMvVYZDSFhlxJSf6qH+eslZDNr7nn7l+Mz xOVvaqe5PqlWtmpPUCbT18XFulyNwU2r4OQdEVcUKzvGLTtwLio1MmXEzd8liPVqtHbmD1LyCPKa ec65PROOv20RDdv9nfFVSt3rrmW8muovlK2FXFJizQZSkvYcT5pzk8sZ/poi93aYXDT4/m584NpC wrvyx1z++iKgU/8AboV/4TP/ANo0RaFffbjMuPPOJaabSVrcWoJSlIGSST2A1BIaJOSkAkwFX9X3 9sek1mk04V2FOVUFqT6mHMYWxGCQDyeWXAEA56dycdtS3ecW5WmdOnVQ7dbi5gc+vQaqSUzcO1a1 LEWnXNR58kpUoMxZ7TiyAMk8UqJwACTobNLjkLnkguQ0ZnJAnt56E3YIvBMeoO0lUkRUBLAS44S7 5QWkKUAUE9Qc9v3BAsGkvpMNi+I5SJvw9xa6gkBtRwuGTPOIy45+qKUzcqhT6dUpkmSqitU2UYcz 6un0oZdyMAqUeJ5ApUME9FJ+TjVAQWNfo7LrqOouDzB4KxBD3M1F/A5HoUFlb+WRFueFRjXoLolM reFRamsKiNFOfYtzzPao/AI6576lu8XDKBPW8W5/RQ7dDTxMdLTfl9UTre69tUi0apccepMVyn00 J9QKQ+1IWkqUAB0UAD1+SOmqvdgAcRYmFZjcbi0G4E+v6JhP3YdpluO16TZtwN0lqP6tcjzIJw1x 5cuIlcu3xjOrVfwSQ+0GPGY9VWn+KAWXkT4RPoiFV3QpFHtu36y+1LUzXHY7MOO02FvqU8AU5SFf A6nBPbpnWjmFtcbPqSelsz05qgeDRdW0HuBzXG4d2rbtNEhyruVOBHjueU5Jdo03yArOBh0M8CCe xBIPxnWIIdAGuS1wm64Xpu1RbFpUifOi1h9plpDx9NSpBSUqxj+KpAbSeoyFLBHbv01LjhdhOcx7 4+EqGDvAHNyIn3+/omDG+VvyLiFGTBuASfRiby+hyj7CrjjgEFzv/Nw4f72emrx8X+pj3w8YPJUx Waf8vfj4Su2498LStet0mlzak2mRPXwWS62j0XtCgZKVrStrII7p/wAcaq2HPLJ430tmJGvDj5qx szHHC2t9Y4cUPq/iAoFMrL0BmBUqq23IiRRNp/p3WHFyUc2Qj+KFLBGeqUnsf21NMGo5rcpJF+WZ 5AZyoeQxhfnAxW4THnKs7UKUtES0RfCMgg9tVc0OBaciiF2xa9Ms2isUmjxvR09gqLbPmKXxKlFS uqiT1JJ760Li6J0t5Ibuc7UmT1RXVUS0RLREtES0RLREtEXnD+ILeirl3dh26y8TFoUIBaR2Dz3u Uf8AEJCf89foX2epd1s7qoElxhfP9oVMTw0K7tlPFxtzHj2dYFFhVVtwoYpsdTjGEFfHBJP2Jyc6 8DbuyNrpiptD4IXdR2qmcFJqgn4mHX8i/wDDM/6I16P2ZM96ByXP2jkxWzv6sHwUys+0fRoHX/ma 15XZ4ntUDm75SuquJ2VUJ4WfFbaGyG2kug12PUXpi6g7L5RWuaOCkoA6/f2693tbsitttbG2IiFx bJtLKNPCVb3iD8IdjePK3rOumpVSq0FbUQrhyIYSXFMOe7gtKgR366+GfTNF5pHSy9trsbZXnHdH gRteg+Ouh7EtXHVXaDUIbcpdSUhv1KVKaWsgDHHujHb51RWW6dqfBpYP4eLV3bxR7jr9ws02hPty IbrLZ5N8kL9vAZzlCR9hknRFUv4byL28RniU3D8RFwvSYdMdbXTIsVKyGXVKI4spB7oaQlP/ADKz oiBbpXzXfAV+IXULznJm1Tb/AHFw9KKcrVwUoBQT91Mr6hP91WB30ReqMWSmTHbdbB4OoStPJODg jIyNEWfQf9ejscG0z1/80aItCynHGYzzjTJkOoQVIaSoJKyB0SCegz266q4kNJaJPBWaAXAOMBZU o0quv7p3lMuOjvTa8gRmyKTUKoymG0pHMMhUJhzkAOOeeAVJJHLJOppANomDMuMm9yLZcBprGaiq SajZsMNha08+PHTgjFr1CdX6zubSJqrjRTW6QyW6XGmzZMlOUnkGfWNpc5L7dUfPTIwdUcMey1NT ibGXO2tuPJWacO0U4tuu9c9LjSNeahtft+tR9iJblw+qiSkBnhErNZVESwhBHlNMwW/YslDas+YG 1khRAOMnSq4NdTeYJBk6yTEiMgAHDIyBIMCAq0RONosIPK2hJzJJGogmIkyVPLM3FYt6yLyuSl0q 36dHhw21w34tD+nCcs5SglPqFOLR5nNAPFIJCsKyFAWrYmMhtyXAAcRxgakGRqBBi9s6DQ5zQdGk zzGk6wYB58LSco+y12PWLVqSL0ap8S4T6uTG+mOuORFOYU6224uSVcVZIVyyT17EnUVaTWgUJlrD bmAZA6Tf1JVqVUvP3gCC4DwMZ9f2iIRK/BItax6Pa1diQbujVidHo7LKXJFPSlJGUlxwuPuKwUDJ BB//AE8/eawYRcy6f/GD7vdGD7vSc8Gwgedj7i2igsatwK9Pj2iLXmuvSahOoq4ki9al6MCM0hSu uDlCgogJ4fA+/Ss9+3vDeW479Y85EqT+BIyjCLf7SmtYambq0uxZVAoVegIYRJp6mKa81IjQ4iOT LnFx9KB5y0gJSoqBAGep7zh72r3jzIe0EzzJsOp+KNNCFJ/CYaTc2OgdQAZPSd2ddQURuS3I0So0 O3LkYvCfPWpTNuimvxY7EYsgKDjQVKUorSP531E4OABgASHOqVC5p/EAmeUnTKDrMuMXMqsBlOD/ AMdhHMiBPMXy3ReBC+bnWkFVi2ZM+emoXnMhobmQ5tGTIL0dvkVKQ23FmJad5KHJQynocdNVGEVn hgtmeRgNBBjKQZHQc1Yz3TS43BIHSSTrcwRB4X4hRirWfT3XYTNZjs0ChyHhHmSVW+UOkLGEpac+ jMBtfLHUr1ZjRUqNYTnYaEnTXLiOCq5xYwvGmfADX9uaOXzajlRuTcVuK7VXYdIpsdqog1tqMJEY M+chtDYhOdU8CMlWTk9cKI1k6pipvrvFnPJ8QbHoJEdNSFqxkPpUmZ4YHQyD55n5ZBRVNRbp12/m CPJLtRiSaE9DpMktKXLS7ECFIShtCOS0JcHEoSAPt112UwRXaDeX1GnoYl3yvpfhZcj4+7SMmsBH VrzA8p52Wydc63S0RLREtES0RLREtES0RLREtES0RLRFQ26fg8snd68ZNzVJydDqUhKW3jEd4pcK BxSoj74AH9NetsvatfZaeBmQXHU2WnUOIoNaHgUsWybrpNwQZ1VVLpkhEllDr2UFSewI+2tto7b2 mvSdSdEFZ09ip0yCMwprvf4crc8QK6X+YJExj6YHEtekc4554zn/ANI1x7Ht1XYCe61XRW2dtcNL lKq7tpR7j25VY9QS4/RnISYKsq/icUgBKs/cYBzrmZtL2VxtI+KVqWBzMJyVDq/Dq284kfUqyBjG PPHb/LXv/wBxbUy4AXnnYKZMrRVl2vFsm1aXb0JS3IlMjojMrdOVFKRgE/vr5urVNeo6q7Mlek1o Y0AKpa14Q7XrniYpu+L9RqAuWBHSw3ESpIjkJQpAyMZ7KOqqVcF1W1AvS2KtQKo151NqkVyHJbz+ ptxJSof5E6Ihu2m21vbSWZS7UtanN0yiU5ryWGEd+/uUo/zKUepJ7nREJ3a2WtLemFSIV1UtuoN0 ue1VIiz0W080oKGD/dOACPkaIrAT8fb7aIqtRtyhXiL/ADt9QcDoopp/ofLHAjkDy5Zzn9tEVq6I gsWz6TBqVaqEeOtibWQgTX233Eqc4pKEkEK9hAPdGD899REM7sZST4nNTMvDzmLIfTdsrfpJqy4z M1MiqpQiZLXU5K5DoQMJHnKcK04Bx7VDpoQHM7s5TPv36lAYcH6gQmKdkLBTLjSfyjSS5HaLKAqM koKTjqpB9q1dP1KBV369dWm5dx92GQ8OmSroBw93Ovj1ShbJ2RBQtCLfYeSot4Epxx/yw2srQlHm KVwSFEninAOSCCNGktiNIPOQIF8zAsJRwDpnUEcoJk2yub9bqcahSgd1WVRL3YhsV2nN1JiJITKa ZeJ4BwAgFSQcKGCfarIOeo1EAOD9RPzUycJboUAb2MsNpxlQtmGttmS9LRHc5LYS46lKVnyiSjGE JwnGE4GANBYRyjwmfZzUG884+WXr46p5C2ltSn0yNTWqUVUqPzKKc9JediqKlFRK2VLKFnkcgqSc dMYwNSbxN4EXv7N88+aaki0mTFvYtlkm8nZm1pcuHKdZqipELl6Rz63OBjZGCGsPewYAGE4GABoJ BxTfjqepzKGCMMW4acrZW04J3P2rtWryKc/VKSisO09pbMdVVdcmYSo5PLzVK5nPYqyR8EaWxF0X IA8Bl/OZ1T8obNgSfP3lkuidsxYs9ttKrSpLBbcS6hyHFTHcCknI97YSrGfjOD86lpLXNe3MGQoc A5pYcjZdlX2js64KlVKhU7ehVCdUkJRIkSUFxeEo4DgSf4Z4/KOJ6A9xnVA0BuEZTPs5/RXxGQeH 85Ilblj0S0pEp+kwvSOyWmGXVeatfJDKPLaHuUcYT06d/nJ1oXEgg6knxOazDQIjQR4TKO6qrJaI loiWiJaIloiWiJaIloiWiJaIloi//9k= --=_related 000639E648257DC7_=-- From nobody Wed Jan 7 17:15:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E3D1AC3C2; Wed, 7 Jan 2015 17:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.023 X-Spam-Level: X-Spam-Status: No, score=-97.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_46=0.256, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC0MU4KKKLND; Wed, 7 Jan 2015 17:15:53 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 346461A87D5; Wed, 7 Jan 2015 17:15:52 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id AEFD8A2C9A8EA; Thu, 8 Jan 2015 09:15:49 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 19996BB6CF673; Thu, 8 Jan 2015 09:15:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t081FgNP001870; Thu, 8 Jan 2015 09:15:42 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20150107145943.GE13482@elstar.local> References: <20150107145943.GE13482@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-KeepSent: B5B85345:28DDEA9F-48257DC7:0006A0E7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Thu, 8 Jan 2015 09:15:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-01-08 09:15:42, Serialize complete at 2015-01-08 09:15:42 Content-Type: multipart/related; boundary="=_related 0006EE4748257DC7_=" X-MAIL: mse01.zte.com.cn t081FgNP001870 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/USuElm08YL90hWcuokr1XpELezQ Cc: netmod , netmod@ietf.org Subject: [netmod] =?gb2312?b?tPC4tDogIFZSRlkgOlkzNDogcmVtb3ZlL2RlcHJlY2F0?= =?gb2312?b?ZS9yZXBsYWNlIHRoZSAnYW55eG1sJyBzdGF0ZW1lbnQ=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 01:15:55 -0000 This is a multipart message in MIME format. --=_related 0006EE4748257DC7_= Content-Type: multipart/alternative; boundary="=_alternative 0006EE4748257DC7_=" --=_alternative 0006EE4748257DC7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQogIFkzNC0wNCBpcyB1Z2x5LiBXaHkgdXNlICdyb290JyBzdGF0ZW1lbnQ/IFRoZSBtZWFu aW5nIG9mICdyb290JyBpcyBub3QgDQpjbGVhci4gSSBwcmVmZXIgWTM0LTAyLCBpbnRyb2R1Y2Ug J2FueWRhdGEnIHN0YXRlbWVudC4gDQoNCg0KDQoNCkZyYW5rIEZlbmcgICC367PlDQpCTiBQcm9k dWN0IFRlYW0NCkJOsvrGt83FttMNCg0KQWRkOiBaVEUgQ29ycG9yYXRpb24sIDUwIFNvZnR3YXJl IEF2ZW51ZSwgWXVIdWFUYWkgRGlzdHJpY3QsIE5hbmppbmcsIFAuUi4gDQpDaGluYSwyMTAwMTIN CsTPvqnK0NPqu6jMqMf4yO28/rTztcA1MLrF1tDQy82o0bYNCk1wOis4Ni0xODkxMzg1MjYxMg0K RS1tYWlsOiBmZW5nLmNob25nMzNAenRlLmNvbS5jbg0KDQoNCg0KDQoNCkp1ZXJnZW4gU2Nob2Vu d2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiANCreivP7Iyzog ICJuZXRtb2QiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4NCjIwMTUtMDEtMDcgMjI6NTkNCsfr tPC4tCC4+A0KSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGU+DQoNCg0KytW8/sjLDQpuZXRtb2RAaWV0Zi5vcmcsIA0Ks63LzQ0KDQrW98zi DQpbbmV0bW9kXSBWUkZZIDpZMzQ6IHJlbW92ZS9kZXByZWNhdGUvcmVwbGFjZSB0aGUgJ2FueXht bCcgc3RhdGVtZW50DQoNCg0KDQoNCg0KDQpUaGUgMjAxNC0xMi0wMyB2aXJ0dWFsIGludGVyaW0g bWVldGluZyBwcm9wb3NhbCBpcyB0byBhZG9wdCBZMzQtMDQuDQpQbGVhc2Ugc3BlYWsgdXAgYnkg V2VkbmVzZGF5IDIwMTUtMDEtMTQgaWYgeW91IGRpc2FncmVlIHdpdGggdGhpcw0KcHJvcG9zYWwu DQoNCkZvciBtb3JlIGRldGFpbHMsIHNlZSB0aGUgaXNzdWVzIGxpc3QgYW5kIHRoZSB2aXJ0dWFs IGludGVyaW0gbWVldGluZw0KbWludXRlcyBhdmFpbGFibGUgaGVyZToNCg0KICAgICBodHRwOi8v c3ZuLnRvb2xzLmlldGYub3JnL3N2bi93Zy9uZXRtb2QveWFuZy0xLjEvDQoNCi0tIA0KSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJl bWVuLCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90 aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBl cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHBy aXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBy ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBv dGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4g ZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 0006EE4748257DC7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFkzNC0wNCBpcyB1Z2x5LiBXaHkgdXNlICdyb290 Jw0Kc3RhdGVtZW50PyBUaGUgbWVhbmluZyBvZiAncm9vdCcgaXMgbm90IGNsZWFyLiBJIHByZWZl ciBZMzQtMDIsIGludHJvZHVjZQ0KJ2FueWRhdGEnIHN0YXRlbWVudC4gPGJyPg0KPC9mb250Pg0K PHRhYmxlPg0KPHRyPg0KPHRkPjxpbWcgc3JjPWNpZDpfMl8xMERBMTUyQzEwREExMTJDMDAwNkVF NDU0ODI1N0RDNz4NCjx0ZD48Zm9udCBzaXplPTE+PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRy Pg0KPHRkPjxmb250IHNpemU9NCBmYWNlPSLOosjt0cW62iI+PGI+RnJhbmsgRmVuZyAmbmJzcDsg t+uz5TwvYj48L2ZvbnQ+DQo8dHI+DQo8dGQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSM1ZjVmNWYgZmFj ZT0iQXJpYWwiPjxiPkJOIFByb2R1Y3QgVGVhbTwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSM1ZjVmNWYgZmFjZT0izqLI7dHFutoiPjxiPjxicj4NCkJOsvrGt83FttM8L2I+PC9mb250Pg0K PHRyPg0KPHRkPjxpbWcgc3JjPWNpZDpfMl8xMERBMkM5QzEwREEyOEM4MDAwNkVFNDU0ODI1N0RD Nz4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPkFkZDogWlRFIENvcnBvcmF0 aW9uLCA1MCBTb2Z0d2FyZSBBdmVudWUsDQpZdUh1YVRhaSBEaXN0cmljdCwgTmFuamluZywgUC5S LiBDaGluYSwyMTAwMTI8YnI+DQrEz76pytDT6ruozKjH+MjtvP6087XANTC6xdbQ0MvNqNG2PGJy Pg0KTXA6Kzg2LTE4OTEzODUyNjEyPGJyPg0KRS1tYWlsOiBmZW5nLmNob25nMzNAenRlLmNvbS5j bjwvZm9udD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwOyZxdW90O25ldG1vZCZx dW90Ow0KJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OzwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDE1LTAxLTA3IDIyOjU5PC9mb250Pg0KPHRhYmxlIGJv cmRlcj4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNl bnRlcj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+x+u08Li0ILj4PGJyPg0KSnVlcmdl biBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUm Z3Q7PC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bmV0bW9kQGlldGYub3JnLCA8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltuZXRtb2RdIFZSRlkg OlkzNDogcmVtb3ZlL2RlcHJlY2F0ZS9yZXBsYWNlDQp0aGUgJ2FueXhtbCcgc3RhdGVtZW50PC9m b250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48 L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5U aGUgMjAxNC0xMi0wMyB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBwcm9wb3NhbCBpcw0KdG8gYWRv cHQgWTM0LTA0Ljxicj4NClBsZWFzZSBzcGVhayB1cCBieSBXZWRuZXNkYXkgMjAxNS0wMS0xNCBp ZiB5b3UgZGlzYWdyZWUgd2l0aCB0aGlzPGJyPg0KcHJvcG9zYWwuPGJyPg0KPGJyPg0KRm9yIG1v cmUgZGV0YWlscywgc2VlIHRoZSBpc3N1ZXMgbGlzdCBhbmQgdGhlIHZpcnR1YWwgaW50ZXJpbSBt ZWV0aW5nPGJyPg0KbWludXRlcyBhdmFpbGFibGUgaGVyZTo8YnI+DQo8YnI+DQogJm5ic3A7ICZu YnNwOyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vc3ZuLnRvb2xzLmlldGYub3JnL3N2bi93 Zy9uZXRtb2QveWFuZy0xLjEvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly9zdm4udG9vbHMuaWV0 Zi5vcmcvc3ZuL3dnL25ldG1vZC95YW5nLTEuMS88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj48YnI+DQo8YnI+DQotLSA8YnI+DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eQ0KQnJlbWVuIGdHbWJI PGJyPg0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IENhbXB1cyBSaW5nIDEsIDI4NzU5DQpCcmVtZW4sIEdlcm1hbnk8YnI+DQpGYXg6ICZuYnNwOyAr NDkgNDIxIDIwMCAzMTAzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PC9mb250Pjwv dHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iPjx0dD48Zm9udCBz aXplPTI+aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2ZvbnQ+PC90dD48L2E+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KbmV0bW9k QGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXpl PTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVl Ij4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3 aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4g aW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmli dXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRl bHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRo KSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUg ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50 ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBt YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku DQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 0006EE4748257DC7_=-- --=_related 0006EE4748257DC7_= Content-Type: image/jpeg Content-ID: <_2_10DA152C10DA112C0006EE4548257DC7> Content-Transfer-Encoding: base64 /9j/4R9rRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAcAAAAcgEyAAIAAAAUAAAAjodpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBXaW5kb3dzADIwMTQ6MDg6MTIgMTY6Mzc6 MDAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAAoKADAAQAAAABAAAAxgAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAAB41AAAAAAAAAEgAAAABAAAASAAAAAH/2P/tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSA AAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAoACBAwEiAAIRAQMRAf/dAAQACf/EAT8AAAEF AQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAAB BAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHx Y3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm 9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS 0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9VSSSSUpJJDvvqoZvsMA kNaAJJcfosY0e5zklEgCzokQbMljZDGuuePzKxJn93c7bWz+29QbXff7sj9Gz82hp1j/AIaxv0v+ Lr/R/wDGoll2PjtAcQwD6LR/BrU4DWvmPgtMtL+Udy4lnXuou6uzpLqqen2WMFjLLybg+fo1sZUc dnqaP/w62KactoHrZAsPfZWGD7nOtd/01k9YZ0/qtIqvqMs1qvBAew+LIn/MVWjrXVOnsFOaRk0N 0ZmNBLgP+7DJ3f2//PqnOIyiOGIif0on/pRl/wBy0/vAxzl7sjOBNxyDaP8AVyQjw/8Ahj0oa8fn z8QFJ0x7RJ8DosZnXHlocPTsYeHCdfxVirrmM4xaDX5j3D8Pd/0VGcGQfo35M8eZxH9Kr7/xdAPH DgWnz/vUlCuyq5m+twsYe4MhRc19fur9ze9Z/wDRbio66bM16XuPBKkoVW13Viys7mu+XGha4H6L m/nNU0Eg3qFJJJJKUkkkkp//0PVUkkklIcvKow8a3KyHbKqWl73eQ8P5TvzVCih7njJyB+nIhjOR W0/mM/l/6Wz8/wD4tZ/1optyuh5zK/zGBzR4ljm22H+y1iQ65VlYmPbUQG2s9XIM6MaP52r+vv8A Z/6sUscZMQY7kmMvAU155oxyGM9BGInH+seKUZf4nobOZ1JrBtqPJjfzx9LZ/V/eWPkZQbvdu3bf pk8jzcqXWeosJF2Md9Fg2NPG17R7qnN/M/fWPl5toyfUa8tcQ14j+U1rz/1Sv4OV0B2vu5fN/EPU QPVRG3y1L9KLp3dXY36Jn4Kq/qz3fR9p8+Cs59ld+tYFd3evhrv+K/dd/wAF/wBtqq66DB0I0IVy OGA6a+Lnzz55H5tP6rpDNex5IGyeQ3T8PoqYzMh2tTvUjlvDh/ZWR9oPB1HgU/rDlroI4kwfk5OM I9h+xi4Mn6MiPB2sbrmZiWG2l+14+kOxj82xn5y7HofX8fqtewxVlsE2Uzz/AC6v3mf9QvPqbLbx +sVF1fe8+zaPE2Ha16NtsxiLsR7hY3VjmO9wkbXPa5nu7qvzHL48gquGf6Mh/wB0z8p8Ry8vk4ZE zh+lAmx/gy/Rk9/gWGzM6h6UGmu4NBB0L9jPtDP7D/8Awb1VoAgiQsv6s5+HmdJq+y1to9H9HbQ2 YY8au+l7nepu9Xf/AOjFfLzXktYfoXA7fJ7dSP7bP/PayckSJyiRRjpr/VelwyBxxkDYn6rG3rP8 oJkkklGyqSSSSU//0fVVF7i1hI1PYefZSVLqozn0MowLRRkXWNaL3N3hjRNlr/TPte7YzYz+ujEW QNvNbI1EmifAbp77KsXFsss1rqYXOnuANf8AOXnpe+ltuPUQym8tsNY/Nn3MZP8Ar/g1q9f6OMDE ruys/JzLbLNrvUf7IAc87a/d+c1v5yw8dwcJBmDB+K0uUxCMDMHi4jvWnpee+Mczk4ow4PbMB+9x S/Wb3w/1UuPU5u5ljt1FwDbWRB0+hYw/6Wp30P8Atv8APWb1FxpvFbyJaxg3djA27m/ctdqDm5oo 201ub67wS0PAc0R9Fj/3PW/MVqMzxXvblYM+SRGLhE9yL9PDXq+b91w2+rdpVW6z+qCR/nfRU3xx l3VVOHB3h9n9V1WP6rnf21Kz6yXlprtqqc0aFj2GAR2LN6G3rdbjtb0/FM+Fe3TxKk4pdm4MWfrj AH9WceL/ABp8P/QWf9lpgu9XI3fRc3bVWf6rz61jkvt4pP6Kuqp/8lvqOHxuyN/v/qMT/tfCbIb0 /H930y3c0E/yfapU29GubuHT2ADRwFjxB/kwhZPQp4SBeTFOQ/vYiD5w9yMP+ajbmvufNznPA7vc SZ8E1dvu31OIdyI0cEYO6V6gacB1bWk7XDIdB/qtd9LcoPt6DU7aabtw7C0mPmjddCF136RinVbD 2tv8HI7P1e63nYucwUNYbMktrcH+1th19Ntn7j93trtW0z66Pu6nj/aaWU4TbJ3AkvbuY+nfY72s dXus3v8AYuQGZgQPRxnkmNu58kn81W82i2kN9Zjmes0PrkEbmu7s/eVfJhxzlZjRI4V8OYz4RGMB OGMS4uGXCY/ZHi4YvqdF1eRTXfUd1drQ9jh3a4bmlEVHowzG9Pqqza21X0gVuDNGENA2OYPzfZ+Z ++ryx5CiR2L0kDxRBOljyUkkkguf/9L1VRP0h8CpKl1VtlmL6Nbix2Q9tLrGmHNY9wba5h/f9Lds RiLIHdEjUSd66PKfXLqdeZ9n9BrnY1b7Wtv4ZY9uxtno/nPrp+h6383v/m1yz8u2pwcHlpbw1ujR 8Qu0+veLVT03CsY306saz0mMYIAa5nsa391rfRauBtydn80xrT+8fc7/AKS2eT4TgjWw4h/znnuf xH71PiHGZCP935W3X1PqljgGEBk62GsbQB4/vI+VjYnWA9tL24/UGa2VkyHNH5z2/S/t/Tr/AMIs N2TeXm02OLmDQk9z7WqFQcx7bi5zbAd7HAw8n9/f+apzEdNCwfdqInAjFOI9PBHc/u5P34Oi7Bbq 3KZuyI22WEFrtPbv5/d/wn+EVMGnbtbWS3uXOjd5u2BbFGfR1KtuN1A+jkD+ayWe0E9v5LHf8G/9 FYq2Z027Gs97RqdHN+i7+Uz9x379SIl0Io/msx5SJGGS4z3Eb9P97H/V/wCg0QY+jWxv9ncf+nuR G22M0d7/AB7AHwbtRBXt/rfkTigmO06Dz/qt+k5OZDIHpbVeG2EmwBr+zx+R4/7+l9jufc2tlZtt t1ZW3Wf3nOP5jP6y0DhNph2U80A6hgAde4fyavo0f17kK7JJpdj0s9DGP06wSXv87r/pP/qfzSbv t9qY5v8AN+rxP83Hy/f/AMH/AMba5uZghzKbBflukPvbrXUOCzF/0l37+R+Z/gV6t9UYt+rHTHPA cW0t2k6xt9rTqvIrKSGkt1aB8IXs/wBXsU4nQun4zhDq8eoOH8ra0v8A+kqPxHSEB1Mv2On8NA4p n5iQOIlvDl3+vZSUW8k+akst1FJJJJKf/9P1VReJbxJGoB8RqpJJKcz6x9PPU+iZWNWN1rmb6Y7v YfVrA/rubsXjltkifHsvdG6Es+bfgvLvrz0F3SeqHNoZ+p5zi9h7MuMvto/k+p7shn/XKq/5taHw /MAZYifm9Uf+6aHP4eLhygWY+mXk846v0SGOh1n0nDkNJ+ju/e2qTGkmTqTySoV1k6kjzcSIn4q9 RiFw3SC0cu+i0f1rHrSsOXM8I1PmWDK50iZ7crY6Zdc79Tui6og6OklscN3D83+uq1Yx6xDW+ue8 Haz/ANK2f9BF332N2H21/wCjYNrf81v0v7SRHEK/Fo5zxgjh8pS04T+9H9L/AKDbf0vHEvDnNiSR AJgaw0uVIZBAP2VookavHutI87XfR/62reK3JaZrkgctJO2Pn9FPkYldgNtAAs7tEFpP/Uf5qA9J qR4vH/vmCJmP5wmcf0Zfof4blOq5Pc6k8koL2Qrr6njSxorJ4jv/AGkGysCfyqRsxnrqv0Xpp6j1 fFwQJrteDd/xTP0l3/Qbs/tr2AmBJ7LlvqN0J2HjO6nkNjIy2gVNPLaZ3a/yr3fpP6npLp3GXBkS Bq4/9SsbnswyZeEfLj0/wv0no+QwnHhuQ9WT1fT9Fk0ENE89/inSSVNuKSSSSU//1PVUkkklMXhx b7fpjVs8T/K/krHu6HldTw343V851zLY9aimuplYIO8Cv1a7sj9G7+bs9XetpRc3WW6O/L5FOjMx 20Pelk4CW9+QJj/0XyXqvSbug9QtpuDLqgWtrvYCZD9zqmXbi6vHu2Vu/Rf4T/B+xVXXMtcJYdrf ojdEf2W+1eqNw6HX5uPmVNsq6g5tu14Dmu2110PqM/6P7P6v9v8AkLneqf4vWAm3o9oZOv2a8kj/ AK1f7nt/q2+p/wAatPBzsCQMp4ZUPX+jJyOY+HSJOTEOLU+i/VH92v8ABeTr9L91w+YP/fVboYHE BsgnxAP5E9/ROr4ZIyMS5gHL2jez/tyn1GqOOQ14Jc5sHXWD+KvCQlG4S4vI8TkZccoGpiUf7w/7 56LA6c8gE4/r+G61v/nt4bWr2RiWOqIsw7dsfmuqdx+7tsVbplpIAqzbQ790Cuz/AKJrWk9vVC3a yxto/wCFx3NP+djv/wDRazcs5CepH143Zw4ccsVAyIIqqw8P/R4njLbGPBDhI8D/ABWn0X6v3OvZ l5uHffiiH00ez3nsbvXtq/Qt/wBG/wDnv+K+nqZ3Qr8nEtLMM25djdLLHNqY0z9OljXWWvd/4ZRf qtX1DP6VTk5ebY7HdLaaWAMO1hNX6TIb+nfu2/muYnZOZPtngkB+jL6/ucLX5T4ccecDJxS044aV D0/v+5/6j43Sdn9Ste6rHw212DSb7W+2eHvrxftH+b6le9aDGuawBx3Oj3OAiT47U1VVdTAypoYw cACAprOkQdgA7sIkaykZHx6f4vCpJJJNXqSSSSU//9X1VJJcXnf4zMPEzsnEODbYca2ykvD2gONb jU5wB/lNT8eKeQkQHFS2eSMBcjVvaJLhf/HVw/8Ayuu/z2Le+rf1u6b9YPUroa+jKpAdZj2xO06e pU5pc2yvd7P9a0+fLZoR4pQIA6rY5scjUZAl2rK2WN2vG4fx8R+65Aurzmsd9lsY50extwJE9psr LXf9B6w/rJ9d8boGezBsxX5D31C4uY5rQA5z62t93/Fq79WvrJi/WHEsyKK3UPps9Oyl5BI0D2P9 v5j2lD2skYDIY+g9VccJSML9fhoW1VblViMxlpcfpOqAdWD/AMH6X6zt/wCMrRRiYVzQ91Tbp1Bt Bef/AAbc5qwvrJ9d8boHUGYNmLZkPfU24uY5rQA5z62t93/FLW6D1dvWul09SZU6hlxeG1uIJ9j3 0zLf3vTSlDIIDJw8MZbEFETAyML4yNxIXJvNa1g2sAaBwAICksSz6zA2Ppxen5WRcA41thjA9rHe k6332esyn1Pz30omN9YqsjeG4mQwtrte0vFYa51JDbqfVZa9lVrXnb+m9NVvexk1xNw8pmAvhoec f+i6WTjsyaXUWE+nYNrw07SWn6TNzfd7v5KnXXXVW2utoZWwBrGNEAAaNa1o+i1qxj9aK68WvKvw shjL278dg9N731hvq23bG2/oq6a9vqet6f01Z6X1ujPxLMiyt+GccA5Db4aGgsbd6gt+g6nY7+cR GaBIiJa78KJcpliDMw0HpMgYy/6P9b/nukksav6xOddS+zDsp6bkv9OjPsc0NcTPpPdR/PVU3ub+ hts+nvp/0qi360Y7633MxrnUsZQ8Ebd5OQ+yikem57Wf4L/S/wCFYh72Pv8AgenX+6n7pn/c7bGO 8jwcJ/r8X6DtpLEH1kcWmv8AZ97csWCkUPdW0F5achzPW9TYzZjD1nep/pK1p4ORfk44tvoOM8kj 0y9tmgOjt9Jcz3IxyRkaBv6FbkwZMYuYA/wom/GMeL1R/rthJJJPYn//1vU7LGVVuteYYwFzj4AC SvBa92Vks9V4Yci0epY4gAeo/wB9jnO9rWt37l7P9askYv1b6lcf+49jB8Xj0m/9J68h6L0q3q3U qOmUvFT79wFjgXBoY11jiWtj9xaPw8CMMkyaHf8Au6tLnLM8cAL8PN6X63dN+pGJ0wP6NbWc82N2 MovdfLZ/S+q11tza2bPdv/0ij/ixwb7utXZ7QRjY1Lq32djZYWbaf8xjrH/ufo/9Is/6yfUzM+r2 LTlXZFeRVdZ6PsaWFri11jdHOfua5tb10v8Aiy61lZDMjpF8PqxWNsxnAAFrSSyyp5b9P3bX17vf /OfyE/Ia5WRhM5Qd5zOvCtgL5iPHEYyBoIvNfX3I9f615mstoFVLT/VY2x3/AIJbYp/UPrP7L69X XY6MbPjHtHYPJ/VrP7Nh9L/r6yeq2nP61mW1GftWXZ6Z8n2FlX/RLVc+t/RR0Xrl2NUCzGtAvxCD wx35rXf8Bc17P+21PwxOOOCX6UP+jwsPFL3JZhtGf5pfr3k+t9ac50yyn06m+WytheP+3XWL0z6u 1MwPqxgNscKm1YjH2vfo1pLPVue+fota5z143kWX9RzX22w6/Ntl+0QC610Ohv8AaXt2dlY/TsGX PpqAAqp+0P8ATrLo9jH2bX7fa39xU+f/AFeHFAn5Rr/gDhbfIg5Ms5AE8RAA/vPKtdl1Mc3odjci utzLcvIxMZ1e4Vu3bfXfdY7Of7v6Ox38z+j9T8xLJowrcDqnUKeo03W5gopyH1sOOaw+yut3rt9X dUy2sfpvWr3/AMtXcj633Y3pAfs7Jda8MZXj5hc7mPpOx2U1t/42xit9V+stGNS1+JVVnC5riIsA 3OY/0IY303+v722fQ/0SwiMQEryfKNvX6OL0gwjxPRXzIlD9VrOQ9XFivLwSjOUcs+D/AFfo/m/+ qPMWVYT3vrw2vtqZbc7HxqH2fpm2vrosxGvod6np5GBhfaPU/mdl/wDwi3a7Psv1KycjHufYbmPI JfY70t59D0a3X7r2Mw2/o/8Arfqqf/O6uux1bqsetzai5gNxjcHNZ6TrG0HY11X6RqLlfWZ9Gbdi Cmhwoa4Wg3ta4PFTcnc5tjWVsxd9teP69tlf6RDH7YEiMt2ODSMvRKfyqyHmJ8EThNQl7tSyxPHD H84/5/zOTZj9GqyPU6XdisOLutZcOoOsssDK3FjPs9jvSZuu2eo+yz9HUql7cNvSyzeNtjiaXQ21 r2YmMzDZ6Pr+p/PZz7a8ezH/AEtnq/olu9L+tLOo5NNFePUPVfsdF1RcGisusf6O/wBZ/wCsN2M/ R+/H/To+R1vMwsmmnqGJjsY8Gy003PtdXVXq7IfV9lr/AEbbNjGf8IiYYzEyE+GJ00jwx1T7nMQm ISxmUxHi4ZZozySjHiP6XF6uKLzZw+n1UZbHht7enUZXqSxjQLh6eFi+t6W31LXvZfbjWZO/I/wq 7jp2FVgYNGHU0NZQwMhogEge9/8AWe/3vQMbq3TcyvItx5fTQN1trq3MYSAXQHWtZ6j2NZ7tv0E/ Q87I6h0rHzchja7b2l5aydoBJ2Ru/eZtU2CEIy9MuLijYI/dj4/4rU5vLmyQ9cZQGOYEozP6eSPH H0en/Wf47fSSSVhov//X6z/GRkGn6sWVCZybqqtAToHeu7j+RSvMMHNzen5LcvCc+nIYHBtgZJAc Nr/ptc36K94XK0fWHqDLPtd+92JYzKvZU+tjA+qoudjV4VrX+pZkPZ6P9Ib6T6/Vs9itYObGLGYe 3xWSTr38OFr5uXOSYnx8NbUHzzJyPrH157HXDK6g6uRW1tbnBs/S2sqZsbu2+5y736p9ByPqz0TO 6hnANzbaza+sEO9Oulr31VbmfSs3OsfZs/74tav6xP8AXNV+I6sVP9LJsa7eyt/p/af53Yyl1VVW z7Ra6yv0bf8AtxVb/rVY1tbjQ6jbkV12NHv3NspsyGVh1gobW/f6DLrnfqtXq+r9pexLLzhnHgEB CF6xH5Kx8sISMjIynXzF81+q+M/J6/0yosJnIre8EGIYfXf/ANQvQf8AGP0Y53Rhn1N3X9OJsMcm l2mQP7EMv/60rd/XupMy7GNprLaLLC5geBNVGOy3J33Pb7dmZl0s9Rrf8H6f/CKwPrFbZkfZ6MJz 3WOFdG+xrC54qZlX72w/0qcdlnpWW/pP1j9H6f56WTnJTywyCPDwdLu/3lQ5YRhKBN8fg+W/VfFf k/WPptQaf6Qywy0xFX6w/n+TUvVvrAMnKoHTMWvc7Ka717Xe2tlI/nQ+2HbX5E+hX7fz7Lf8Eh1/ WfGsxm5XpOZS40jc4jT1a/tlv0d39Fxf0r9n85/gkJ3XuoX2VUUYno5D7KCGOe1wNVrcjILbHtn0 LW04jvW+n9P9D6yi5vMeYrTgFcOhtl5SH3c2PWQeIXp6v0f8V5+ro+d1HDzcqhvq47mBjfeZtbS3 1W1srdhY78ljrP0Vf9E/66rnXMcXZeNdj4loq2Y9GPX6b2sY07rXOo9G+lrXtps9D0/Tr/c3rq+n 5gzsGjMDDX69bbNjiCW7hO2R9JWFQ+6DhMeI6/Mf8b/vnSPxGfGJcFCN8I4uhEY+r/wt5RmPn05X StlT8LGbvofkBrrHn7Q5mW+r0rX5V2Kz1Kfs/r3Xex9n+DZ6azLcI512Za/Hsd6pdZsbTY2wevcx 7abrKqr3u9TAx2We+n06N/p2LvkkZcrxacZr/wBB4UQ+ISib4PV+8Dr85yS4j6perieS6VWf2x9t yKbrH4OI8saQXWMk+yjb9lwPfbV6noUfpf8ArabG6liOpuzLMx+L1fNLTZcMay30a2mWYVTbKfT2 MZ/OO/Pv9S5dckiMEgKE+5Ng7y/S9M4epaecjIkmB2jEcMh8sPXwevHkjwSn6+F51+WbPq31Cy7P +1MIfU3IfjvqLd7WV+m6hjA+332fSrrW3g4rcPCx8Ruox6mVAj+Q0M/gjpKWEKNk36eHr/3UpMGT LxDhA4QZGdentwx0hDGpJJJPYn//0PVVn0dA6NQ0tpxK2tLQzbEgNa5trWNB+iz1GMfsatBJJTSt 6P0u66y+3GY+y5pbYXCQ7c30nuLPoeo+r9E63+c9L9Gmb0XpTWPZ9mY4Wh7bS+Xl4sa2i31X2Fz7 PUpqrq9/+DV5JJTTd0vpjfXsdQyLmPbeTrLHhjb26/m2tpr9X/SbFh4+b0zNxcenPwCTa5lt1tbd tTLcqp+Y73+r6/8AMO25W32fpP0n6JdLdSy+mymwTXa0seASDDhtd7m+5U3dE6Y6o1GmGOcXwHOH uNH7O9sO9v6n+i/9SJKchmV0e61tlPTrqc7IZW7EAZUHxbRbXXfWx9j8Wh9OLXbTZ9o/M9On3/oq 1HpV/RcdjHspdZde+u1n6JtYaLKHDdVUHfoqsbEpuru92/1PUq/wlTFs39E6de4vcxzXlzXCxlj2 ObtZ9nit9bmuY11J9N+xNZ0HpNgcDjtAfijBIaS0DHBJbQwNPsb7vzUlOdT9ZMVmPQzCxSMep/ov aHVltdLKHZW+p1NtlVnpVsra6ttns/7a9Q4+stNWN6uTVaQyt+69jAK33UsN2Tj0Nda6zd7La2b/ ANH6tdlPrKw/6v8ATLGuFjbLC8vdY51thc82VNw7fUdv92/HYxmz/MTu6B0t9j7HVuPqFx2F79jS 97b7/Sr3bKvXtZuu9P8AnElJ8HObmesPSsofj2elYyzbMlleQ0/o3WN91V9aoXdfa36wUdLqfSWE mrIBd+l9V1b8mkVVz/NV11fp37P+1NH7ly1KManHNpqEG+w22EkmXkBs+7+Sxqr/ALI6eccYxqmt txyNXO3G0uNzrXWbt7nOe7/0X/NpKaeN9ZsbKqbZj491jrXiuitpr3PO11zw5vq/qzqWV/p2ZfoP q/R/n2KLvrb0xtr6i2wOra42NO0Oa9lX2qyl9Rs9Vrm1t2eps+z+v+h9berH/NzpW2Cyw2TJuNtn qkbfR9M5G/1vS9H9Hs3/APgil+wemRa1tbmVXNLXUtse2obtLPToa70q3WNb79jP/PliSkLevWW5 OPj04lrX2ZHo3i3aCxno/bPV9tjvzX1ez/1H6muqg6ZhjLGYGuF4e6zdud9J7GY75bu27fSpq9n8 hW0lKSSSSU//2f/tJ8ZQaG90b3Nob3AgMy4wADhCSU0EJQAAAAAAEAAAAAAAAAAAAAAAAAAAAAA4 QklNBDoAAAAAAJMAAAAQAAAAAQAAAAAAC3ByaW50T3V0cHV0AAAABQAAAABDbHJTZW51bQAAAABD bHJTAAAAAFJHQkMAAAAASW50ZWVudW0AAAAASW50ZQAAAABJbWcgAAAAAE1wQmxib29sAQAAAA9w cmludFNpeHRlZW5CaXRib29sAAAAAAtwcmludGVyTmFtZVRFWFQAAAABAAAAOEJJTQQ7AAAAAAGy AAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAASAAAAAENwdG5ib29sAAAAAABDbGJy Ym9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9vbAAAAAAATGJsc2Jvb2wA AAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAAAEJja2dPYmpjAAAAAQAA AAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRvdWJAb+AAAAAAAAAAAABC bCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAAAEJsZCBVbnRGI1JsdAAA AAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBSAAAAAAAAAAAACnZlY3RvckRhdGFib29sAQAAAABQZ1Bz ZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAAAAAAAAAAVG9wIFVudEYj Umx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAA4QklNA+0AAAAAABAASAAAAAEAAgBI AAAAAQACOEJJTQQmAAAAAAAOAAAAAAAAAAAAAD+AAAA4QklNBA0AAAAAAAQAAAB4OEJJTQQZAAAA AAAEAAAAHjhCSU0D8wAAAAAACQAAAAAAAAAAAQA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1 AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAA AAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD///////////////////////////// A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////////8D 6AAAAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgAIOEJJTQQCAAAAAAAS AAAAAAAAAAAAAAAAAAAAAAAAOEJJTQQwAAAAAAAJAQEBAQEBAQEBADhCSU0ELQAAAAAAAgAAOEJJ TQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhCSU0EHgAAAAAABAAAAAA4QklNBBoAAAAAAzkAAAAG AAAAAAAAAAAAAADGAAAAoAAAAAIAQgBOAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA AACgAAAAxgAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVs bAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAxgAAAABSZ2h0bG9uZwAAAKAAAAAGc2xpY2VzVmxM cwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJ RGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQA AAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAA UmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAMYA AAAAUmdodGxvbmcAAACgAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNn ZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAA CGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAA AAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQA AAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0 c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAA AAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAA AAAEAAAACzhCSU0EDAAAAAAeUQAAAAEAAACBAAAAoAAAAYQAAPKAAAAeNQAYAAH/2P/tAAxBZG9i ZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEM DAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQR DAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAoACBAwEiAAIR AQMRAf/dAAQACf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAA AAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIj JBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITES BEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi 8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMR AD8A9VSSSSUpJJDvvqoZvsMAkNaAJJcfosY0e5zklEgCzokQbMljZDGuuePzKxJn93c7bWz+29Qb Xff7sj9Gz82hp1j/AIaxv0v+Lr/R/wDGoll2PjtAcQwD6LR/BrU4DWvmPgtMtL+Udy4lnXuou6uz pLqqen2WMFjLLybg+fo1sZUcdnqaP/w62KactoHrZAsPfZWGD7nOtd/01k9YZ0/qtIqvqMs1qvBA ew+LIn/MVWjrXVOnsFOaRk0N0ZmNBLgP+7DJ3f2//PqnOIyiOGIif0on/pRl/wBy0/vAxzl7sjOB NxyDaP8AVyQjw/8Ahj0oa8fnz8QFJ0x7RJ8DosZnXHlocPTsYeHCdfxVirrmM4xaDX5j3D8Pd/0V GcGQfo35M8eZxH9Kr7/xdAPHDgWnz/vUlCuyq5m+twsYe4MhRc19fur9ze9Z/wDRbio66bM16XuP BKkoVW13Viys7mu+XGha4H6Lm/nNU0Eg3qFJJJJKUkkkkp//0PVUkkklIcvKow8a3KyHbKqWl73e Q8P5TvzVCih7njJyB+nIhjORW0/mM/l/6Wz8/wD4tZ/1optyuh5zK/zGBzR4ljm22H+y1iQ65VlY mPbUQG2s9XIM6MaP52r+vv8AZ/6sUscZMQY7kmMvAU155oxyGM9BGInH+seKUZf4nobOZ1JrBtqP Jjfzx9LZ/V/eWPkZQbvdu3bfpk8jzcqXWeosJF2Md9Fg2NPG17R7qnN/M/fWPl5toyfUa8tcQ14j +U1rz/1Sv4OV0B2vu5fN/EPUQPVRG3y1L9KLp3dXY36Jn4Kq/qz3fR9p8+Cs59ld+tYFd3evhrv+ K/dd/wAF/wBtqq66DB0I0IVyOGA6a+Lnzz55H5tP6rpDNex5IGyeQ3T8PoqYzMh2tTvUjlvDh/ZW R9oPB1HgU/rDlroI4kwfk5OMI9h+xi4Mn6MiPB2sbrmZiWG2l+14+kOxj82xn5y7HofX8fqtewxV lsE2Uzz/AC6v3mf9QvPqbLbx+sVF1fe8+zaPE2Ha16NtsxiLsR7hY3VjmO9wkbXPa5nu7qvzHL48 gquGf6Mh/wB0z8p8Ry8vk4ZEzh+lAmx/gy/Rk9/gWGzM6h6UGmu4NBB0L9jPtDP7D/8Awb1VoAgi Qsv6s5+HmdJq+y1to9H9HbQ2YY8au+l7nepu9Xf/AOjFfLzXktYfoXA7fJ7dSP7bP/PayckSJyiR Rjpr/VelwyBxxkDYn6rG3rP8oJkkklGyqSSSSU//0fVVF7i1hI1PYefZSVLqozn0MowLRRkXWNaL 3N3hjRNlr/TPte7YzYz+ujEWQNvNbI1EmifAbp77KsXFsss1rqYXOnuANf8AOXnpe+ltuPUQym8t sNY/Nn3MZP8Ar/g1q9f6OMDEruys/JzLbLNrvUf7IAc87a/d+c1v5yw8dwcJBmDB+K0uUxCMDMHi 4jvWnpee+Mczk4ow4PbMB+9xS/Wb3w/1UuPU5u5ljt1FwDbWRB0+hYw/6Wp30P8Atv8APWb1Fxpv FbyJaxg3djA27m/ctdqDm5oo201ub67wS0PAc0R9Fj/3PW/MVqMzxXvblYM+SRGLhE9yL9PDXq+b 91w2+rdpVW6z+qCR/nfRU3xxl3VVOHB3h9n9V1WP6rnf21Kz6yXlprtqqc0aFj2GAR2LN6G3rdbj tb0/FM+Fe3TxKk4pdm4MWfrjAH9WceL/ABp8P/QWf9lpgu9XI3fRc3bVWf6rz61jkvt4pP6Kuqp/ 8lvqOHxuyN/v/qMT/tfCbIb0/H930y3c0E/yfapU29GubuHT2ADRwFjxB/kwhZPQp4SBeTFOQ/vY iD5w9yMP+ajbmvufNznPA7vcSZ8E1dvu31OIdyI0cEYO6V6gacB1bWk7XDIdB/qtd9LcoPt6DU7a abtw7C0mPmjddCF136RinVbD2tv8HI7P1e63nYucwUNYbMktrcH+1th19Ntn7j93trtW0z66Pu6n j/aaWU4TbJ3AkvbuY+nfY72sdXus3v8AYuQGZgQPRxnkmNu58kn81W82i2kN9Zjmes0PrkEbmu7s /eVfJhxzlZjRI4V8OYz4RGMBOGMS4uGXCY/ZHi4YvqdF1eRTXfUd1drQ9jh3a4bmlEVHowzG9Pqq za21X0gVuDNGENA2OYPzfZ+Z++ryx5CiR2L0kDxRBOljyUkkkguf/9L1VRP0h8CpKl1VtlmL6Nbi x2Q9tLrGmHNY9wba5h/f9LdsRiLIHdEjUSd66PKfXLqdeZ9n9BrnY1b7Wtv4ZY9uxtno/nPrp+h6 383v/m1yz8u2pwcHlpbw1ujR8Qu0+veLVT03CsY306saz0mMYIAa5nsa391rfRauBtydn80xrT+8 fc7/AKS2eT4TgjWw4h/znnufxH71PiHGZCP935W3X1PqljgGEBk62GsbQB4/vI+VjYnWA9tL24/U Ga2VkyHNH5z2/S/t/Tr/AMIsN2TeXm02OLmDQk9z7WqFQcx7bi5zbAd7HAw8n9/f+apzEdNCwfdq InAjFOI9PBHc/u5P34Oi7Bbq3KZuyI22WEFrtPbv5/d/wn+EVMGnbtbWS3uXOjd5u2BbFGfR1Ktu N1A+jkD+ayWe0E9v5LHf8G/9FYq2Z027Gs97RqdHN+i7+Uz9x379SIl0Io/msx5SJGGS4z3Eb9P9 7H/V/wCg0QY+jWxv9ncf+nuRG22M0d7/AB7AHwbtRBXt/rfkTigmO06Dz/qt+k5OZDIHpbVeG2Em wBr+zx+R4/7+l9jufc2tlZttt1ZW3Wf3nOP5jP6y0DhNph2U80A6hgAde4fyavo0f17kK7JJpdj0 s9DGP06wSXv87r/pP/qfzSbvt9qY5v8AN+rxP83Hy/f/AMH/AMba5uZghzKbBflukPvbrXUOCzF/ 0l37+R+Z/gV6t9UYt+rHTHPAcW0t2k6xt9rTqvIrKSGkt1aB8IXs/wBXsU4nQun4zhDq8eoOH8ra 0v8A+kqPxHSEB1Mv2On8NA4pn5iQOIlvDl3+vZSUW8k+akst1FJJJJKf/9P1VReJbxJGoB8RqpJJ Kcz6x9PPU+iZWNWN1rmb6Y7vYfVrA/rubsXjltkifHsvdG6Es+bfgvLvrz0F3SeqHNoZ+p5zi9h7 MuMvto/k+p7shn/XKq/5taHw/MAZYifm9Uf+6aHP4eLhygWY+mXk846v0SGOh1n0nDkNJ+ju/e2q TGkmTqTySoV1k6kjzcSIn4q9RiFw3SC0cu+i0f1rHrSsOXM8I1PmWDK50iZ7crY6Zdc79Tui6og6 OklscN3D83+uq1Yx6xDW+ue8Haz/ANK2f9BF332N2H21/wCjYNrf81v0v7SRHEK/Fo5zxgjh8pS0 4T+9H9L/AKDbf0vHEvDnNiSRAJgaw0uVIZBAP2VookavHutI87XfR/62reK3JaZrkgctJO2Pn9FP kYldgNtAAs7tEFpP/Uf5qA9JqR4vH/vmCJmP5wmcf0Zfof4blOq5Pc6k8koL2Qrr6njSxorJ4jv/ AGkGysCfyqRsxnrqv0Xpp6j1fFwQJrteDd/xTP0l3/Qbs/tr2AmBJ7LlvqN0J2HjO6nkNjIy2gVN PLaZ3a/yr3fpP6npLp3GXBkSBq4/9SsbnswyZeEfLj0/wv0no+QwnHhuQ9WT1fT9Fk0ENE89/inS SVNuKSSSSU//1PVUkkklMXhxb7fpjVs8T/K/krHu6HldTw343V851zLY9aimuplYIO8Cv1a7sj9G 7+bs9XetpRc3WW6O/L5FOjMx20Pelk4CW9+QJj/0XyXqvSbug9QtpuDLqgWtrvYCZD9zqmXbi6vH u2Vu/Rf4T/B+xVXXMtcJYdrfojdEf2W+1eqNw6HX5uPmVNsq6g5tu14Dmu2110PqM/6P7P6v9v8A kLneqf4vWAm3o9oZOv2a8kj/AK1f7nt/q2+p/wAatPBzsCQMp4ZUPX+jJyOY+HSJOTEOLU+i/VH9 2v8ABeTr9L91w+YP/fVboYHEBsgnxAP5E9/ROr4ZIyMS5gHL2jez/tyn1GqOOQ14Jc5sHXWD+KvC QlG4S4vI8TkZccoGpiUf7w/756LA6c8gE4/r+G61v/nt4bWr2RiWOqIsw7dsfmuqdx+7tsVbplpI AqzbQ790Cuz/AKJrWk9vVC3ayxto/wCFx3NP+djv/wDRazcs5CepH143Zw4ccsVAyIIqqw8P/R4n jLbGPBDhI8D/ABWn0X6v3OvZl5uHffiiH00ez3nsbvXtq/Qt/wBG/wDnv+K+nqZ3Qr8nEtLMM25d jdLLHNqY0z9OljXWWvd/4ZRfqtX1DP6VTk5ebY7HdLaaWAMO1hNX6TIb+nfu2/muYnZOZPtngkB+ jL6/ucLX5T4ccecDJxS044aVD0/v+5/6j43Sdn9Ste6rHw212DSb7W+2eHvrxftH+b6le9aDGuaw Bx3Oj3OAiT47U1VVdTAypoYwcACAprOkQdgA7sIkaykZHx6f4vCpJJJNXqSSSSU//9X1VJJcXnf4 zMPEzsnEODbYca2ykvD2gONbjU5wB/lNT8eKeQkQHFS2eSMBcjVvaJLhf/HVw/8Ayuu/z2Le+rf1 u6b9YPUroa+jKpAdZj2xO06epU5pc2yvd7P9a0+fLZoR4pQIA6rY5scjUZAl2rK2WN2vG4fx8R+6 5Aurzmsd9lsY50extwJE9psrLXf9B6w/rJ9d8boGezBsxX5D31C4uY5rQA5z62t93/Fq79WvrJi/ WHEsyKK3UPps9Oyl5BI0D2P9v5j2lD2skYDIY+g9VccJSML9fhoW1VblViMxlpcfpOqAdWD/AMH6 X6zt/wCMrRRiYVzQ91Tbp1BtBef/AAbc5qwvrJ9d8boHUGYNmLZkPfU24uY5rQA5z62t93/FLW6D 1dvWul09SZU6hlxeG1uIJ9j30zLf3vTSlDIIDJw8MZbEFETAyML4yNxIXJvNa1g2sAaBwAICksSz 6zA2Ppxen5WRcA41thjA9rHek6332esyn1Pz30omN9YqsjeG4mQwtrte0vFYa51JDbqfVZa9lVrX nb+m9NVvexk1xNw8pmAvhoecf+i6WTjsyaXUWE+nYNrw07SWn6TNzfd7v5KnXXXVW2utoZWwBrGN EAAaNa1o+i1qxj9aK68WvKvwshjL278dg9N731hvq23bG2/oq6a9vqet6f01Z6X1ujPxLMiyt+Gc cA5Db4aGgsbd6gt+g6nY7+cRGaBIiJa78KJcpliDMw0HpMgYy/6P9b/nukksav6xOddS+zDsp6bk v9OjPsc0NcTPpPdR/PVU3ub+hts+nvp/0qi360Y7633MxrnUsZQ8Ebd5OQ+yikem57Wf4L/S/wCF Yh72Pv8AgenX+6n7pn/c7bGO8jwcJ/r8X6DtpLEH1kcWmv8AZ97csWCkUPdW0F5achzPW9TYzZjD 1nep/pK1p4ORfk44tvoOM8kj0y9tmgOjt9Jcz3IxyRkaBv6FbkwZMYuYA/wom/GMeL1R/rthJJJP Yn//1vU7LGVVuteYYwFzj4ACSvBa92Vks9V4Yci0epY4gAeo/wB9jnO9rWt37l7P9askYv1b6lcf +49jB8Xj0m/9J68h6L0q3q3UqOmUvFT79wFjgXBoY11jiWtj9xaPw8CMMkyaHf8Au6tLnLM8cAL8 PN6X63dN+pGJ0wP6NbWc82N2MovdfLZ/S+q11tza2bPdv/0ij/ixwb7utXZ7QRjY1Lq32djZYWba f8xjrH/ufo/9Is/6yfUzM+r2LTlXZFeRVdZ6PsaWFri11jdHOfua5tb10v8Aiy61lZDMjpF8PqxW NsxnAAFrSSyyp5b9P3bX17vf/OfyE/Ia5WRhM5Qd5zOvCtgL5iPHEYyBoIvNfX3I9f615mstoFVL T/VY2x3/AIJbYp/UPrP7L69XXY6MbPjHtHYPJ/VrP7Nh9L/r6yeq2nP61mW1GftWXZ6Z8n2FlX/R LVc+t/RR0Xrl2NUCzGtAvxCDwx35rXf8Bc17P+21PwxOOOCX6UP+jwsPFL3JZhtGf5pfr3k+t9ac 50yyn06m+WytheP+3XWL0z6u1MwPqxgNscKm1YjH2vfo1pLPVue+fota5z143kWX9RzX22w6/Ntl +0QC610Ohv8AaXt2dlY/TsGXPpqAAqp+0P8ATrLo9jH2bX7fa39xU+f/AFeHFAn5Rr/gDhbfIg5M s5AE8RAA/vPKtdl1Mc3odjciutzLcvIxMZ1e4Vu3bfXfdY7Of7v6Ox38z+j9T8xLJowrcDqnUKeo 03W5gopyH1sOOaw+yut3rt9XdUy2sfpvWr3/AMtXcj633Y3pAfs7Jda8MZXj5hc7mPpOx2U1t/42 xit9V+stGNS1+JVVnC5riIsA3OY/0IY303+v722fQ/0SwiMQEryfKNvX6OL0gwjxPRXzIlD9VrOQ 9XFivLwSjOUcs+D/AFfo/m/+qPMWVYT3vrw2vtqZbc7HxqH2fpm2vrosxGvod6np5GBhfaPU/mdl /wDwi3a7Psv1KycjHufYbmPIJfY70t59D0a3X7r2Mw2/o/8Arfqqf/O6uux1bqsetzai5gNxjcHN Z6TrG0HY11X6RqLlfWZ9GbdiCmhwoa4Wg3ta4PFTcnc5tjWVsxd9teP69tlf6RDH7YEiMt2ODSMv RKfyqyHmJ8EThNQl7tSyxPHDH84/5/zOTZj9GqyPU6XdisOLutZcOoOsssDK3FjPs9jvSZuu2eo+ yz9HUql7cNvSyzeNtjiaXQ21r2YmMzDZ6Pr+p/PZz7a8ezH/AEtnq/olu9L+tLOo5NNFePUPVfsd F1RcGisusf6O/wBZ/wCsN2M/R+/H/To+R1vMwsmmnqGJjsY8Gy003PtdXVXq7IfV9lr/AEbbNjGf 8IiYYzEyE+GJ00jwx1T7nMQmISxmUxHi4ZZozySjHiP6XF6uKLzZw+n1UZbHht7enUZXqSxjQLh6 eFi+t6W31LXvZfbjWZO/I/wq7jp2FVgYNGHU0NZQwMhogEge9/8AWe/3vQMbq3TcyvItx5fTQN1t rq3MYSAXQHWtZ6j2NZ7tv0E/Q87I6h0rHzchja7b2l5aydoBJ2Ru/eZtU2CEIy9MuLijYI/dj4/4 rU5vLmyQ9cZQGOYEozP6eSPHH0en/Wf47fSSSVhov//X6z/GRkGn6sWVCZybqqtAToHeu7j+RSvM MHNzen5LcvCc+nIYHBtgZJAcNr/ptc36K94XK0fWHqDLPtd+92JYzKvZU+tjA+qoudjV4VrX+pZk PZ6P9Ib6T6/Vs9itYObGLGYe3xWSTr38OFr5uXOSYnx8NbUHzzJyPrH157HXDK6g6uRW1tbnBs/S 2sqZsbu2+5y736p9ByPqz0TO6hnANzbaza+sEO9Oulr31VbmfSs3OsfZs/74tav6xP8AXNV+I6sV P9LJsa7eyt/p/af53Yyl1VVWz7Ra6yv0bf8AtxVb/rVY1tbjQ6jbkV12NHv3NspsyGVh1gobW/f6 DLrnfqtXq+r9pexLLzhnHgEBCF6xH5Kx8sISMjIynXzF81+q+M/J6/0yosJnIre8EGIYfXf/ANQv Qf8AGP0Y53Rhn1N3X9OJsMcml2mQP7EMv/60rd/XupMy7GNprLaLLC5geBNVGOy3J33Pb7dmZl0s 9Rrf8H6f/CKwPrFbZkfZ6MJz3WOFdG+xrC54qZlX72w/0qcdlnpWW/pP1j9H6f56WTnJTywyCPDw dLu/3lQ5YRhKBN8fg+W/VfFfk/WPptQaf6Qywy0xFX6w/n+TUvVvrAMnKoHTMWvc7Ka717Xe2tlI /nQ+2HbX5E+hX7fz7Lf8Eh1/WfGsxm5XpOZS40jc4jT1a/tlv0d39Fxf0r9n85/gkJ3XuoX2VUUY no5D7KCGOe1wNVrcjILbHtn0LW04jvW+n9P9D6yi5vMeYrTgFcOhtl5SH3c2PWQeIXp6v0f8V5+r o+d1HDzcqhvq47mBjfeZtbS31W1srdhY78ljrP0Vf9E/66rnXMcXZeNdj4loq2Y9GPX6b2sY07rX Oo9G+lrXtps9D0/Tr/c3rq+n5gzsGjMDDX69bbNjiCW7hO2R9JWFQ+6DhMeI6/Mf8b/vnSPxGfGJ cFCN8I4uhEY+r/wt5RmPn05XStlT8LGbvofkBrrHn7Q5mW+r0rX5V2Kz1Kfs/r3Xex9n+DZ6azLc I512Za/Hsd6pdZsbTY2wevcx7abrKqr3u9TAx2We+n06N/p2LvkkZcrxacZr/wBB4UQ+ISib4PV+ 8Dr85yS4j6perieS6VWf2x9tyKbrH4OI8saQXWMk+yjb9lwPfbV6noUfpf8ArabG6liOpuzLMx+L 1fNLTZcMay30a2mWYVTbKfT2MZ/OO/Pv9S5dckiMEgKE+5Ng7y/S9M4epaecjIkmB2jEcMh8sPXw evHkjwSn6+F51+WbPq31Cy7P+1MIfU3IfjvqLd7WV+m6hjA+332fSrrW3g4rcPCx8Ruox6mVAj+Q 0M/gjpKWEKNk36eHr/3UpMGTLxDhA4QZGdentwx0hDGpJJJPYn//0PVVn0dA6NQ0tpxK2tLQzbEg Na5trWNB+iz1GMfsatBJJTSt6P0u66y+3GY+y5pbYXCQ7c30nuLPoeo+r9E63+c9L9Gmb0XpTWPZ 9mY4Wh7bS+Xl4sa2i31X2Fz7PUpqrq9/+DV5JJTTd0vpjfXsdQyLmPbeTrLHhjb26/m2tpr9X/Sb Fh4+b0zNxcenPwCTa5lt1tbdtTLcqp+Y73+r6/8AMO25W32fpP0n6JdLdSy+mymwTXa0seASDDht d7m+5U3dE6Y6o1GmGOcXwHOHuNH7O9sO9v6n+i/9SJKchmV0e61tlPTrqc7IZW7EAZUHxbRbXXfW x9j8Wh9OLXbTZ9o/M9On3/oq1HpV/RcdjHspdZde+u1n6JtYaLKHDdVUHfoqsbEpuru92/1PUq/w lTFs39E6de4vcxzXlzXCxlj2ObtZ9nit9bmuY11J9N+xNZ0HpNgcDjtAfijBIaS0DHBJbQwNPsb7 vzUlOdT9ZMVmPQzCxSMep/ovaHVltdLKHZW+p1NtlVnpVsra6ttns/7a9Q4+stNWN6uTVaQyt+69 jAK33UsN2Tj0Nda6zd7La2b/ANH6tdlPrKw/6v8ATLGuFjbLC8vdY51thc82VNw7fUdv92/HYxmz /MTu6B0t9j7HVuPqFx2F79jS97b7/Sr3bKvXtZuu9P8AnElJ8HObmesPSsofj2elYyzbMlleQ0/o 3WN91V9aoXdfa36wUdLqfSWEmrIBd+l9V1b8mkVVz/NV11fp37P+1NH7ly1KManHNpqEG+w22Ekm XkBs+7+Sxqr/ALI6eccYxqmttxyNXO3G0uNzrXWbt7nOe7/0X/NpKaeN9ZsbKqbZj491jrXiuitp r3PO11zw5vq/qzqWV/p2ZfoPq/R/n2KLvrb0xtr6i2wOra42NO0Oa9lX2qyl9Rs9Vrm1t2eps+z+ v+h9berH/NzpW2Cyw2TJuNtnqkbfR9M5G/1vS9H9Hs3/APgil+wemRa1tbmVXNLXUtse2obtLPTo a70q3WNb79jP/PliSkLevWW5OPj04lrX2ZHo3i3aCxno/bPV9tjvzX1ez/1H6muqg6ZhjLGYGuF4 e6zdud9J7GY75bu27fSpq9n8hW0lKSSSSU//2QA4QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8A YgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBw ACAAQwBTADUAAAABADhCSU0PoAAAAAAA+G1hbmlJUkZSAAAA7DhCSU1BbkRzAAAAzAAAABAAAAAB AAAAAAAAbnVsbAAAAAMAAAAAQUZTdGxvbmcAAAAAAAAAAEZySW5WbExzAAAAAU9iamMAAAABAAAA AAAAbnVsbAAAAAEAAAAARnJJRGxvbmdHI0uGAAAAAEZTdHNWbExzAAAAAU9iamMAAAABAAAAAAAA bnVsbAAAAAQAAAAARnNJRGxvbmcAAAAAAAAAAEFGcm1sb25nAAAAAAAAAABGc0ZyVmxMcwAAAAFs b25nRyNLhgAAAABMQ250bG9uZwAAAAAAADhCSU1Sb2xsAAAACAAAAAAAAAAAOEJJTQ+hAAAAAAAc bWZyaQAAAAIAAAAQAAAAAQAAAAAAAAABAAAAADhCSU0EBgAAAAAABwAIAAAAAQEA/+EWMmh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIg eDp4bXB0az0iQWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3 OjMyOjAwICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0i aHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJs Lm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wL21tLyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlw ZS9SZXNvdXJjZUV2ZW50IyIgeG1sbnM6c3RSZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEu MC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENT NSBXaW5kb3dzIiB4bXA6Q3JlYXRlRGF0ZT0iMjAxNC0wOC0xMlQxNjoyODozMyswODowMCIgeG1w Ok1ldGFkYXRhRGF0ZT0iMjAxNC0wOC0xMlQxNjozNyswODowMCIgeG1wOk1vZGlmeURhdGU9IjIw MTQtMDgtMTJUMTY6MzcrMDg6MDAiIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHBob3Rvc2hvcDpJ Q0NQcm9maWxlPSJzUkdCIElFQzYxOTY2LTIuMSIgZGM6Zm9ybWF0PSJpbWFnZS9qcGVnIiB4bXBN TTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjEwN0MwRkQ0RkIyMUU0MTE5ODY1QjgyMDYxRUIyNkNDIiB4 bXBNTTpEb2N1bWVudElEPSJ4bXAuZGlkOjNDRDI3QzlERUUyMUU0MTE5ODY1QjgyMDYxRUIyNkND IiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9InhtcC5kaWQ6M0NEMjdDOURFRTIxRTQxMTk4NjVC ODIwNjFFQjI2Q0MiPiA8cGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJk ZjpsaT5hZG9iZTpkb2NpZDpwaG90b3Nob3A6MGMxMzZiYWMtODYyMS0xMWRkLWJjMGYtZTgwNGFm YjAzOTg4PC9yZGY6bGk+IDxyZGY6bGk+YWRvYmU6ZG9jaWQ6cGhvdG9zaG9wOmRjOGY5ZTk4LTE2 Y2QtMTFkYi05Mjg1LWJjYWM2NGZhNDExNzwvcmRmOmxpPiA8cmRmOmxpPmFkb2JlOmRvY2lkOnBo b3Rvc2hvcDpkZmUwYWM3ZS0xNDIyLTExZTEtODE2ZS05ZWM3Nzc3ZmE2MzQ8L3JkZjpsaT4gPHJk ZjpsaT51dWlkOjJBRUY5MjNFMUJDRUUxMTFCRTVCRUJERTMyQTJDOUJGPC9yZGY6bGk+IDxyZGY6 bGk+dXVpZDo1QzhCNjgyRDdDQjlFMzExQUI2MjhFNDU2RTA5QTM3MTwvcmRmOmxpPiA8cmRmOmxp PnV1aWQ6OTM1NjI3MUVCRDRDRTExMUExQUVGM0FFNjQ4NURCNDY8L3JkZjpsaT4gPHJkZjpsaT51 dWlkOkM2NkM4QjBDNDFBNERFMTFCQTdGRUU1NDMzRDA0RjZEPC9yZGY6bGk+IDxyZGY6bGk+eG1w LmRpZDozRDkzQzE0RjJGRDhFMTExQUJDRkM5OEYwNTJCNkNDODwvcmRmOmxpPiA8cmRmOmxpPnht cC5kaWQ6NDU3NDIxRDMzODdBRTExMThBM0NDQTBDMUQzMTgwNEM8L3JkZjpsaT4gPHJkZjpsaT54 bXAuZGlkOjgyNTI3NzhDQTYzRkUyMTFBMUE1RDM2ODFGNUYwRDFDPC9yZGY6bGk+IDxyZGY6bGk+ eG1wLmRpZDpBNEU5NjVBNEMyMjYxMUUwOUUyMEFGQ0E1NTUxNDNCRjwvcmRmOmxpPiA8cmRmOmxp PnhtcC5kaWQ6QTdFNDhDOUVDMUQzRTIxMTgxRTA5RTEwODQ2NTM2QzU8L3JkZjpsaT4gPHJkZjps aT54bXAuZGlkOkMzN0M1Qzk2QkM4N0UyMTE5NjkzODdFMUU4ODY0NkQ5PC9yZGY6bGk+IDwvcmRm OkJhZz4gPC9waG90b3Nob3A6RG9jdW1lbnRBbmNlc3RvcnM+IDx4bXBNTTpIaXN0b3J5PiA8cmRm OlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249ImNyZWF0ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9Inht cC5paWQ6M0NEMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQt MDgtMTJUMTY6Mjg6MzMrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hv cCBDUzUgV2luZG93cyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3Rh bmNlSUQ9InhtcC5paWQ6M0REMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0Ondo ZW49IjIwMTQtMDgtMTJUMTY6Mjg6NDQrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2Jl IFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0 OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6M0VEMjdDOURFRTIxRTQx MTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQtMDgtMTJUMTY6Mjg6NDQrMDg6MDAi IHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6 Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNl SUQ9InhtcC5paWQ6M0ZEMjdDOURFRTIxRTQxMTk4NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49 IjIwMTQtMDgtMTJUMTY6MzY6NTYrMDg6MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBo b3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFj dGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6NDBEMjdDOURFRTIxRTQxMTk4 NjVCODIwNjFFQjI2Q0MiIHN0RXZ0OndoZW49IjIwMTQtMDgtMTJUMTY6MzcrMDg6MDAiIHN0RXZ0 OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzUgV2luZG93cyIgc3RFdnQ6Y2hhbmdl ZD0iLyIvPiA8cmRmOmxpIHN0RXZ0OmFjdGlvbj0iY29udmVydGVkIiBzdEV2dDpwYXJhbWV0ZXJz PSJmcm9tIGFwcGxpY2F0aW9uL3ZuZC5hZG9iZS5waG90b3Nob3AgdG8gaW1hZ2UvanBlZyIvPiA8 cmRmOmxpIHN0RXZ0OmFjdGlvbj0iZGVyaXZlZCIgc3RFdnQ6cGFyYW1ldGVycz0iY29udmVydGVk IGZyb20gYXBwbGljYXRpb24vdm5kLmFkb2JlLnBob3Rvc2hvcCB0byBpbWFnZS9qcGVnIi8+IDxy ZGY6bGkgc3RFdnQ6YWN0aW9uPSJzYXZlZCIgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDoxMDdD MEZENEZCMjFFNDExOTg2NUI4MjA2MUVCMjZDQyIgc3RFdnQ6d2hlbj0iMjAxNC0wOC0xMlQxNjoz NyswODowMCIgc3RFdnQ6c29mdHdhcmVBZ2VudD0iQWRvYmUgUGhvdG9zaG9wIENTNSBXaW5kb3dz IiBzdEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8eG1wTU06 RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDo0MEQyN0M5REVFMjFFNDExOTg2 NUI4MjA2MUVCMjZDQyIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDozQ0QyN0M5REVFMjFFNDEx OTg2NUI4MjA2MUVCMjZDQyIgc3RSZWY6b3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjNDRDI3 QzlERUUyMUU0MTE5ODY1QjgyMDYxRUIyNkNDIi8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpS REY+IDwveDp4bXBtZXRhPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDw/eHBhY2tldCBlbmQ9InciPz7/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlu bwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAA AAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAA ABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAAC xAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNo AAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHly aWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJ RUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVog AAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpY WVogAAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAA AAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNv bG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNv bG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJl bmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5j ZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAA Vx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAA AAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcA fACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwEN ARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB 2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLg AusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0E OwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXV BeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H 0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woR CicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcM wAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+z D88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMT IxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbW FvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwb FBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+U H78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwk qyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoC KjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv /jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3 NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9 Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RH RIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JM KkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRC VI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZd J114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9 ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9Fw K3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pG eqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOF R4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBu kNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByc iZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjE qTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2 AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NY w9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzR vtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A2 4L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070Dv zPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t ////7gAOQWRvYmUAZEAAAAAB/9sAhAABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAgICAgICAgICAgIDAwMDAwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwP/wAARCADGAKADAREAAhEBAxEB /90ABAAU/8QBogAAAAYCAwEAAAAAAAAAAAAABwgGBQQJAwoCAQALAQAABgMBAQEAAAAAAAAAAAAG BQQDBwIIAQkACgsQAAIBAwQBAwMCAwMDAgYJdQECAwQRBRIGIQcTIgAIMRRBMiMVCVFCFmEkMxdS cYEYYpElQ6Gx8CY0cgoZwdE1J+FTNoLxkqJEVHNFRjdHYyhVVlcassLS4vJkg3SThGWjs8PT4yk4 ZvN1Kjk6SElKWFlaZ2hpanZ3eHl6hYaHiImKlJWWl5iZmqSlpqeoqaq0tba3uLm6xMXGx8jJytTV 1tfY2drk5ebn6Onq9PX29/j5+hEAAgEDAgQEAwUEBAQGBgVtAQIDEQQhEgUxBgAiE0FRBzJhFHEI QoEjkRVSoWIWMwmxJMHRQ3LwF+GCNCWSUxhjRPGisiY1GVQ2RWQnCnODk0Z0wtLi8lVldVY3hIWj s8PT4/MpGpSktMTU5PSVpbXF1eX1KEdXZjh2hpamtsbW5vZnd4eXp7fH1+f3SFhoeIiYqLjI2Oj4 OUlZaXmJmam5ydnp+So6SlpqeoqaqrrK2ur6/9oADAMBAAIRAxEAPwDf49+691737r3Xvfuvde9+ 691737r3XvfuvdYp6iClhkqKqaKmp4UMk088iQwxIv6nklkZURB+SSB7siM7BEUlzwAyT+XVJJI4 UaWWRViUVJJAAHqScDooHenzY6x6O2vujdjbU7V7Ow+zcY+V3LlusNi12a2phaVZFgByG/stNgti CQTuqvDBkaipjB1NEB7HnLft3vPMd7ZWIvbKzuLh9Ma3EwSRzx7YVDzcOBMaqfJuod5697+VuR9q 3Td/3Tu26WdlHrmksrVpIIxWnddSGK1rWgKpM7itSvQd9FfJv5HfKfZW3u1uouounNm9WbjesbGZ nsft/Nbg3fVQ4/IVONrYanZ2w9iTY7B5OnqqV1enqcy0iEcjkezbmXk7lPkrcbrZN+33cLje4QNS QWqJECyhgRLNMGdSCKMsVD0HeQ/dD3H91tk2/mzk3lLZbTlO5ZtEt3uEs07BHZGBt7W1KROGU1V7 io8xno5GDpO0vEr7lz2wmqCvNPgdq7gjgRiDx91kd3zSzBT+fFHf+g9gC5k2TVSztbrR6vKlf2LE KftPUx2MPN2iu57jt3iekVvNQf7Z7kk/7yvSkji3Imoy1uEnuQVCY2updItyCxytXqufzYe0ZazN NMUg/wBsp/59HRmibstddxbt9kbr/wBZG6eV16F1hTJpGoJfSXtyFLc6Sfpf2nNK44dLxq0jVTVT y9fl0z/x6kikMWQiq8SwYKsmQh8dHIT9NGRiabH3Y/RTKrn/AFPtR9LIw1RMsg/onP8AvJo38qfP pD+8oI2KXSPCa8XFFP2OCU/IsD8unoEEAggggEEG4IPIII+oPtN0YAgio4dd+/de697917r3v3Xu ve/de697917r3v3Xuv/Q3+Pfuvde9+691737r3Xvfuvde9+690GNTv6ozmRrMB1zRU246/HVclDm tx1ck0Wy9uVcPFTRVOTp1aTO5ymayvj6Eu8LnTUy03BJym1pbRR3W7yGGJ1qkYoZpAeBCn4EPk70 qMor9BWbmGW/uZtv5ZgW5uI3KSzMSLaFh8SlxmWVeBiiqVOJXi83WDY1HWPHV7uq5N45BDrVcnDH FgqSS3P8N23G0mNgCkDTJP8Ac1ItzMfbDblJGDHYRi3iP8Jq5/00nxH7BpX+j0qj5fgmZZ95mN9c j/fgAiU/0IBVF+RbW/8ATPU3eu3Nn7p2duLaG+aDE1+ytyYTIbd3Disu0UGKrsJlKOShraCoLvCs UUtLKygqysnBUggEU2y53G03G0vtreRdyhkWSNkBLB1OoEUrUgj0NfPpRv22bJu2x7ns3MEEMmxX Vu8M0chCxtFIpRkJqKAqSKggjiCCAetfDFYPt/8Aladl53OdFZw/IL4kbnypye6tgJWyVG49nqfH E1fJJBBLTUWboKRViXMUqyUeRgiVK+GF1hkTLeWPZ/ezZLaDmixO0c9wR6YpytI5fOlCQxRjkxNR 4yaxMwLA8vpz7gfc45r3HeeQLo80+x11N4l1aKxae0GAXOlSEkRaKLmMNDKi6biOMiMrbZ1j88/j 925t2HcOy8pnq5BHGcpiJsXTU2cwNS45pMxjZMkJYGVrhZUMlNLa8cjjn3Bm6+z3OWzXTW19FApr 2sHJRx6qwTP2GjDzA6zT5E+8/wC1HuPs6bxytuU8ygDxYiirPAx/DNGZKrnAcao34o7DoVKT5KdV VLhJ8pksdf8AtVuJqig/4M1GKwAeyaX255ojBKW0cn+lkWv/ABrT0PYfdjkyVgsl5LF83jan/GdX Ql7f7A2TuohdvbpwuUmb6UtPXQit/wBjRStHVj/Yp7Dl/sO9bXU3+2TRJ/EVOn/ehVf59CzbOZ+X t5IXbN5t5nP4Vca/94NG/l0r2UMCrAMrAqysAQwIsQQeCCPZRwyOPR4QCCCKg9M0+MnhVpMLUrj5 v1CmljaoxcpHOmSkDxvT6/prgaMgm5DWsVKzqxAuU1r6jDD8/P7GB/LpDJZyRgtYTCKT+EjVGftW oK/ahX1IPDqNjtwCatGHytJJiM0UkkippGM1FkoorGWow2REccVfHGpBeMrHUxDmSJVKsbTWumP6 iCQSW1ePAqT5Ov4fkcqfJiagNWu5eJP9DewGC/oSFJqjgcWiegDgcSpCyLxZACCVH7SdGnXvfuvd dG9jYAmxsCbAn8AkBiBf/A+/de679+691737r3X/0d/j37r3Xvfuvde9+6910zBQWYhVUFmZiAFA FySTwAB79xwOPWiQASTQDoCXqs13PUvTYityO3OoqWpkhrM9j6iXH57tFoGKS0e3K6Ax1mC2D5VK y5KF0rMsARSPFS2qakTBLfl5A08aS78wqEYBktq8DIpw8/pGQUi/0QM/YgBMt7zvI0dpNLbcnKxD SoSkt9Q0KwsKNFaVqGmUiS4/0EpDSSUXaen2/tDBRU1LDjNu7dwlGsUEEEdPjsZjaOEWSOKKMRwQ RLfgAC5P5J9kf+Objd58Sa9lb5szMf2knoYom3bNYLHGsVttsCUAACRoo4ADAA/y/PorPYfybjon nx2yqZQELIc/k4Tpe3GvHY6QLdRbh5/r/wAc7c+5R2D21aYR3G8ycf8AQkP/AB9x/gX/AHrqG+af dxLYyW2wRAAY8aQcfmiH/C/+8efRNN19qZHM1D1eczVXk57tpatqWkSL/CGEkQU6f4Iqgf09zBtf K9vaRiKys0jT+iKV+08T+ZPUB73zxcXkrTbhuDzSDzZq0+wcF+wAdBTlO0aBVbTWRpMisNBkA1rY ggc25H1/3nj2KLXlmeorCSh86dATcOfbIBqXaiYDhXj/AKv+L6JLvzGbBXcLbz2LlZesN9wu8rZT bbLR46vdzqlXJ4eMpSslS3+cMYCSfWSOT3Ju17Zu0lqLK9g+r28j4XyR6UbjjyrkeRHWH/PuycnH eX5t5I3x+WueEJPjWxCwSkmpE1uCFo5+IoAr8ZI5OpuC+T2aptOL3lHRz18Q0LncFIJMfXqvAlmo lPko5X+raBov/YQe6XPIccR8VY3jgJ/EOHy1cP25+Z6KNo+9TumySpsvuXZxR3QOlb61Ou1m+bot WiY+dBTz8OMdKIfJfDpKp/iMccsbBlYS+OSM/UMpBV0PHBHt9fbm6li1JCXiYeQqD/kPUhx/eJ5d k0SxbrEQaFWDj9oIPRkesf5iu6tlzU1PUZyn3dgkKLJhtw1bVEyRCylaDMkvkKN1X9IczRA/7rPu POZfu9bZvCSSR2LWl8eEkS0Ff6UfwN86aW/pdTHyX98272OSKGTd4r/bRQGKd9Rp/Qly6n0qXUfw 9W19D/Kfqb5AUvh2nmoqHdVPB58jszKzQRZunjRQZaqhCt4cxjkJ5mpy2gW8ixkge8U+efa/mrkK XXutmX2tmolwgJjJ8lbzjf8AotSv4Swz1nv7W++nIHuzBo5e3RE3tF1SWkjKJlA4slDSWMfxpWn4 1QkDoddxbfx+58RV4bJfcpBUqDFV0FTLQ5PHVcZ10mTxWQgK1GPydBOBJBNGQ0bqD9LggO0upbOd LiGhYeTAFWHmrKcMrDBBwR1Ku5bdb7rZzWVzqEbDDIxV0YZV43GUdD3KwyCOgu6l31msv/efZu8Z YqvdvXm6KnZWbzFPDFTR5edMXi9w7fy1XRQ/tY+o3NtHO0NcBH/k/nlmhTS0OknW+7bbwfR7ht6l bG7hEyISTpGpo3UE5YRyo6Z7qBWNQ1egnyfv99dndNk3pw+77bdm2klACiQ+HHNFIyjCNPbyxSin YWZ0FClCNnsOdDrr3v3Xuve/de697917r//S3+Pfuvde9+691737r3RHe6e7abL/ACe6F+ItFEz4 zsnG7/3z2fXCQxJV7U2Ht+oqcfsWlkjdZXO49xT08mUtZTjaWSlbUKmQJI/LvLrwcm8z89yGk1m8 ENsPSSaQBpjX/fceoR+fiMHxoFYK5354ivPdDkH2fhWtpuaXVxfNWmqC2hd0tVI4+NKFM/l4KNEa iVwpzMlkcZtzFvV1RSkoKKOOGKGCMAn9MNLRUdNGBrlkbSkUaD62AsPYCtra4v7lYYQWmckkk/mW YngBxJPU0Xd3abXZtPOQlvGAAAPyVVUcScBQOq2++u8spWStR5F2xBLNNSbe8qFsJQqzLTVOVMbN HPn8io8g5K00BATlizZF8i8kWsSCa3Hi4o0tP7RvMJXhEnD1dsnAoMTfc33JunYwXT+AclYa/wBk n4WkpgzScfSNKacsSSNdg984XFU2MbMSxmhyOONS1XSlY62GaGsrMfPPGCwhnMctIbxkAMDa4Nj7 m3l/kW9upLoWaHx45NOlsqQVVgD5iobj5enWLnOvvHsuz29k+63Cizlh1F1IDqQ7xswBNGoUytBU GlQeiV9pd55XEQwV+MmXM4DKaxitw492bGVLLy9JOf8AO0GTg/3ZTShZFtcXHPuZeWOSLS6aSC7X wL+KmuJ/jX+kPJkPk61B+Rx1ij7ie8u8WUcF3sy/W7Lcg+DdRn9FqcUb8Ucq/jicBhxyM9FGz3dm 58k7t/EWp1JJAhYhh9foxJNx/X3Kdpyps9ooH04Y/PrHPcufudN5dmfcWiQ+SYI/M9IWr7HqsgPH l6uoqhyFqVlYVEV/9jplF/wf959mC7bBanVZRoh/hp2n/N0WGW+3IBN4nlm9H1HUP8hHSfqM3PH/ AJXRVbVUSnUJoJHE8J/5uxgiSMj+v09vieGQGC5hCk4KsAVP2VwempOVS8bPEBNbnjip/wBspz/k 6cqTsehq1Wl3LR/fwAaUyNIy0+Vpgfo2oFYqoA/htJP5J9k0mySWjtcbDd/TyE1MbVaFvyNSv2j+ XQXuOTLm3ZrjZbjwZeJjerRN8qcV+0Vp8un0Y2fIU75HZuWi3FRxjVNSRyCmzVGDzpqKGQqWI/qL X/APvycwi3kW232zNtOeD/FE3zDCtPzrTzPRYL9bGZLTmCyeyujwfLQv81ccPzrTzI6asN2bu3ZG 6sDnsLns7tnce2aqbJYquoKqrx+XxuSURwQS0jK0U8c2mRh/RlJBupI9mV5tey75t9zZ31lBdbbc JpdWVXR1PEHiCP8AAcjPUh8u7lzDsNxbb7ytv1xbblBNHJBPBKytGyktrR1OOGc5FQag062YvhP/ ADTdidmbCy2I+R+4sDsHsTYm3KrP1u46qSKhwe/NvYxP8pyGOp4kCx7xpgAtTi6ZGNXI3ko0ZS8U POT3p+7funKu7QbnyHZzXnLd5OIxEKtJayue1HY8YG/BKx7B2ymtHftH92777fLXN3K9/tnvHvNt tvNu1Whma6ekUO4QRjukjQfDdg4e2jBMx77dMtFEcb4nY7dm7aHt7vbfe38htOX5D7+pd2bU2VmI mpM1t3q/bO0sBsfr47gpAxbH7l3BicC2XqoQxamNckZIeM2hHnuSw2+XYeWNru0nG02pilmQ1SS5 kleafwz+KONn8JTTu0E8D1kr7Kxb3zBZc5+43Me1y2R5n3IXNtaSjTLBt8FvDa2XjLXsnmjhNzIo NU8VVrVTQ2dHO6zS4+oLGenRZIZXIJrKRjpScHi8sTeiUfhrNwHX2A5FBUSr8JOfkfT7DxH7PI9T TBIwd7WUnxFFQT+JfI/aODfOhwGHTj7a6V9e9+691737r3X/09/j37r3XvfuvdMmfyFTQY8jHqkm Vr5o8diY5QzRGvqgwSedV9TUtDCj1EwFiYYWtzb2ptYkll/VNIFGpvXSPIfNjRR8yOkG5XMtvbUt gDeSMEjB4a24E/0UALt/RU0z1Sj/ADFWy3xg+S/wn+W2MgyGR2hsit3B1rvyWMPLVT0WfqKvJ5mS ocDxy5Xc+Cz2cqEvYPVUo4Fx7yO9oo4OduT/AHH5DmZE3C5RLiAcACgCpTz0xvHCp/ot1gD96vcb 32Y9zPYX3ot4pZdgsJ5bK8IqWKyl3lr5NLcQz3brXBkjr6dGF7Y+VuGzGdl3rgszFV9V7Boo6/Hz UcqCDfGTzdFJBjBTSSKRoyvnP27lS0FJDLNYM1h7lL2wuoNvi2q6tCOZNxajVGbeNGDMTT+Cg1Ct GdkStBXofc9++u1XN5JzPt25q/JG1xCRGQjTePMhEWknFJdXYSKpEryUBNOqtflZ8g8V2HR1PZ/W AnlxuP8A4ftzfWMnRIcptvLyiT+D5eujp5p4qnCZqImlhq0IUVFN45ArOgOUPtdyBc8vSx8t8zlV nk1zWzjKTRiniRqSARJGe9kOdD6lqA1MAPf/AN7IOc7SfnL25DS2kBS2v42oJLWYg+DM4UsHgmFY 0lU08SLQ+lmQGtrfe+a/ObG2dka2reWWnzm9cRJ6zpCIdvZmBLA/QPmZbX9z/tVhbbbvO729vEAj Q27j7f1Yz/KNesPN8n3PmTlblm+3K4aW4S6vYjXgB/i8yinpWZ6dA9iu0cjtpquCP7fJYXJKseZ2 /kg02KykK/pM0Vw0FZEOYqiIrNE3INrgmm4bbb3/AIUjVS8j+CVcOh+R81Pmp7SOI6d5anv9mE1v Giy7ZPiWCQaopAPMr+Fx+F1oyngeIKf3DNjMjTT5zZdRPU0MamXJbfq3EmcwF/1E6QBlcWpPpqIx qUcSKDc+621xdIwt79R43k6/C/z/AKLeq/sx0bXWxbaGW4sWKW7n4H+JD/Dq4MP4Tgnzz0EFRun6 2l45/tX/AOK+1+tfXpVDsX/C89Ny7vmgkEkFQ8Ui/R0cqf8AWP8AUH+h49tSeHKpR0BX59GcGzPE weOob5dSxvOirDbIKaeU/WtpAFuf9VPT30Pz9Stj7SFLiDNs+pP4G/yN5fnjox/dNvc4uYNMn8aj /CvA/lnpV7Xg3pla6Gp2PTZbMzxHVHX7cjqZXp+RxPLDYQc/qDnT/Xj2zPuW2tG8O6aI0plZaU/L 1+VM+nQX5p27l7ZbF25jv7JNvfFJnQavsRzqJ/0oJHlno0+FyqTUa4rt2s2ZBuVJFGPgnrMVU5JK TxAv/GmpDNQYusMlgoMkfkBsRqHICvY/Bl+p5Y+qWybDU1hS1fwcGYU44NPWnWPO47PdieXcfbqw 3V9iCapWWOZYq1wYtYV5Ep56WpTBpwacs2V29WYvcPWNTj3m27kqbK/dYSejyGRxmVx1XFksZPAr SVUbR09SgkEOk3I/Sykj2psprPcBPZ82iR45kKKsoZY2VlKPqFF7iMazwHmDQ9CXlLmK8sN02y+3 q5uLXebZ45LR5UKKrRvrDUZQC4cAhnBHkeGdv/4CfLzFfMLorHbxn+1oex9qTxbU7V2/ABCKDdFP TrJFl6SkJ8sGF3RSAVdMCLRP5qe7NTsx5m+9PtlP7Yc43G1wlpOX7kGazlOdUJPwM3AvCexvUaXo A4HX0pfdv96rX3u9ubHfpjGnM9rpgv4loFE4WomQf75uF/USlQreJEGYxEkyPatZLt7bi78pQxqN g1Ue4apFJUVW21Ipt3Uc3NmjO35ZqiMG6rVU0Lkege482ONbq7O2P8F0vhj5ScYiP+bgCn+izDz6 lXm+Z9u2xeYYQfF25xMw/ih+G4U/LwSziuBIiN+HoSo5I5o0lidZI5FDo6EMrKwuCCOCCPZOQVJU ihHQoR1kVXRgUIqD1z966t1737r3X//U3+Pfuvde9+690nIwa/ck8rKTT4CkSlguPS2TyiJU1jjn 9dLjlgVT/Spce1Z/Ss1UHvlap/0q4H7W1f7yOixQbjdZHI/StkCj/mpJRmP2qmgA/wBNh0Rr+Zll djn4x57ZO76OnyFdv/KYzE7UjdddZjM5jaiPLxbjx6i0pqcR9sEAUjyNUCJrpIymZPu/7Nuu5c/2 19t8rR29lC8kzDgUYaBG3lRiamvAIWFCARi999HdOV4vZPd+XeYoUkuN2mjhtQcvHMhEgnQDJaPS FoCNXiCM1VyDrOz7q35jtmS9M1tfAuO2xncsVSlmSVo8mdFFPFLXQySLV09Aadkp1v8AsrJIo/VY Z+bJHtFjuzb7dWrm6khTSSD8GWFFNKa9QavnRa8B1wU3n3I5l2PYbz2r5gvym17fdzEeFR28XCFD IrUdE0nw80QNIoIDUCa2Tid67SzZzFHNgs1jclR1OG3TtXIy1sWP3TtrIhUymErZhTusZlRRJBNp 1U1THHMhDIPYl3zmDZ98tBaPBcQzxuJIZlCloZV+CRRq8uDLWjoWU4PQK5K94Nr5K3n6mTbp5trm jaG6hbSY7i3koJInXUDkUZGHckipIvco6CHvnb6ddbep8ZRVklZt+u33lsttasqWjFc2Kr9uYXy0 GSjQkJlcRPSCCoKjxysgljJRxYy5Z3l95vHuriMJerZokoFdOtZJO5a/gcHUvmK6TkHqfYjydvXL iyck72l9sv7weRK9s8SyRRfpXERo8ciaNJNNEmnXGzKRQl2S3IRq/c/259jNpMfLpVZbLXT2dJ/G 5zP12ShXa1PmMjlke1PHgaOtyFdrPGlYaCKeQhr2IIIYcEEe0k88US6p3VV9WIA/n0dXW3bbY2ck m9XEEFiR3NM6RpT5s5Ufz6Eyv673ZlKT7/d9Jgupso+grVb53Bhdq0ObZ2ADfwCprG3DSVr3uTFR tG5/APtAd7sJKrbu8s3pEhcH/bUCj7S1OgPa84cv2Nx9Ly9cXXMFiK9tjbzXTw0zTx1QW7oPINMG HqR0ichjesNp1j0G69/7l3TlobNJhet9n1ENK4P6dO6d5vi4ZIH/ABLBj50I5BPtia83MGn0aQD1 mcV/3lK/8eHQq26fn7maBZ+WuTLSzsmwJr+6DuPttbISsCP4XuIz606k0vZ2y8FEKzA9XbXw9NG7 JDney81XdgZ6qmjsSmPwEQw+3RUL9WLUMkUN/UTwCmCXFypafc53j9IVEan5BzVj9ur7fTpVN7Zc 17i/0/MPuBctKRVoLCOOwiVT5ySDx7vT6DxVZ/IDJDTmfkhvLMkQ1G6sq+NQGODAYcU21tswRlSm kYnCwUkNQQp+roLn8Ace6rtNs2rTaRxE/iJMsn+9tw+dOjnZPaPkjlmVbyy2CO43UZNxODPKSfPx JzLIPlQin29Z5d24ur2/STV001BPW1BkpmDLKqGRdLGeIBXceJAwYjgOCPqD7MIbS5sIxPE6yOT8 PA0xwPkaf4ejS4ji3TcprBonSGJRVhkVHAf6WppQeanhnrrEbnzW2aiLJ4jIy0308dfjprwSof8A dc6DVG8bflJFKn/H26ZrLcka2uYgT5o4yPmPP8xnoPb/AMl297bvDuFnHcWh9RUfaDxU/MEH59WS /B352dl9E9r0eV2JisPX7h322E2ZmcFXRmPb2/kqsvTw4XHZDTUUr4bMxZKr0UdfHIRTtO6svikk jeHPdf2r2Tm3lyS33G7kWytNc6MDWS3IQl2TB1oVFXjI7tIIOpVINPZDmn3Q9g+cRuPtWy39nfmO Cbbbk1S4BkGhUeq6JFYkRyalZCzA61Z0a2T5L/znd0S0We602v8AH3+765Ham5dldl0PYmbrKbcu D3RkaHJYDN4nCQ4mCOGnj2/UuR5q2ITTyKUempytzjNyj93O0je23q85rE2meOa3a3QGN4lKyI7l ia+IPJDRRQh3r1lr7gf3g1/uSX/Ke1e2L2TPaTWt/HfSMLiG5ZXhmiiEYXSIGxqlQO5BDQxEZu7+ MXenXffPVWz93dfZ+DLUuS2ft3PVlAzxpmMJLk3yuIrKHOUKSStQZCDc22cpA63KF6djGzJpY408 5ctbtyxve4WG62pR0uJEDZ0vp0sGQ0FVMckbDz7hUA1HXRf2q595b9wOUtm3jl3cVmhls4ZWWo8S IuZI3SVQTpcTwTqRUiqEqStCTF+wn1JfXvfuvdf/1d/j37r3XvfuvdUwbk+U/wDMO7j3hvna/wAQ vjdtzDdf7e35vTbkXenaNTHT4zd64Dc+Uwcea2lRZfJ4GjqMWaahjRZYYMwJTETdP0DIWy5K9qNg sNtvefebppN0ltoZPo7cEtFrjVykpRXYNUk0JipXz49YQb57q/eU5w3bfNp9lvbS1i2KDcLmL96X xAScRTSRrLAsskSFNKqKqlzXSfhPaKq/mDvb5kUvYo2/8ke0dvbj3Z1gcRJjqHZdNiaXB4fJ7roK LcDUdAaDbWAp6nJ0WMipZ6mSVZPDqhVXJYe8q/aLlzk5+XP3nyLYtabVuYkDmYu0siQM0WpqvIQj OXVApGrvJUAdc1/vL7/94W453Ox+5/Oltdb7sTwmFbVY1himuo0uNKeHbwq0scQieVnDaKxhWJI6 K5gIgQrG5Z2MrszFmd5GLu7sSS7u5JYkkk8+xtcTSzyvLPIWk4En5YA+QAwB5dc6t7nmlmmeaQtM SakmpJ86n16FfGxcL/gB/rc+0HUeXr5brLunbez9xYGop98Y7GZDAUQOUqTlS0dPQikR3at+6jki mpBDDq1OrrdSQbjj2/bXd5Zza7GR0nPaNPnXypwPSvk685jh5o2mz5X3R7Td7yeO2V14frOqDWul tSgkMRpYilQKjolGT3n8T9i7myGLz3S2UpMziqkwVEVfBR52jW1pIaqmpa/dE1HPTVULLJDIIyJI 2BH19iUy8x3UCOu71iYVx2n7CQoII888esyLv2Z+81eQtaw+59g0VSKpK8DHy+NLRXp/tusm4PkH 8ZNxUjY2XI9zbSxLR+NsTsOWTZuJCadJV6Pa2VpUmuPrrD39oUj3O3bWRbySV4yDxG/awPRVtH3c vvEbRcC+t7Hlbcr4GomvWW8lr8nu4iR/tadATUYz+X7WySzzbl7loqyUs0lXW02Rys+om5aR6rDZ RZTf8sG9qn3XfyAC8IT0HaP5UP8APqV7XbPvp7XGkMXKHKtxEvAK8Kj8lFxEB+Q6Urbd+GkVDSY3 Md19jVFA8QqcZi907XqppsXA91QxrR7LpaujpqiM3SKU2ZbOoAsfayPfd3t1RJtttZPMamJYfmX1 Cvz6IJbj73E9xcXVj7U7Wk4bTI9ndRokpHEEfWtG7KcFkFQaqxJqOkbVfHD4w7khkzmL+VObWhWR aWNJtjNURY1C5Wmofs6eioKikgjuFXVGoa+okkkl79+73KPF/dSMgNO2QY9BSpp+zoyi9z/vCbFI m17j93GM3RXUSt4QZDSrPrZ5FdjxNGNOGAKCDVfE7pHCTUtTV/Lba0EEjOaanz+1Wx0dVKkeuOOV m3BCzRIxUyKApK+m6k39ufv3coSpuNkYD/TjP8v29Xi97fdzco54IPu2bq0qgamguGkKgmhIH0xA JFQpqQDmhpTrPS/FHa2ZoZpcP8rOq82Jcn9ya1aMxoZRTmKenYRbglCuA6EKOFUAW+ntxeZLt0Jb ZJzVuINRw/0vSW497uattuoo9x+7zzJbFYNOg6iaaqq2bYVHxZ8ya149O1F8W5NvOrv8iuqzTyMA 8LMVjqE41Dw1GYVGYr9COf8AH2xccwJIoE2zzBxwNaEH5GnV4PffeZyfp/ZLmWnmPDZh+dID0r26 42Ng4Iwe4Nsyy07Ry002Lqscr01RA6y089II8tI0csEyhkNiQw9pId4m1F/3c7seOokggihBFMgj j1s+5nPG6Oo2/wBoN0goQV1rMpUg1Br9OtCDniOl9vPK1m65qjduQyD5ur3VLU7iqM86sP49U5Or qKitzCMQBIK6v8rFluuvUB9PZBaW8NlGthbxiOGACMIPwBQAqfLStB9lOo6v5d+bmLdL3mW0mh3q 7ne4lWUEMWuGMpbPxBi9a+f216uY/kQ9i9e7Z7F7g62ysWYoux+yaPC121cjI1Q+2s1g9j0eYyGX 27CqAU9NubHHMSV416jPRGTTo8LeTGT7zm0brd7ZsW7wGNtotGcSKKeIjzFFVz5mNtITHB6Vrqx1 F/u8+aOXbHdubOW7pZk5l3JI2hck+DLHbLK8kQHATIHMma6o9dNOnv2fPeGXXVrr3v3Xuv/W3+Pf uvdYKp2jpal0bQyQTOr8HSyxsQ1mIX0kX5492QAugIxUdNzErFKwNCFP+Dpj2ft6i2ntPbW2MaCK Hb+CxWHpS1tbw4+ihpVkkIuGll8epz+WJPtTf3Ul9fXl5N/ayys5+1iT+weXSHZtug2jaNs2u2H6 Fvbxxr9iKFqfmaVPzPWlx8+99ZPefyz+QTVGSWgxGF7R3XgY5aiR44UTAVi7eMhjT92pqZIcPGgU AnRGq8Ae+tHs/DYbF7YciW0NuZtzl2yCUogBb9VfFyeCLWQmp8yT59fO995rmO83v3790mPiS+Fv d1DHGnE+A/gVPkKrCo1NwVVHl0Wza3cu1cVJHisi2YehoqdIm3JNSxGnYxluaqmifz08QSwVvW7A crfknO6cu3rvJdqIVmlcnwVJJFf4TSjZqSMAeR6xn3T2p5n3pJ9x22G38d2LGHWV0g+kj0QsTWoq o/hJ8hWh+R/StFA0sm+6GQxrdqenosrJVtb8JTtQoWP+xt/j7IW2Hd1IDWTD5kin7QT0A4vYr3T3 W48C25WYGtNTzW6J9uoy8PsB6bfkHW7z3105HluoKmh3PtTKUrVu4kwjPU5vMYSALL4cRpbxzU9P PEwrqUAVZ06bWEinW3eBa3pF6pSdcLXgCfM/5Dw/l0J/YG25O5J92ZNu91baaw5otpPDtDPpW2hu GqtZieDupH00xYwd2okEo4pty266jt+nG3KsJD2Jtunel2rJVSLDLuHb1GCTtTI1EpVTlcNGrSUc jkaotUZNlB9yPZ26CMxwsKnPyYnjT7eukO6Rz8qbkm93kbPyzMQtwACzW0nBJwBUtE+FkAGGKsAa 06DzP9S9i4Z6L73HPXCukEMX8CnfJCKoYahBUrDGrwsQDZyPEbH1e1T2U66ax1r6Z6W7V7i8pbmt z9LuHg+CKnxh4VV/iWpoR8gdX9HpR0PW+68CqyQYmonzQs38RyFRTUmGwrfX/IhX1EMeUyUZ/wB3 spp4W/zYkYBw8LCSMV+nBk9SFoPsrxPz4Dyr0UXPPmzbmWR930bZ/vuPW003+n8MExRn+AESOPjK CqmMdlZRJJJ8vvTCUc8sjSTtJuGpytZJKxLO8i48VTSSsfqS1yfbLbbCxJmMOo8a0J/kD0rXncaE i2zZr+SJRRQIvCQAcAPEKAD0x0vOv6egwefFRS7yymRqPtKiGTx0tbj8VGJSkaPU1VZUqXJkISJS lmkcW59v2tht8UupUUtTyWg/M/4Pn0GebN85g3LaDDNtohg8RSKyiSU6akhUVTTGWIOFB8uhF3nk JZqGCiqKjH1ddNOsuKos5Uyx0s9VGrca4yGVjG5C6iI2YgH2oubCxdAslrEWrgMME/l0EuWNy3WC 6luYLy7jtVSkrwULqpp/FXzAJoCwAJHQRQdi71xiZfC1NFSY2sho62fHwU1ItDHRywwGR1+2RXWp DRI8iSavUygXIPBeLeBBJEbJFahoACKfl59SPJt1lett25Q73cTWzSIsjM/iFwWoDqNNNCQpWmAe AI6B2LJ7qrJ5Jp8zWvBEPJW11TKziKP8lpba3lf6KgN2P+8E88FlDRvpleZjRRxJP5+XqeAHUq28 xlTwo3EcAGdICgD7BT8vPoxvU9FJu/HZbdWcmm2l1ztSRU3DvTIoPtppBbw4bCJZTl915GwVKaEP oZgz24DE9xDNbSxQxsr3EnBB5etfRB6mnUZe4POljsMtnsGz2h3Dnq+FLWyQ1Yr53Fyw/sLaP4nk amqmlPMjaH/lu/C3oP5/fBCPdUMWd6s3xtfuHsHZuI3jiqls9Vtg8TT7fqsVjNxYLI1SY2upjj8s k7R070ssdXLI6zWkkD4ne7XufzP7Y+5jWSeFebPNYQSGFxoGpjIGZJFBYNqUirBgVABXAInX2w+5 3yV7ve0cG48zbxdQe5q7jOZ9yiJdWYpCfA+mdgn0sSlVhRDE6kFtYDupur+InwQ60+H2wqXb+Oyt Rv3dkm/4d9V2+83jafF1aZ2fC1OzKeLBY6kqKsYagg25l6qlEZqKh5fvJy7kOqpjlz77m7xz/usl 3NALWx+lMKwoxYaA4lJdiBrYyIrV0qBoWgwScxvZX7vfK/sjy1b7VaXjbhu37wW5a6lQRt4pja2A iQM/hoIZJE0l3LeK9WoQqnz9xh1kP1737r3X/9ff49+691Er0WShrUYEq9JUowXhirQuCFtzcg8e 3IiRLGRx1D/D0zcgNb3CkYKN/gPRN+6+xOyt+75x/wAYvj3lV2vuuq25i91dz9yGliyEfSHXWalq aTDUuAopw1HkO29/mgqlw1PNePH0lPNXzIVEAcfcu7VtG17dLzjzVB41iszR2lrXT9ZOgBYuRlbW HUvisMuzLEprqpDHPHMPM3MO9Qe13t3efSbs9qk+47jpD/uyzlLLGIlPa1/daHFujYiRGnYU0HrT A+VmCh2B8g+9dly5HOZHH7J7Y35tynrtwZKTK7jzC47cuRpqWqy2VnVZMhmclBEJ6upZQZJHZ7XY D31Y9vbyO85C5Pv7S2hjuLzbbeVhGulFLRKWovkik6USuAAowOuIXPfKEXLvuf7h7QZp5YLPebyI STOZJ5QlxIqtLIRV5HA1SORkktTIHRSMnQbq3CpNJjzS45NRjeqdMbjYF/46GSpZGlP5L2dj/X2M UtilWAJc8WPE/wCx8hgdIk3rZ7IpFcXY1DhFGC7fZRa5+bGvQay4fZVBl8dHurfuJqHbI0iS4jC0 9RkYJSahB9vX5MaKelpZD6ZGtcKT7owjBAeUeWBn+fQoh3Dma8sLttg5TnVRC5EszLGRRT3JFlmY cVFcmnQyr8wD0bvKmotp42DdtC8UUO5sFS5daDB0sUNQFjjokpqeppoNx00CtolQKI1IjlDA2Um3 zabHcY/DZQLlRhx+H5H+IfLy8iOo9m+703uty7Lc8x3z2F4CTbTtDrnYlfx6mVjbMxFUNdRq8ZU5 Y3EWxeofkph4u3ejn27idyeWd92YqXCYyhzM2UqqZ2+wz7Rr91g82sx1LPGzUlchJDEEv7C22bvf ct3SWe5RarMnBpXHqp8x6jiOoJ/rpz97O3re2nvCL242ZUVbK6WaWSOOJGFGiBOm6taYMbAT2xoA MeGSU9rQ5mgp9wbRphVUW68VJTyZbHJJU0WUpKCGbXUy09liapFkXUI2P7T6uQReTFvLe+tC+3zq 9QD2nNPP/iusjeSoLM3Gz8wXfhS8vXKt4E3bJBKzCi92QOJpqAIcaSAwIBYI8VPVEPUSTVDHnVPL JMxv+dUrOTf2i01yxJPU0PfxQDTCioo8lAX/AAAdPdJtuSeSOGCHVJIQEUAAfS7MzGyqirckngAE n24sRJAC9FlxvSRI8kslEHH/AFeZPkPM46dqvExJAuOpBqpUdZamcKR9/VqColN+ftoAxWFT+CXP qbi7LQaF+HzPqf8AN6dILfcHaU3lxiciir/vtfT/AEzcXP2KMDLJUYRn5fU9l03csxAH0UFieP6D 22UJ4r0Zw7mFwhAzXGOlLisfJLJjKXccM1TTGeKDEmKJ59w65WEa0tBEiyVFVSThtLI6kWJ034Ht O14GPhRqHK8WJoqf6ZvT5f4Oq3FvFbwXe4xXItkKFpFJARwMliCQqMKVElQMZ6FXMdDbO60p4Nz9 5V1didvAR1W1+nNvyq3YG65mjDody1igQ7TxMhsHqZytU8Z0xqjfUOGV55pY9oPjPWjXDD9NP6Kf xU8guPM16j2P3n5l59duW/aexhe5QlbjdJgfoLUVoWhU917cAcEWsStliy8Cx9t9mbi7JqMdSSUe P2rsvbKPT7M6+23G1JtnbFIQRqhhGlsjl50/4EV04aeZif0qdPtda2EdmHYEvcP8bt8TH/IPQDHU v+33JOzcmRXlwl1Nf8zXpDXl/cnXc3L+jN/ocKn+zhSiIKfERXrdl/4TSUtXD/L13PU1QIXIfJbs uelJB9cFPtTrjHu4v+PuqORf9dT753fevkV/c60UcU2mAH7TJOf8BHXUX7tcXh+3twwFFfcZWH/O KAf4QetgPI2MMA0a71+OsvIsVrqd9fH/ABzC6v8AYe8aovibNO1v+OnqeLr+zjGmv6if8fU1/Lj1 P9tdKeve/de6/9Df49+6910QGBB+hBB/1iLe/cM9aIqCDw6L78etpHCY3s3dWRXy7p7E7m7Jze4q 6VLVM0G2Nw1PWu0KIuw8go8VsjZOOhhjvoX1Mou7Eijmm++pm2eyixZWm3wJGBwBkQXEp+1pppCT x4A8B0APb7aPoLbmTdLgV3Xcd4u5ZnIyRDKbOBfXTHbW0SqOAyR8Rrp1fzdMXN1F85+7qGlxdMh3 bX4XsjHZGqjaUTQ7y29jKmumpo2sv7ecpKuIsDYvG3H199Pvu6b9HuvtBypIoBubaN7ZjxIMMrhB 8v0yh+wjrj996nkOay9/OdlubiQbZeSx3caL2hvHhjaQk+f6wkH5HPVLO9t5ZfKmT+I5OqqluSIX lZadf+CU0eiAf8k+5hmmdviboHcs8ubfYBPo7GNG9QO4/axq38+gXpq6+UevYB4cJA+WdTyj1MDp Hi6Y/j/KMrLCCPygb+ntIh1OXPwqK/5v506lKe08Lbls1NJ7thED5hWBMrf7WIOa/wAVPXrDg8Cs kS5TLyywUUsjsrIFNfl59ZMyUCOCukyE+WpceKIn+29kO0jqNch7P5n7P8p4de3TdjG5sduRXulA rX+ziWmDIR8vhjHc39Fe4Dh132Dvbr3ceO3JsTKS7ZqMcDFBQUeqbF1dHIytPRZqimJjzcVXpHma fU5IBQxlU01urO33GA291CDB5DzB9QeIPz8/sx1FvOHKXLPN+zXmy81WK30M2WkfEquK6XhcZgKV OgR0UDDBwW1Wm7a3j1P8ucRQYrdNJFsXuLE03+4qtpHQVbSxIS0u3a6coc5iXNzLjak/cRKToJF5 CCJrLduVJxe2TmSwrx9Pk48v9MMH5cOsH9y2f3A+7te3txs0h3n2vuXrNDJXQATQeMq1+mnAwl1E PDcgax/ofRWO0egNzbEyzCvx8QWod3iyFAjfwTLKG5rKCV1AopzcGalk0vGxuLggkd7RvFlvkeu3 IS7HxIf8K+o6njk33O2Lmra/qtov3kt0A1RyU+ptyeEc6CutfKOdKxuBSoaqgNkwwpY3pYkvK48d XMByQDc00R/EQI9Z/wB2Ef6kcnXh6Rp8/M/5OhM25eO6Tu36Yyg/5+Pz9B+EfPhNh2hPIiyzIlJA xAWaounkYmwWCK3lndjwAoNz7SySxKSkdXlHkvl9p4D8+lUd1Iy+JJIEh9WwKf4T0LmF6Gro8fFu PdVZj+uNrsA67m3rEy5SuS2rTtjZ8Z/imRqHH6GdUU/W/sOXO5rNK1rArXNz/vqE9o/5qS/CB6gd AbcvePZrK7k2Xk+wm33mUY8O3oYoz6zTmsMSjzJLsPQdQ8h2PtfrlKim6P29PDnpY3grO3d6wU2S 3rUB1KSnbOMdJMZtOnkH6WVHqNP1sefdl2S6vAp3mUCAcIIqiMf6duLn+XSCLlTmLnmaO99198Eu 36gy7VaMyWYpkfUy1Et0w8wSI68KjHRWczVZavqKvK5OrqsxX1sjfxmbLTzV02V1sWjnrJ6h3mkn QkoJL6lGkDjj2epGsMaxxRgRKKaQKCnlgdTjtsO32sNvYWNvHbWkQ/REShFioKFUVQFCnB00oc16 D+t2lFkkmnxkyxKLD7SqDeSGU3Ji86gq0Vv0uRyPr7baAOCyHHoehdbcwSWTRx3sZLfxpShHrp4g +o/Z19Az+SZ1N/oi/ltfHzHTQyxV+9aXdnZ1f54TBJN/frd2ZyuIqPGwDCObbf2LJfnQR75SfeI3 dN393OajE+qG2aO3H2wxIrj8pdfXW37v9hcWPtPytJdIFnuke4oM9ssjNFnzrD4ZJ/Z1aZVupqcd TksGlqJJrKLgpTU8jMWP4USun+xI9wxGDolbyAp+0j/JXqXJ2BltYq5Lk/kqn/KR04e2ulXXvfuv df/R3+Pfuvde9+6901UCLTVWSo1iihRqj+IQ+Ow8q14L1MjoOfK1ekrMfzqB+p9vykukMhYk00n/ AGvD/jNP2dI7cCKa6hCADVrFPPX8R+3WGJ+0dawv/CjroSq/hXSnyiw1E0lPjzWdNb8qIogft4ay Ws3RsGtqGTkQ/eHL0zSPwJJoEvdgPebP3Pub0R+ZuRrmWhel5ACeJAEU4Hzp4TADyDHy6wU++jyG 10/KnP8AawVMYNlcEDIFWltyaeQJnBJ8ygrkdafO4q95HZEDSO7hERAWeSR2CoiKOWdmNgByT7zd lYnHr1iPsVmigSPQRqKkngAMkn5Dieptftr+51DQUme8FZmMs38ZqcNBJIY4/CGp8bT5apTQftaQ yTO0UR1TzPbUqR6i+8QtkVJMyNkj/BX5fIcT9nSW13z+sd1eXW1a49ugHgrMwFTXukaJTXueiAMw pGgrQs+kc6RKjITipq380rKiA6USOONBaOGCKMLHBTxL6UjQBVH0HuqhnJLH/V6D5dM3Lw2kXgwL pjBJ8ySTxLE1LMeJYkk+Z6EnEYy+n08m3tUi17iOgXuF7TVnoVMBh6pqmnNAs4q4pEmgkpTJHUQS xENHPFNEVkgeJhcOpBU839qNCaSZaaKZrSlPnXHQH3G7EySxSIHjcFSpGoMDgqVIIYEYIIIPVnvR 29cx2JiMvsPsiLGbi/h+LgqFrauWM5WvpmmFLpyFLEtpKmk1KVrFaOfkawWOr3GfMm3W+zzW267M 8sYZyDQEIGpXtJ8j/Caj09OsLvdXlCH243Ha+ceT7mTb7qe4ZPBjykR06jQ1IVH4GBwyHIFFGnp5 yPxi2bVyLNiMrkMVUtKuqWWjx2R0wmQFljUxUmmcR+lZH1kHkg+00XOl+tRdW6ypTgGZamnnxx6g U6T2f3jOZbeNxe8vWErhO1k8SIhgPiIJkUgnJAC0/CR0AlVvDAbNyFZjevNsUtLnqCoqaCfeO73p 9xbnFTSzPTzvi6VlbDYe0sZ0+JHNh7HtvsVxuUMMu63+q1dQwhhrHHQioDH43xxqR1IP7l37m2CD ceeOYJp9umRXFpa6oLbSwDKJWr40uCKhio8ugX3GM1uKvmyu4MlX5rJTX8lbkamWqnsedEbSMRDE PwiBUH4HsQwWNvZxLBawLFCPJQAP5cftOepC2Y7bs9rHYbRZRW1mvBI1CL9ppxP9Jqn1PQeZDC2D WT+vFve2SnEdC+z3KtKt0g6/FqHYMtlIKuPyUI/of8eR/Qj2naOh/o9Cy0viQKHPEfb08dQdQ7l7 m7k6z6V2TSmfP9o702/tCll0l/AuYro6ety85S4hodv4wz1kzfRYYHYmw9hzmjfrPlLl/eeY74/4 nZ2zzN/S0qSqD5u1EUebMB1JXJGwXnPXMWycu2hP1t3cpElBUJqYAuw81UVZz5KCfLr6WuydoYXr /Zm0th7bpxR7e2VtnBbTwVKLf5Nh9u4ulxGNg9IAvFR0aA8c298Wtz3C53bctw3W9fVeXM7yufV5 GLsfzJPXc3atttdn2zbtosU02VrBHDGPRI0CKPyUDp2jLTZOoYraKjp46eNyBdp6kioqQD9dKRJB /sSf6e05osKivcxr+QwP516dWsl3K1OyNQoPzbub+QTpx9s9Kuve/de6/9Lf49+691737r3TTkV+ 3lpcokbO1IWgqNJIP8Pq3iFS5UA6xTSRJN/UKjW5Ni/EdSvCThsj/TCtP21I+0jpHdDw3iu1WpTD f6RiNR/2pAb7AacegW+Uvx72l8qvj92j0HvS0WH7G2vV4mmyiwrPPt7cEDR5Ha+56ONiNVXtzcNH TViLcCQw6CdLH2IuSuar/knmnZeaNuzcWkwYrWgdD2yRn5SRlkPpWvEdEXOvKu3878r7zyxuQH09 3CVDUrokBDRyAescgVwPOlDgnr5mHcfV27/jp21vvrHtHEHHdidU7nq8FuDHSB2oabK0c2vDzY2W RVGVj3DTeKvo51BgGOkE41sVC9f+Xd92zmTZtt5j2mcS7fcwrLGfSv4SPJ1YFXX8DKwORjkrzDy3 vGybjufKG4wtb3KSvDIPxMq4eQHFINJGhsGYslKRtVgjgqK3LVsuRyVTLW1tU/knqZ3Lu7n6AE30 RovCqLKq2A49moLOxd2Jc9F88VrYW0dlZQrHaxiiqooAP8pPEniTk9DBtra+Wr4Y6mkxtTNTM2la kIEp7g6TeeQpEAG+pva/txZoEYo8qhhk1x0CN0uGUH1PkMk/kKn+XRlOv+ra7OP5EQVlNTc1tVDO lJhKEKCWWu3FUiPHqyn9SQtK49tXG6W9uVEkwjrwFC0jf6SMZ+wtQdRBzdzjsnLi6dwuC1+/wQJ3 SsT6RrVz+wD+l0PdDjutNtJ4KzJ1e7apbasFs5mxWA8g+iZLc9QhyGSRTwftwB7bRN43BtVrai2h /wB+XHfIfmsQ7V+Wo9RHf8ye4G+Bl22wh2fbz/os413BHqkCnSp/5qselZFv3cJpxj9r02O2JiQw YUW1KZaSqmsbq1dmZRJlK2TjkmRQfyLezS25XsC3jbi8l5cU+KY1Uf6VBRFH5H7egXJyps/jG832 ebddwp8d02tR66IRSJB6dpp69CttDtHfFFVwNmal9wY4qsU0M8FLDWKL/wDAinq4IYWaoQfiTUrj g2PIK925K2Ke3kFkn093xDAsV+xlJPafUUI+fDoBcwci8sXVvIm2W4tL2tVKlmQ/0WRmPaf6NCPm MdSN99Nbf3pG269kzDF5GoDVFVjPD4qSqqbl3JhZkkoKwv8ArRToc8ra/JFtHMd3slwNp36piXCv xKjyyPiT58R59L+WPcneOX2i5b52t2ZFAWO4aurRwAc0pIlMLLTUvB9QFVK7klpMdXT4nKU9bRZW ml+3kggqJ5onnOkLHE5mVlZyw9LhdJ4J9ydHcW80aujVVhUEGoNfQ9TDbLdzwJeWskb2bDUCyqCF 9SKEEeYKkhhlcdJ3IYStcsSZKOPn9uSSOqqWH+1HQYof9gzn35ozQ+Q/b0a2m52qgAASP6gFV/w1 P5gdB1lcS0IezBz+WkU6z/wZgxv/ALb2ldKGnQxsNwWTTUUHyOP2U62Kf5CPwsq3zu4PmlvvEeGg oKXL7D6Pjq4SHrK2qL0G/N80gdVYU1HTq+Fo5Vusjy1448ak4Jfe59yYkhtPbLapwZiyT3pU/CB3 QQH5k0mcHgBCfxHrp39yf2unb6z3V3e3Ig0vBYhh8THtnnHyUVgVgaEtMCAUHW0NXVkOPpZquoJE cQXhRd5JJHWKCCJfq81RM6oijlnYAfX3ghFG0rrGgyf+LJPyAyfl10PuJ47aF55D2r+0kmgA9SxI AHmSB1xoKZqWmVJG1zyPLUVMn+rqKiRpZbf7QjNpQfhFA/Hvcr63JHwjA+wYH+z8+q20RhiCsayE lmP9JjU/kOA+QA6m+2+lHXvfuvdf/9Pf49+691737r3XRAYFWAZWBDKQCCCLEEHggj37hkcetEAg gjHQPdldw9cfH3Z1duztvdNNtDZuLqcbjqDN5CKvyEuTrMxUmkxO3cVjcVS1+Zze4Zan9mCjpYJ6 qoQKyqxEmk+2nYt15nvo7LZLMz37hmZAQoUKKs7MxVESmSzEKpqCRioT37mnYeRtqm3DmfcRa7TE VVJGDOXLmiRIiK0kkoOAiKzsoDAHuprX/wA3z417Z+f1NtjvH4y9I/JhO+tqUsGEyOTyfxk7J25t DtTYflQxirr904XBy0+7Nqx6nxldJTsaiiaSjc2+2MOWHsfzPde3L3HLXOXM+0jlWVzIFXcIJJLe alDRYnYGOTAdNQCuA/8AHqxL95brbef4U5i5L5A5nn5mjRY9f7ou4oriEHAMk0aEGPUWVghLLVKE hNOsPsnaLzbi/gVdn8dQT071tPVJ99T5LcMeQoHaKegGEnp6Wlx1RTyROJVkilkhMbKfV9M05buz htRc2m3a1IBDMO0g8G1AkEGopSta8eufXOfNu9bbZXU8u2XwuUcK0bxPbxIK0Ot6mRiDQUBQEngO jJ023IdqUcdY7Tb0qzMIaCDO5CixVDTyMrSCSs8tVCKtABZIIdINuRbn2XRXA3O4IlfwEAqdCs5p wooAOn5sfy6h6fn7dt8QbbbuNrgCEyywo88z5oRGQh8MZFXYMR5NXqe0vYmf8MORh+5x8JBpcTj0 xTYajUfpSkx9FLJAgUcAkM3+J9iaz/q/ad8c2icjLsXDn7WYD/N0HYLnlTYhM1g0a3T5eWZWaZz5 l5ZU1H7AQvy6WmJwuXiC/cbfkX6cnFzp/vMIQez2C82tiNG7p/zlX/KeiDcOY9vkroubVv8AbKP8 BHQm4ajgEtPDU44RyzOEihjjyBqJWJA0xU8Zmmkb/gqm3tbPcxxxFor8MAPVD/MdBC4uzfyiG0tY 5HYgYYgCvqdVB0ffp/oTP7ljp56LacVCkgQnJ7kqZJGAP5pMBjllqXt+BPU0p/qPcHc38/Q2LSRt uBNPwoAP2uxA/YrdZR+1fsK+7Rw3tztWuZ6Eu7FgK/woFqfzZfz6NxD8Q2p6VqzI5TP1lY0Dohij pMXiqTWB66fD0NOiStGRwamWpcD6ML39xFP7nC5cQiOERg1ySzH/AG5OK/0Qo+XU7c1fdK5Z5s2K Tbd8s5tdCY5UVUeB6YeOi+X4lcsrjDDzBFu4+r22llpsPurFUU/3SzSY7KikieDJwKQjyEspkWeP UBKpPkQkckFSZS5U5rWaGNo5SbSvctcoT5j5eeMHjg1HXOrmTkvnT2A5nPLHMjtNskpLWtzHXS8a mmpQSSNNQJrdqmNjVKqQXJbuTaVbjpKiox8E+SxxZnGN+7pf4hSoByKOaQk1UYtcRSHWPorH6e5b s+bNtcRW5vhq4VZHH/Gjj/eqfb07ZczcvbpOTKr21yxwwWkTH+koB0E/xKKeq9GG+Dfwe3F82u1Y sRRwZDC9S7SraOp7X3swaOTF0RYTJtPEa4Y4m3luCJCkMZDijgLVMgKrGksee9Pu5tntXy49y0yS 8y3Kstpb0yzcDLIK1EMRNWONbUjU1JK5h/dv9ht+95Oa4rQ20kHJ9myve3daqErUQwsBoeeahC8R GuqRx2hW3Xtq7X2Z1XsjBbR2xjsTs/Yux8DRYXDY6BoqHE4PBYilSnpojLM6pHFDBEC8sjFna7ux YknkruO4bnv+63m57hPJc7rdzM7sas7yOak0HqTgAUAwBQAdd1ds23Z+V9lstq26CK02SygWONQQ qRxxgACpPAAZZjUmpYkknrjgM9tzsGix+5Nt5ah3DthKieXFZfGTJWYfMVdLLLSGvxtdFqpcnj6S RHEM8LSQSy+tGOhW90ura72uSW0u4GivCAGVhR0BodLDirHFVNCBgjJHTdhf7dzDFb7ltt2lxtas THIh1RyMpK60YdroprpZSVZsqTpB6WPtB0dde9+691737r3X/9Tf49+691737r3XvfuvdMWf23hN zQUMGbxePyRxOWx+4MNJXUVNWviNwYib7jFZvHfdRSilyeOnu0UqWdQWF7MQVNtd3Fm0jW8zJrRk ahI1IwoyNTirDiDj9nSK+26z3KOFLy3SQxSrLGWUMY5UNUkSoNHU8CM8RwJ6l0NbJKzUtbGlNkIg xeJX1RVMKsFFbRknW9M+oXB9UTHS34ZqSRhQHjNYj5+YPofn/hGR6C8E7OTDOoW5Hl5MP4l8yp8/ NTg+ROtb87v5YtV8zPkh8pN9/GHF7I6k7K6twvWmE3HU1dLVUFF332jufAP2DuUVWRpp/wCHbLy1 JsvM4SnbJpRyNk66dvvHUBqhcuvbD3kj9vOVuTNu5xlub7Z72S4dACCbK3jfwI6KRqlUypKwj1jw 0A8MHCHB33a9kD7z+4fOs+wwW9p+4Y7VSjAiPcL+eL6l2kIOhfBt5IACUIklclyMsNZHsXrHuDqT fOR627o2lvLZm89vzaarbG7qerSppkdisdXQSO81DlMVVBb09dSSTUtTHZo5GHvO7lbd9g5g2yHd +Wry3ubCUYlhoQaeTUoysPxIwDKcMB1z+5y5SvuR91vtr3jYv3duYNXRkEZIJNCCBR0NKqykqwyp PThhofAVLoENvyVHP+JH0t7GCg0APDqItzk8XUA1ehdwmSSLQHy0tOvHop6ieEn8WaRD5Pz/AGdP tR4FrJXxoYyPmoP+EdR7uVk8hbRt4dvVlDfyOP216M/1RnNtPmKGHObgooqBeHGUr3jgIuP1vVuA RyfqfYO5psbNbKZrHb4jP5aEXV+VBXos5T5Uiv8Amu1G9bMv7v4trRQh4ceA6ui6J2p8ad0LQxT7 j2K1VIIwf4d2OcLVlja5Axu5sfKHJP4F7+8Oudr/AJx25pngsboRCvG31r/xqNh10z9s/Zz2N3KG 2E9hZRXBAzDf3Fs9f+bF3EQfs6PjH8bOrq2iZsDmeyaeHxMUnwHc3YU9KLJ+pVO5chSlf9ha3uFG 533+KYfV29mXrwks7cH/AKtqeskF+7v7dfTn907vzNAlMG35g3cr+Qa8kX+VOqmfmB8bd1Uu5I9w bO3JkNw4unxq0dTjt6blqa7NY+WCaaR5qLK5IGKooJxJqMbsjxyBjdgw05D+3vNMN7ZC1u7NI7gt UGJAqGoGCq8GHyqCKcOueP3nPuzb5ccxW/MPLfMl1uG3R24jaLcbySa4iKsxJjmmw0Taq6GZWRtR 7gw0kv6p6jx24u/es+qe/NyZLpTam/JoqtN3ZXGGmp6/EzrXDGS4fIZX7bGRUG48jj3oKfKv5qOn nbUyuFI9jDmnmG42nlvfN15ds49y3GzFDDHIG0v2lg4Srao1YO8QpIQNI0kg9QH7Vey237t7ncoc ne6O4z8vcv7i2r6mSLSJIjrEZieXTGI55EMMdz3wq51EMFI62Mdq/H/4w9ObewGwOu/kF3qMXXxV OY2v1x1N3NlavLZ6OukkmqcxQ4bq+ipc1W0tZUIRLk5nWlSwElQiINOGG78689817heb3v8Ayztr 3i6Ulubu0UKmkAKhe5YopUcI1Go+SEnPa3l72n9puQtp2vlrlb3P5lO3srSW9lt+6yM8ocktIkVg iSMrNXVMxCDAaRVAoKOG+G/W266ynyu/NlZqsxMUiTR4ntXsnfHc+8MsEd2H8bqt57t3Ttfa0Eq2 8lLiUqKiQf8AKbGpeFg5ce4G72UbwbZuMSzkU1W1vDaRL/pBDFFJIR5NLpUf77OGA9272T5Y3OWK 637Y7h7QEEJf311udzJQ/wCitc3FxBADjUlvrc/7/UakJ3qKio8bR0mOx1JTUGPoKaCioaGigipa Oio6WJIKakpKaBI4KampoI1SONFCIgAAAHuOJJJJpHllctKxJZiSSSTUkk5JJySck9TvBBDbQw21 tCsdvGoVVUBVVVFFVVFAFAAAAAAAoOpPunTvXvfuvde9+691/9Xf49+691737r3Xvfuvde9+691D q6GnrRH5VKywOZaWpjIWopZipTywSWOlipIYEFXUlWBUke3I5GjJ0ntPEeRHz/1VHl0zNBHOF1ij qaqw4qfUH/D5EYIIx0BKYSfqzsXdnYlSoqNsdmQbeG/62jglK4Pc+1Md/AMLvWoplaVocZl9sR0u OyhGpKM42lnFoXqWhEhuF3ra7LakNLyzL+CCR3xyNreIHzZZNTx+beI6/EE1Aj6V+V9+3Tfphq23 cVi+pdQaRzQp4UdwwzRHhCRTHIj8KJ8IZCkjvL43dC/KLaUW2+5evttdg4V4GmwuTqIzFmsP95Fd chtfdWLlps1hpJUZX10lSiSgDWHXj29ynzxzdyFuLX3K+9T2V1WjqDVHofhliYFHpwo6kjyoenuc /b7kf3K2pNv5u2G23CyK1jdh3pqHxQzIRIlRmqOAwpWo6oh7t/kALTVldm/jX3DF9vIZZabY/cNL PIab+2kFFvrbNJI0q3JRFq8PIwFi8xN295ecn/fIYJDa89cuMWFKz2ZGfm0EpFPUlJh8l8usFvcP 7hSXDT3ftvzUiA1K218poPOi3EKn7AHtz5Vc8eq+90/ywvnL1vPItf0dl9y0kRbTktg5fb27qSeN P92R0mJyQzUakC4EtFE1vqB7yQ5f+8Z7ObyqaOcYbaU/huUlhI+1nTw/2SEfPrCnnT7oP3gtikmP 9Qp7yAcHtJIbgEeoSN/FH+2jU/LpC7X2B2fsTc1FSbk613njslHULDJi63auVeuLXAZBRLRS1Dtc fQKb+xlunNPJu9bZO9lzXtzwFahluIqft1AdY7Qche5PKXNVhLecjbulwslDH9LOX+Y0hCSflTPl 1cx0h1ruLdGOoRlfjnmczBMkYMu4+o3gpXBA5as3HgqSmAI/Jf3hzzrzJsNncT/Sc+26ODwhu9R/ ZE7H+XXUX2p2Lmjc9vtBfe19+6FRmfb3Qfm08ar+09G8k+GmGyMCSUvQe3Nq1rqp/iG1s/DsavjL Dk+bZ248XLG6/wDBWsfwfcPv7pG3dgebLi6jH4ZYzMp/5zxtjrJAe0lxcRq0XIUFrMR8UUyW7D/n BMhH7D0pti/DXc20suMtRzYGqkKL9q3cO++wu+6DCSK5YVOI2XVrsLFwVqG2h6nKZDx2Gkg3JKN4 9113K2a1rLFF5izhgsWcejzjx3IPmEjjr5jpdtHsnu1ldpeeDt7SjKtuM93uqxn1S1Is4gw4gyTT UPA9VlfzZviR2juDdXR27J+5cz3D2R2lvnB9LbF6nptkYnblFiqGfH5fNZ/NbahxGTq5abCY+alh lr3qY52p45hJPVmNEVZQ9juftms7HmSwTl+Pb9os7Z7ua5MzSM7BlREkLqKuwJCaSAxWix1Jri19 7v2M5q3ve+RN9ueeZ965l3G+j261sBaxwJEmiSSSSERSMViVghkLqzIH1STlVUC+vo/4/dQ/HTZt HsjqHYuB2ZiYYKda+XGUurK5ysgj0tkc/m6kzZfOVzszHy1U0jKG0rpWyjGDmTmnfubNwk3Hftyl uJyTpDHtQE/CiCiovyUD1NTnroXyJ7d8ne22yQbFydsFvZWiqocoKySsBTXNK1ZJWP8AE7EjgKDH Qzew/wBDbr3v3Xuve/de697917r3v3Xuv//W3+Pfuvde9+691737r3Xvfuvde9+6914i/B5B4IP5 9+690HuQ2HJBC/8AcbcVfsKpMrzinxtFjsntyeaRxJJ91trKQS0sMcz3MhoJKCZ2JJkuT7NI9zDs P3larcpSlWLLIB8pFIJI8tYcD06IJtiMSH9yX72L1J0oqPCScmsLgqAfPwjExOS3QFZ/F/K6Pd1R Llsxt7c/WcVNRpjsd0umM687Bq6vyytkm3KvaU+8cRVUhiWIU/8ACc5hZlYyeRmGj2JLWbko2KCC CWHdyTqa71TwAU7fD+nETA1rq8SGUcKAZ6Bd/be5w3R2ubuC45dCrpXb9FrdM1Tr8X6wzoVpp0+D cW7A6tROOlvBuvrLK/w7D752vurC1wcUlPR9rbYzdZSSzj+z/eSqXO7KyE7k8GLISn+nFvZc1nvE Piz7bewyR8SbaRAQP+aY0TKPtQdGq7hyxdeBab5tdzFLXSFvoZHUn/mq3i27H/Syt8uhsxeFwuGg EOExOLxVMwBEWLoKShgI+oIjpIooyP8AYew9NcXFw2q4nd39WJJ/mT0M7SysbKMJY2kUMR8o0VB+ xQB06e2elfXvfuvde9+690joNhbVj3c2/Z8VBkd5jGy4Wk3Jkx97k8ThKiZKiqw2CkmDR4LGVs8S PUxUiwireNGnMjRoVXtud6bH92LOU2/WHMa4VnAoHenxsASFLV0gkLQE9E0ewbUu7HfpLUSb14Zj WZ+544yatHETiJGIBdYwushS+oqCFj7QdHPXvfuvde9+691737r3Xvfuvde9+691/9ff49+690Tr 5H/zAPh98Rdz4HZnyM7uwPWG59zYH+8+CxGUwm8MtUV+B/iFXiv4kj7a25mqeGE5CgmiAkdHLRmw tz7HHK3ttzvzraXF/wAr8vyXdpFJ4bsrxKA+kNp73Uk6SDgEZ6CHMXPvKPKVzBZ8xb1HbXMsetVZ ZGJWpWvYjDiCM+nRdv8Ah7L+Vx/3lztD/wBA7tT/AOwP2KP9YP3e/wCmKn/5y2//AFu6D3+vR7Y/ 9NZD/wA45/8ArV1mp/51f8ruqqIKaP5dbKWSomigjao2t2ZSU6vM6xo09XV7HgpaWEM3qkldI0W5 ZgAT7q3sL7uorOeSrigFcSQE49AJSSfkASfLra+83tizKo5thqTTKTAfmTGAPtOB1YxsHsHYnam0 cLv7rPeW2N/7H3HTNV4Hd2zs5jdx7dy9PHNLTTSY/L4moqqGp+3qoHilCuWimjZHAdWAi/cts3HZ 72423drGa23CI0eOVGR1NKjUrAEVBBGMggjB6kSw3Cx3S0hv9tvIriykFVkjYOjDhhlJBoQQc4II OR0Xb5J/PD4k/EHL7YwHyP7pwPV+Z3lja7Mbax+UxG68vUZTGY2qioq2sQbZ2/m1poYqqZUBmMZd r6dWlrCflX265052gu7nlbYZLyCBwsjK0ahWYEgfqOlTQVxWnnxHQe5j565T5RmtoOYt5jtZplLI GWRiyg0J7EamTTNK+XTV8dP5hnwy+Wm8Mr1/8eO+ds9lbzwu3p915HbuPxe68NkYtu0mQx+Lq8rD Hufb+EStpqWvytNHL4GkaMzoWADA+3uaPbLnvkuxh3Lmflya0sJJRGrs0bLrIZgp8N3oSFYitK0N OmuXvcDk7mu8lsOX99iubxIy5QK6nQCFLd6LUAsAaVpUV6NlufcuC2XtrcO8d0ZKDDbZ2ng8tuXc WYqvIaXFYLBUFRlMvkqkQpLKYKHH0skr6VZtKGwJ49gy0tLi/u7Wxs4jJdzSLGijizuQqqK4qWIA 6FVzcwWdtcXl1IEtokZ3Y8FVQWYn5AAnqs3/AIey/lcf95c7Q/8AQO7U/wDsD9yx/rB+73/TFT/8 5bf/AK3dRt/r0e2P/TWQ/wDOOf8A61dWiUNdS5Oho8lQzCooshS09dR1Cq6rPS1cKT08yrIqOolh kDAMARfke4ikjeKR4pFpIpII9CDQj9vUmxusqJIhqjAEH1ByOiz7n+bPxF2dkM1idx/I7qDH5Xb0 lXBmcYm98LXZGiq6FWNZQNQ46pq6qbJUzo0b00aPOJlMWjyAr7jPcveL2r2me8tdw9wNqjurcsJE +ojZ1ZfiXShYlxwKAFtXbTVjqZdn+737479a7fe7V7U77LZXQVopDaSojq/wvrdVURsCGEjEIVIf VpNemranzz+Gu9IsLJgfkl1QZNwmnTF0OZ3RSbYy0k1W4ip6arw25/4PlsXWSyEKIaqGGXUQNNyP aXbPe72k3hbNrH3C2vVPTQskywuS2AGjm8N0YnGl1Vq4p0t3r7tfv3y++4LuXtPvem11GR4rdriM BRVmWW38WORQM643daVNaA9OO/Pm38UOsN3ZrYe/+89kbV3ht2eCmzeAylVWx1+NnqaOnr4IqlIq KWMNLR1ccgsx9Lj2o3v3j9sOW91vNk33nSytt2t2AkidmDISoYA0UjKsDx4HpLy193r3q5w2Pb+Z OWfbncb3YrpS0U0aoUkCsyEqS4OGVl4cQenXsX5hfFzqbcuO2d2H3z1ntndOQz1PttsDVbnoKrJ4 XKVMElRE27qXHSVkmyMUIoyXyGY+xoIyVV5lZ1BU7/7se2vK+42+079zvt1tuck4i8IzKzxuQSPH CFjbpQZln8OIYBcEiqLlX2J94+dtput+5W9tt3vNmitmn8Zbd1jljUhT9M0gQXclTiG18aZgCVjI UkGAxGXxOfxePzmBymOzeFy9HT5HFZjEVtNksXk8fVxLPSV2PyFHLNSVtHVQuHjljdkdSCCQfY7t bq1vraC9srmOazlQOkiMHR1YVVlZSVZSMggkEZB6jG+sb3bLy627crOW33CCRkkilRo5I3U0ZHRg GRlIIZWAIIoRXopO3f5gfw73b2rR9Kbb7wwGZ7GyWdk2zjcTRYXeEmIyWdjd4hjcdvI7dXZVdNPN GY4TFkXSeUhIy7MoMWWHvr7TbpzNDyft/OcE3MEk5hRFjnKPJw0LceF9OxJFF0ykMaBSSQOpv3X7 sXvvsnJdx7g7t7d3NvypFbC4kkeW1EscJAPiPa+P9WgAOp9UAKLVnCqCQKuV+SvReF3nh+va7sfB tvLObvyuwqPBY+PJZiop93YLALunM4bNTYihrqPbc2M27ItXPJkZKWGOF1JcalBE117h8l2e72mx TcwQ/vaa7e2WNQ8hE8cXjSRyFFZYikRDsZSihSKnI6Bdl7Se424bBf8ANFvypcDYbaxjvGmcxxK1 tNMbeKWISujTiScGJFgWR2YEBcGiKf5xfDhNwQ7aPyf6LORnxUuZSpTszakm31pIqpaRoZt2R5Nt rU+VMrArQSVi1zxXkWExguCc+83tKL5NuPuRsv1BiMlfq4DFpB00M4fwQ9eEZkEhHcEK56EC/d29 +W2x93Hs9zH9KswiKmwuRNqK6qi2Mf1DR0wZliMIbsLhyF6Yt7fzAPh115u+t2Huvvba1HuzHS0l PWYnHUG5dxtFU10MNRS0q1m28Hl8fNVSxVCftJK0ilgpAbj2i3j309pth3WbZNz51tk3SMqGRFml oWAKjVFG6kkEYDEitCK9GXL33ZPffmnY7fmTZfbe8k2SVWZZXe3gqqEqzaZ5onCgqe4qAQKgkZ6O J7lnqCOv/9Df49+6918+f/hRr2Ed6fzLNzbbMgcdR9PdT9ehQFBiGSxeQ7W8bEEliT2cWubGzAfQ A++ln3Xds+g9qbS6p/ubfXE3+8stv/1g6wE+8PuH1nuRc21f9xLOCL9qmf8A6zdE++DH8rb5N/zC cB2DuXoeo63ocT1tmMHgs9Udg7ly+3fucjnqKvyFNDiP4btnPpWfa01AWqNTRGPyx8HVwN/cL3e5 T9s7nbLTmJbpprpHdBDGr0VCAS2qRKVJxxrQ+nQQ5I9sOZef4Nwudia2WK2dVYyuyVLAkaaI1aAZ 4UqPXoAPl58Q+5fhF3LX9Gd50GDpN40mDw+5qSr2zmFzu381t/OrUDH5bE5A09FUtTtU0VRA6T08 EyTQOCltLMJeSedti5/2KPmHl6SRrFpGjIkXQ6OlNSstSK0KnDEEEZ6IebeUt45K3iTZN7jQXgRX BRtSMjVoymgNKgjIBqDjrZH/AOEsvZe/Zs98q+oJsjX1nWVBhNh9h0OLm88uOwG9a/I5Xb1dVY9r /b0VTunC0kS1Kn1VAxUJW3ie+LH3v9p21bbk7e1iVd2aSaEsKBniCq4DeZEbE6f4fEb1HWRn3X9y vzPzTtBkY7aqRShTWiyEshI8gXUCvroHoeiYf8KW+wxuz+YHt7Z0FQGperOgNh7eqKVREfDmtxZ7 eO+Kud2W8okqMPuPHLpYgBYlKqNRZh391LbPovbW5vmXvvNymcH1REiiA9MMj/t44wDfvIbh9Xz9 b2at22thEhHoztJIT+aun7P21S/A35TZn4ZfLHpr5C4z7qfGbM3RBT72xNI5Emf673BHJgt9YZYy fFLVVG3K+eSj8gZIq+KCWxMY9zH7i8oQc98mb7yzLpEs8JMTH8Eyd8LfIBwA1MlCy+fUWci80Tcn c1bPzBFUxQygSKPxxP2yr9pQkrXgwU+XX0Dv5p/cWH2x/K6+VnZu3MvSZLAbz6Dqdu7fzdBJTz0W UxPeRxHXWIyFDPMVjkp8lSb8jeGRf3LSBo/XpHvmt7P7HPd+7vJ203UDJcwbkHdDUFWtNU7Ageam EgjhjOK9Z8+6G8Q23tjzTudvMGgmsCiMKEMtzphUgnyIlFDxzjNOvnLfHfr0dt/IDozqkxecdm9x dZdemHWkfmG9N64TbZi8kiSxx+QZK2plYC9yD9PfUPmfc/3Ly1zDvNafSWM81fTwonf/AJ96548v bf8Avbf9j2qlfqbyGKn/ADUkVP8AL19WDsnPHavXe/dzrOaZ9u7M3Pm46gUWWybQyYrCVtdHImNw KSZ3IurwArT0StVzH0QgyMo98UN/vl2zYt53J5Ci29pLISEeQjRGzVCR/qORTCR97HtTuI666cq7 cN35n5c2po9a3N/bxFdccdRJKiEa5qQoCDl5T4a/FJ2g9a1nXu6PjT8b9rV/Z/aOJp+38/tPC1eG 646Kxfxu351V1HNks9lqiauq92djdr7W3lunf25JaeunmpqzcNRU/ZIhjhilaOmeHn3sm6e03t9b ScxcxxzbobWIx21guzT2loWlclmlnvUlkupqMxR7udtAFFVisZTq9zXae6/uru1vyjyfePsW3Xtw st9u8m+Wm47kEhjUIttZbdPaW9lACiLJFZRx+KTqd0DTLI9d0Yrqnuzvzr/BfH/ZCRddfIBts7a7 Y2H2X8ct77e692Nm8bX7Yj2lP11vLZu29mb92XPubII611RQVdPjjKrT10zUkzwRruY7bkHnPnba rHlPbbhNj33wYbm2uNmmS0gkVohCYLiIWt1amVh+o8L+EW1PO3hMVCHkDeOcvb/225j3D3K35m5q 5Z+on269sN8tZr27ikS4Nyt9a3U11Z3YgQgwpNE84UiO3QTxrIz9L3Z8g2+ZW6flMNo9P4zrbLfK 7bvwkyuxd0UuT3Dvui6r6+hq94dm7vo5mwuIoMFnqDHU8mUniaWXw5Oojp5ZGgppDMevzduR90dy 9zfDhj2uXmKPl57Wa1SSZYLVTcXUiv4yeHpAaWRyCySsqMjKjBitOSfbAewuzezZ3jfZea4OTp+a o7y3eOC0fcb0rbWFs6+JK80LuVt0YKuq3RpUUSSror52vkOz81i8Fv8A3f0D8Vt0bi2Hkt2b83dt jem6d1L2b8k8n8uxWU/Xa0EB6ayNZvKTZRrTVYmCirJ0oqwiol8cisFhXbW2e8tbTfd02Hb7m/sZ JrmaG4gX6zdn33ULXSKs1wbfVrgWORhFJ+o2lgQMm94l5RsLvc+Wtj9x+crLa9yhtbO1ntYLf6DY o+WtDXuo/vNEtRd6BHcvLEhlirEmtSCdgD5Xbf3F0j/Lw2P051hSZjZXYO4W6c6X2Zt/bnZmRwy0 m8975jG0eW29XdhptXK57J7bUzZBal6fHU9XkadNCmk8hkizM9x9uh5O9k9m5P2iW9sLm4ey2+3W 3mpKJrh1UxtKe5ozWQS6SrulQrLWo5p+zW87Zz996HmDn7nCW33Hlq2/ee6XU09hHLqtbWJ2jmSy +ojhjnxCYw8zxwOdRE2gK5LPkPsj5d7L6d6E6P3vF8F8dsLAd4dKbR2Ft747br7q2p3htjdMe6YM bQ5zrrM7yTceJG7se9ZUy1VTkaCpMjzSzyjzkP7jbn/YeY9n5R5L5N3fceXY9ng3iwgtItrS5h3C K4EwRJLaSe7lQTKWYySSRSHud2UvQ9T77Y80eyO989+5PuJy+fcSbmW65f3W4vJt7g2q52m4tzbl 3hvorUQSfTOFjWOOCaPSESNP0wV6BfovObrq+zqrtuGi/vAMFsv5/fLrEVtBQVnZ+ayFX2Tuui+N XXVRV7Xq6bbUe9VWm2VJPNRyV9EskXnZZgsk8igHlG8spN+l5rs5r26mgtOY98jP0yXLP9XMu0Qs 0fjL45X6clYyyCRNbF4wz0HnuJFssfKEPJDyfSi4vuTeW5Ud1sIkSwgffb1UuFM5tCWugqyrDKVb wwYyUjUlt60n7Uzm69udXZjZ25KHZmwe29ibuTe8/wAO8VW76y1XkKiv3ruDbneElX2BCdudYY/B 5RKhMa2RytFWbfhWWWmp4IAksd7DLNeXm1cuS7duq2dlusE7TPy7B4zMxa4aK/c3xZLMRPrMLM8b WyhjGESjStzXc8mWGz7tzhY7vbSb9ueyXdqbQczyJZxKipawz7SFsj424PLGUM4gt5YrxmRJZJJC yHy+EtX8u8Buj4lbd293Fsfa+zfljm+9Pkl27sSi6xweay2z9s4LdEVbTQUO8sqy5bdlX2nSmGgW rlgxI2+raoo8h4NDzj7SSc52O4+3e37Lzt4G1czy3+7T25262LxxRzBnDztM8hN0KRxuB+iMgNpo ccfvAN7H7ttHvPum6cg7jeb/AMmW207Ftl4+4TRR3M8tuUZntYx4duu3tqmMavc/WkUdrbxNS7GP vOfrlr1//9Hf49+6918vj+aB2Ee0P5hvzG3aJBNAO/N/7VoZ1ChKjF9e5eXr/E1EekkGOoxm2InU mzFWBIBJA64+0e2fuj2y5GsqUb92wyEejTL4zD8mkI65le5u4fvP3A5vu61X6+VAfVYm8JT+aoD0 Yb+Xx/OG7o/l09V7w6r6t6n6k3pQ717AqewMtn9+LvR8ytVNtzb23KfEU67f3ThsauMoYcCZoyYD OZaqXW7KI1QMe5fsfsPuhvFjvG77ze28lvbCFUh8LTQO7ljrjZtRL0OaUUUANSRDyB7vbz7ebXeb Xte1WkyTXBlZpfE1V0IgUaHUaRpqMVqxqaUoT/5bfLft/wCe/wAgqrunu/MbYxu4s9Dg9o4mlxlJ WYfY2wNo0FXP/DcNjYHlzeYhwOLqcpU1lRLNLW1cktRNIWdmCgb8l8l7J7cctJsPL8Er2sZeRixD SzSEDUzHsUuwVVAAVQAoxSvQR5s5s3fnvf23ne5oluJAsahQViijBNFA7mCqWZiSWYksc8Ot73+S x8GeuPhr8VKfObU7H2Z3PvLv+bFb63z2r13k/wCMbDzFJiYK/H7V2rsvJARNkNvbOFdXqaiaKGqm yNZWGSOFRHTw87ffn3C3TnrnFre82uewsdtDQxW8y6ZlLEGSSVc6XlonaCVCKlC2WbOX2a5I27k/ lZZ7XcYby8vysss8TaomCghEjPmkdWyQGLs9QMKulr/OE7D/ANJ38zH5hbiE61C4rtWbrxWURBY/ 9EuAwfVrwBYfQGp5dnMjf2i4Jf1lveePshtn7p9qOR7XTQvZib/spd7iufXxa/Zwx1hr7u7h+8/c nm641VC3Xhf84FWCn5eH/nz1XpmNr7h2/QbXyebw9fi8fvXAzbo2nV1kDQwbg29T7j3BtCbMYx2/ 4E0Ee59qZKhMg4+4opV/s+5Ngu7a5ku4bedXlt5BHIAalHKJIFb0PhyI9P4WB8+o/mtri3S2lmhZ Y5o9aEjDoHePUvqNaOtfVSPLq9HdX8wcdn/yJIfi7uLNPVdmdX/Ibqrp56WokSWtyfSkuP3x2p15 lS9VMZZKPbWR66kwBWmT/JKehoFewqLnHqz9tP3T94hubrW307Td7ZcXNRwW61RW8y4HGRZxN3Hu LyEfD1N91z/+8/Y0csXE1dytdwgt6Hi1tSSeJs+SGExY+ELHX4uixfyTuuz2V/M8+KmLkgaWi23u zcfYldIGVVpR13sXdG8MZPIWjlJV8/iKOIALcvKougu6iz383P8AdXtJzjMGpJLCkI+fjzRxMP8A eGY/YPPgQ17L7f8AvL3M5WiK1SOV5T8vCieRT/vSqPz8uPX0aOzo+zpdjZ6Ppup2PR9kulAu2qrs imztZsuBjlKH+KyZmm21UUualIwn3P2whcD7vxGS8esHkfzIvMjbJfLyhJZJzEQvgm7ErW4711mQ QkSH9PXo0n+006qrUddP+U25TTmDbm54i3B+VgX8dbFoluj+m/hiJpw0Q/V8PXqB/T16aNpPRHa/ 4L7u74qpsp81+6avuKnp8VmqDanWewMIOuurtkZLN4utxD7tpaJKrIZLdG88RTZCY43IZG7UTSH0 SAKFhWf2T3XniV7n3k5xbd41ikWCztY/pLK2eRGjM6rqZ5riMM3gyy5jJ+FsUyAt/vB7L7dwpZ+w 3IibHK00T3F9eS/W390kUiyC3ZyqJb2sjIvjww4lA+Jamq96M6e+XXTG49r7Iynd/W/a/wAedvU0 uKpZN4bHy2K7pxW28fip6fbOEocrt3I022cvU4+ohpYJq6vWSSWmEj+PyaEU95K5S91+T9w2zZbn nTbt05At1KA3Fs6bgkKoRDGrxOIZChCK0soJZNR06tIAd9wed/Zbnra933+05A3TZvcy5YSMLa7j k2uSd5A08rxzI08aupkdYoSFV9K69OpiRnL/AMun5a7kqMlt3I9odD4fZVH2L3vv3bucxtFv7J73 zGT+QkU22915velFU4/GYRs3tzZtfUHDiinQRZAp5ppYlBEKXf3ffdTcZLjb7jmXY4dmTcNzuYpE W6e5kfdAYZ5LhSiR+JFbs/geGw0y01uyjrIKy+897M7VFa7nbcpcxT78+17RZzRO1mlrHHsxE9vF asryS+FPcon1PiodUOrQiOel5jP5avbGM3N1V3HD3ntQ9wdI/wBz9rdY7equu8TkurcD1JsqCqxO K2VX1FXQ/wB6s7uI4qqef+8EwWsgrJZGhjSUQ1UJ5bfd05ptty5X5uTna1/rbsvgQ2cTWiPZRWNu GjS3YsvjSy6GLfVNSRZGYoqtolQO3X3qeTbraecOR5Pb68/qTv8A9TcX8y3siX8243RWSS6RVf6e GHxFCfRrWN4lUOzJrhc6Py/6H7F7x2/1JP1XunaW2969Pd2bO7mwkO/cdkcps7NZDaFHmoaGhzFP hx/E08VXlElSSEhlCuFKSFJY5h92eR+YOdbDlV+WNztbfedo3m33CMXKO9vI8CyBVkEfeKM4YFc4 IBVirLBPsn7icse3+5c5x837Re3Ww73sFztkps3SO5iS5aIu8Rk/TNVjKkNgkgkMoZGLZtv4rfI+ l7FrOxs51h/Liptz5Sr3Pm8lvbbHV3bUG/jujPUuTqTn6HP5PP1D0WVq89WLJU1i/wCU+KSUo2th eOtu9sPcOLmCbmG95a9vV3KVppHuIbO+F140qufFWV5TpdpWBeQd+kvpNT1Ke6+7/tdNyxByvt/N vui20wpBElrPf7cbP6eFo18F4UhUNGsKlY4z2aggYaR0HO2P5cHbeP6r7R2nW736o25ubsvaOwel KOPY9Fvt9p9edGbf3LW7n3jRbel3XXZnc+d3ZvHIV0jSff1Apw0khMnqUIH9t+7zzXb8sczbVNvW 12+5blaWu3KLZbkwWu2xTNNcLEZ2kmlnuGYk+K2ipYlsigo3b70XJdzzfyjvMGwbzdbTtV7eboxu ntBcXu7TQLBbPMLdIoIbe2RFC+CmuiqAmCWTWQ/lv/Iuq21hcxR7+6UxnamU7B7y3TvaOkh33HsX C4btbp/HdP7Yx2xpBQfxutn61xNHPPjhXwwgzVY8skqQslQWz/d59wJNus7uHfdmj5nlv9ymuAou RbRx3tglhClsdPiMbNFZohKq9z9zMEIkNbb70ftjDut/Yz8ub9LyfDtu029qWNobuWXb9yfcp3ux r8JBfSMiTGFm7Y+xULhozv8AVHxWy3WPfeyd8w5bBVvW3VfxH2l8bNhY8tV/3qky2K3NS5ncO7sv RfwuLD0UuXosXTRGWnq5ZZWMmpEBJkmjlf2wuuW+edm3tLqB+Xdr5Ug2i2Tu8cukyySzyLoEamRU QaldmY6qquS0Ac4+8FnzZ7db9y/JZXEfNW8c6XG+Xj9v04jkgaKG2jbxDKwjeSRgrxqqjTRmNAp2 vczdQJ1//9Lfc3PuCg2ltrcO6sqxTF7ZweW3BknXTqSgw1BUZGsZdRVbrT0zEXIHtRaW0l7d2tnC P1pZFRftYhR/M9MXNxHaW1xdS/2USM5+xQSf5Dr5IW6dxZDd+59x7syzI+V3RnsvuLJtGuiNshms hUZKtaNf7KGpqWsPwPfaWztYrK0tbKEfowxqi/6VFCj+Q65P3VxJd3Nxdy/2ssjO32sST/M9byv8 vf8Aknfy+Oz/AITfGbs3vP49HefaXZPU+2+wtz7mbtfvXbhyi73ik3RgpP4Ltnsjb2BohT7bytHC BTUcUbiPX6yxkbnx7l+/nuXtHP3Nm08vczeBs9revDHH9PaPp8I+G/dJA7mrqx7mJFaYpQZucgey /IG58l8tbnvnL/jbpc2qSu/j3KavE717UmRRRGUYUA0rmtTqPfzE+qekuj/mt8hOp/jpm48905sj ekOI2lVQ5qXcUWOmO38LWbo2umcqJ6qpyq7M3hVZDEeaWWaZ/sbySO+pzmn7Ybxv/MHIXLO880W5 j3y4gLSAqE1DWwjk0AAL4sQSSgAA14AGOsTvcLatl2TnPmDauXpvE2eCYLGdWuh0KXTUSS3hyF46 kk9uSTnra3/4TC7r3TJ8Pe/8fuLIVH9wNn95zT7Znr5SaHEVFdsPb+V3lSUk0shFLRQBaOskiULG ktVJLy0rn3hx97azsxzvy3Laxj95T7eBIBxYCZ1iJHmT3KDxIUDgB1lP92e6ujyhv0dxIfoIb4lC eCkxI0gHoB2sRwqxPEnrS37b3zUdn9q9m9lVhc1fYfYO8981RkSOOQ1G7dx5LPzmSOICKNzLkDdV 9IPA49547Lt67Rs+07UnwWttFEPsjRUHH/S9YbbtfNue6bluT/HcXEkp+2Ryx/w9bPX8xf8Al8rJ /Ji+B/fO1cKw378b+leu8h2JFFAHyFR133nSY7d+5I6lqfmpOxeyd0xTIuhkgpK6vmMllYtiT7X+ 5ZHvt7i8uXk/+67db+ZYM9omtC0aUrw8aCMg5qWSNaZFMl/cPkAH2c5G321h/wAf26yiMuMmG5Ak etOPhTOD8laQ19dUbUwUpqOlirFbnSWUMFYj6EqHNj+Ln+vvMj5+fWLHy8utj/8A4TGddncfzf7Q 7AqYDJQ9b/HrcMdLMrKPBuPee89l4nH61aNy0Uu36PLjgqwYKbkXBxa+9nuf0vt/tG2o1JLrc0qP VIopWb/jZj/n1kV92nb/AKjnbc79l7Lbb3ofR5JI1H/GBJ1tN/zIe9sT091EYd14r5V4bZOSnxFd uLtv4tZTD7a3LsqWPc2FxWDwlRuXKmWogl3dl8lFTinpIJZZ4wyOUR/VyA98eYH2nlsWktnzHHts rI0t5tE9vbTQFZUVIzLO6keMzBdMasWAKkgNnsb91P27u+d+d/G2i+5Ln5ghWRINt5hjluLe7Bt5 ZJZRBEApFtHGz65XVUajKGZcUg9/d2ZrblNn9sdCb5/nXZLszae313rvmLuXN9o4DGdabGRZqkbx 3TtHCdeSbjqcHVQUU4SeqqcNQIEaRqpgjIcS+d35msYLmy5F3r3Vl3+GLxpvr9x8OO2hyfFkhjQy uhAahZ4Ix8RkIBXroZ7Z8i7Vus227t7l8vfd9h5SvLn6W0O1wWE0l/dmi/TW9zNeiBZVLJVI47qY 1CiEFg3R9ZP5gyVvwMx++Nu717kxUeEquvtk0HyF3t/oy643h2vuunwOc3X2fLsXCdt17YPdEO1q jAHDVAo5MnVVlVLJHRidoDPJNE/ufvR9n7aexvN1S7h+khXcpZNugnu5fDklu2hS6maFxC0fgNRp HdmYRB9HiNjUn3aI7f7yF1sO67HsE31KXt0+y2v7wvrXbrdporbbxdzbagmtzcLN9UniLBHFGqNO YxII1JL0z8r/AJIbuqt1UeP+Q/cHZWb3/W7yzu1NjbT76+KtZueq2xJtKoqsVEu333XX762bnsPi aOSuyNFt+jx60LQSPHDFMsknuGOWObPdy8k3aM82bzfXN5LO8MEO57IXMRhPhjSbhp4JEUGSRLVY lQqWRVYM3WQnPvs77Q7LFss0/tlsG02G2R2sNzd3Oz8xLAtwLkLKfGFslpdQyyMsMEt7LOZg6q8j xlE6O78X/kd3bubpjaXyd3kPkPjesenviVvbcmQ3NuTeOztw9Tdr57rTa256ap3LmsMKGp7ZzO8M zlBJNpq50kM+PVWLuqiSXvbzmb3Duth2nnLe4t7i2va+W5mZ5byzmsb2e2hlXxZFBa7eaRzqJkcA NGNTEgase/eD2u9udq583v2k2B+VpubN952tIEggtbqDcttgv7i3YQRS6l22K1ijotY0ICTEgKpJ StiD5x9lUWwex6F/kN8xKDdO9tvfH7ZNfj8/g91Z3sGDufsWm3X2Jlanp3aU+4+vM5tLaeQoNu47 H0dTh2nJx+WhL0korqVkg9OcfcSHZd/tzznzMm5Xtrt0LCSVJbhb6fxrmZrKP6u1a3hIjiiRoWJM UwPguJFKZYS/d/5LuOZuVLhfbLkOXZ9vut6u0eGW3hsm2qya2sol3S5FvexXNyjzzzyR3QX9a2cL On08wYwXRvyW+T2Q+THR/TXePYfye647P7S7vwfblR1zuzqXfO3ttVm1IqnL4qXZWHzm4++MBIvT 9LhaOsnloU29LevgLVUdeaZQwu5O3/3el535U2PnLe99st2vt6jvZLeSLTCYQXQ20btu6N9CIw7G JbRqyisiz+GKxl7i+1Xs1a+03uFz17d8scn7ryns/Ls22Le2+5Wk1wtwVjkF3LDBs0wO5tK0SLMb 1aQuBC9t4xoeL507NzvUAxUPX3yz+Z+Z+RPyM7FqtudE9NYXtXAwbTfcGayf8Ry9XJhsT13DW7e6 s6+xlYXqJmq4IKKnEEUlTEjNMkr+73Ku9bFA8vLHuZzbPzvvF4yWNkt/BHbh5H1OdH06MlpbI1SF caV0KWAJcY8fdz5i2rndrpuavZTkC39ruVtrWfd90l26ZrnwYo9ESiWS+Kz7jeyLRFEbvK/iOsTs BGxiNudlfPfZ+3NvdXUPxNbfea2xSY3Z0vfvYnyJ6zp9v7xbCJHjarszNbZwQrt9xU25UpTWrQ+B shEKhUmLSq5YX7fzD74bTt9hy1D7XfW3lsiQHc7rdbQRT+HRDdyQx6rkCbT4gj0mVdQDksGJi/de Uvu077uu6c5XHvYNt2+8eS6GzWOx37TWvikyLYRXE2izLW5YRGbWIG0FowEZQA++f+8ctX/IX+XN 0FQZ7J4+s7I77qd8bnpMDUZehp8ttzqmnwFfm8fkhQTEJispjM5XKkdTIUcRsLsVPtD71NvG5c4e x3KtjcukVxvf1N14chjDRWgjLoy6wzI6vKNPdwNfmJfuzbNt1p7Y/eo9ybvboZItr5aFpbNMsTtH PuLTJE8esf2kckMJLRgEahwBHVrvvI7rC7r/09wn+Z/2B/ox/l5fMbdiyeGc9BdgbWoZwbNT5PsD Dy7AxdRGdSWmp8juaJ0+o1qOG+hkT2k2z97e5vI1kRVf3lDIR6rCwmYfYVjIPy6A3ubf/uz2/wCc LqtG+glQH0Mq+Ep/IuKdfL399ceuZXQoU/bfdGQxlNs6k7N7QrcPLR0+Co9q0+8911OMlx8cSUlJ hqbBxZJ6V6NIEWKOnWIoEAULYAeyl9l2GOV759ptFnDFzIYow1eJYvprWuS1a+dejNd23mSNbNNy umhIChBI5FOAULWlKYApTow3x3/l1/NH5Q7pwu2uqPj12XU0eXmplm31ubaed2l1rg6OpCS/xPOb 8zuOpNv0tMlI5nSKOWasqo1IpoJ3shDHM/ufyHyjZz3e88zWgdAaRRyJJO5H4UhRi5NcVICqfjZR noQcve3vOXM91DbbVy/clHI/VdGjhUH8TSsAgFM0BLMPhVjjrebp/j1tT+Vx/KD7z692tlY8xn9h fHruXdO5t6pSQ0R3n3Ju7Z+UpRnmpKmRkgxwz1RQY6hicyTR4ujp4380ykyc925mvfd73t5e3O7h KW1zudrHHFUnwrWOVToqOLaA7uRQGRmI0qcZvLy/a+2PtJvm32soe4g2+4d5KAeJcSRsNVDwGoqi g1IRVBqRn51+0tt5DeW69s7QxK68ruvcOF23jEtq15DOZKmxdEunUt9VTVKLXH+v76eXt1FY2d3f TH9GGJnb/SopY/yHXPa0tpLy6trSIfqyyKi/axCj+Z6+sbmupdi7k6iyXRm4MNHmOtsz15U9W5bB V2iRMhs2s2621qrG1DJGiapsO5QsqrZjdQLC3GiDetxtd7i5htpym6x3QuFcfhlD+IGH2NnrqpNt Njc7TJsdxCH257cwMp84ymgg/auOvlsfLL48bo+J/wAkO4fjxu7yS5Xq7emSwNLkZEWP+P7cl8eT 2huiKNeI6fdG1K+iyEacMiVIVgGBA69cmcz2nOXK2x8z2VBDeQK5X+B/hlj+2OQMhPmVqMdcw+a+ XrrlXmLd+X7upltZioP8SfFG/wBjoVcelacetqn/AISv9dmj67+XnbEsBYbj3p1f13j6lmUrGdl4 PdO5cvBCojDKZxv2haQlmDeNLBbEth598Hc9e6ck7Mrf2UFxMR/zVeNFJ+zwXp9p4+WUf3Xtv0bf zbupX+0mhiB/5pq7sPz8Va/YPztS+fGA7B+SmR3Z1piqDE7S6I+NGFm7X7i352fQ7wptgb03VS7X gztDs/Gy7GH98s1i9nbCzdZlcjJibyrXeGmDQ1CxOeQvvpYb97i3G68uWsEVryRy5Cb6/ubxbhbW 4mWESLAhtv8AGJEt7aSSeUwZ8TRHVJArHr993LcuWvau12bmu8uJr33D5rnG37ZaWD2zXlrbtcGJ 7lxd/wCLRSXN3FHbwLcUUxa5aSRF1FYvxr/l17l+Rzb83ztjBdF0vVp3bQ7S2/nMtB8k8HBPQ4rF 0jZ3dvU+Jz+5aHcVbBVSZLVfdAq4GyFP40hhhWaE42+3X3f9x9wjvm97bZbIvLP1awRSON3jBVEX xZ7FJZllYMXr/jmtTKmkIiB06yy90/vObV7Xjl3l/dtw5hfm76J7maKM7HKQ8kjeDbbjJDA8KlQl P8Q8NxC+pndyj9HD31gt99gfCf4kbKy3SncMeZ6Vrqt92Q7e6t643nhcPmegqjO9azUW8sDv3ce2 qWtxuZqMe9edEk9LWrBIKuGXUhWW97sd8372a9qtmuuTd2F5szt44isrS4jjk2wy2ZW4iuZYVZJC hlwWSQK3io1RSEOX9w5e5b9+veffrPn3ZDYb9GotzNf3trLLFvAivg9tNaQTsrxK4hyqSRF18F0o aoz4L4b5OU+16bfuB6IXdG7K/b+5dwbVk3/1J01sLYFVWbr3TTbbMlJ3LSVo7Pp8ZiNn5qpq3xNP i6damGmqKKJQjLIxP7J2fuRHtke+2PJAud0kt5pYDdWO32tqzTziGq7grfWBI7eR3MCQqHVJIVAU hie/eDvvaeTd5eXNx9wzabNHcwQ3As9x3O8vFW3t2no22Mn0BkkuYo4xcPO5R3juHJYFQgOt+vN6 9ZfD35J9R7nm7Tr++chvrb/xai27U4Xcc+x9jbAfPZreuZ3Hs2aKh+1rNjZvZWP3Bma/LNGivBTQ AiOKWOSci5d2DeeW/aX3E5T3J9zk54kvotlERjlNtbWviyXEk1uQtGtpLdbq4lnIAKonwqys4k5o 5m2Hmz3u9rOdNpj2iP27j2+bfzMssAu7u88GK1iguQX1LdxXT2dtDbgkh3koWdGWMNqXp3J7ywdP vY9edp/ICCfvLsXK7X3buTpP5D1FPv3qLbe0dtdX9bZOrzfSNNgNybOyNFWbWnqYcYWpWFNFTeRQ A0XsOx8o3O72Ue8/uDc9+Rt7u3hnm27dSLmxighs7R2k24RTW7q0LOsNUOhY9QABXoUy88Wmx7hJ sI5m2jluReX7KOe3g3TZlNpuU9zPf30axbq00FyjLcJG04Eg1tLpJJD9Gm+D3VGNHzSxGdbqXC4a HYPTe463MU2KpvkNOer9857J4iPC0+74fkI246/Db7ze1aqc0VFjq2ndaJ5nlTyI6CTfZbla3HvF aXp5VhhSw2iVpAg3U/R3MrxiMTjdfFaO5kgZvDjikUiMuWGoEdRD94DnK6PsRe7eOc5533LfIEia RtmH19pDHIZTbHZvASW0iuFTxZZ4nBlEao2llYrPoL5ddBVXdPZ3yZ+Tm6d17S7fyGQynXXWHWeS 6l7ezY6U6kw1bLHT42OswGwMrin3du+raSqys0czspYxr4lllhU35F91+RJeceZfcf3J3O6tebJJ HtLOzexv5P3dYxsQEDRWrp487VedgxIrpGkMyAj9x/Zb3Hh5D5T9qPabaLO95Jijjvb++Tcdti/e m4yqCzlZryOT6a2XTHbqygGmo6yiOXfqLN/HTJ9ydYJ1p/MS+dm8d1zb9wk0exuzB2/uPY29aUVf mrtqZbH5rp3am3cVj8xCrRSVdROsVHCWdAjqkkavlS99vrnm/lpeXPvAc73m6G+jItrz6+W2uF1V aB0ksIIkSQVUuzBY1qRpIDKi50sPc+05H5tbmv7snt5Y7Ou3Sg3dj+7YLu1bTRLiN4tzuJpHiNGW NELSNRW1KWVjN5zCbK7H/mb7JyMW9ap94fHn4/5rKTbDG065qKnffFVkMHNnJN7fxP8Ah0dZU4jf FMkeO+z8zRxvL5SvpWSb2y2bmH7yOzXC7yx3bYNhkc23gNpBuWaMym416AxjuUAi8PUQC2ojAifb 7/fuV/un7/avsKDZOZuZIoxd/UJrItFSURC18PWVWS0kJm8TSCypoBybHPeQnWL3X//U3+PfuvdV g/KL5x5/pvuvefWmC3/8XNg4nrzp3aHY2Wm783FuXHbi3juXdWa3zCuzdjYvbGUiyFbLQ4HatLUT PDQ5CeJ8nDeEq6B/de6FTGfPnqjEYrbdP25h98da70TqjYvaPbeJOxt5bj2t0pT742vWbgxuK3/v jEYCXCYSvyNXjZaDHUlQYslka+SCmipTUyiEe690t6b5p9JVOK3JVhezqbcG19x7W2rWdcZDp3s7 Gdp1uZ35SZbI7DixPXuR2vS7kr6TeGKwNZV0lSIBTxU9JO1S9OYJ1j917oI9w/zD+p6DcHTs9HXt idjbw/06QdirvLbG7ML2PtHP9N1+1NmnYWP2AaNdx1+/sp2ZvKkxMeOho62arljljplkkUlfde6S vYf8wuo25vndm0ML1fu+mptsdv8Axl6qiyGe6/7ByGVy9f2/TPvTsHHUe1cJio8zJu7bHV8sFbi8 VAKmrq6h9Tx+NlT37r3QzP8APj4/ig2NPD/pNrcxvzJ9gYel2dQdTb8rN57ZruptxYja/aH9/dvQ YV6rZFDsHKZhf4lWZAw0cUcE7JK/iYe/de6z0Hz3+N2Qxm582ud3rQ4Tbuwa3tPHZnM9WdjYPGb+ 67x2Xw+3q3d3WNVlts0ab9xMWe3DQUqfw/yyztWwSQpJBNHK3uvdL/sP5V9NdZZvdG19xZbP1e7N rVnX2Ifae2dn7n3VuTcO4+0aTdWR2VtXZ+JwWLrqndG5MljNl5CrmpaQSNQ0cP3FUYYGEnv3Xui4 7g/mLdcHdHUqbEwu9937Q3ZVd+Um+6Wh6n7PrOydvVfRuH2r/GMdQ7Fp8FDm6Keh3Nu6Glr6ivpo 6OD7Spj8glTj3Xuj57I3lt7sXZe0ewdo1xym099bXwG8tsZNqaqomyO3tz4qkzeFrjR10NPW0hq8 bXRSeKaOOWPVpdVYED3XulR7917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6//V 3+PfuvdV29kfC7tPePZXyI3ht3vjr3bm2vkbRbXwm48BuH440+/dz7Z29tzYFLsB8dtbeOS7bxmM gqK2lNZWLNUYSeOKrrCTDIiBT7r3XDP/AMvTbWX6n7l6rpew6+Cl7Kz3QddtzJZjbce449s7c+OO z+r9sbA2juzF1uehTsXG1dX11LW5RmmxX3j5WVVSJ0Ez+690H8v8ufcqYSlOO7F6gxebyu/Ruzf+ zsN0Lkdr9IbvwlLtObbO1to5baeze2dudi7mouva7J5DL4189uvKwTZGtlL08cfhSD3XumLB/wAq fE4Ta+x6CDuOGDenU22sp/of3xhuraLAnr3tDLfITNd61XYuO21j96DFTUU1DU4/bMmFQ08LYiil C1CCoWKn917oxO3Ph/uKg7tl7P3H2bhs1tqD5FZ75JUe0aPYmQx+Srd4Z3oVujKWhzG4KrfWUo2x u0McRVYrw49JEOtJGdpPIvuvdBb1j8Udg5bc3yA2W/dGQ3puig6x7j6N7Nkodi5ba+X2pun5Y763 F8iN2blxu5q7MZDG1+SrNsb+wNPHT0T1Bphi4ZKip80pp4fde6h7j/l9dh772O2G3931trMbq2b1 Psvp3pauwHUE+19n7S2xs3sXrnsGvr927ZfsfO1+6c92C/VOHx2Uko8hiaSloBPHS048hPv3XukX 238d+5OtN8YnvWDP7y7b7rzfc+V7SXenV/SOIzO1tjJQ9DUvSmF63q+nc33Li8lk9sZfDZHKCgyy bgimxlZJFLXPJ/lFVP7r3S++Ovwp7E2vsJdzb+7DfE9zbz+Pvcmxdwz1G38duHI7S7P+QPam5u3N 679qc1jc/RUG4Kyjr8piaOWgpUpaeZsMHWrImBT3Xuju7fi2P8dOoetdn5vcNDids7HwXWPUODyV ZC9GuSyOnAdd7QxtHj4XrZ/vs7lZKWCCnjaZg8oGoqC3v3Xul1tfeGB3lT5iq2/PXVEGC3NuHZ+R krsJnMJpz21cnPh85BRrnMdjXylDTZGmkjjrqUTUNToLQTSL6vfuvdKb37r3XvfuvdBRs/vHqnf/ AGJ2Z1Ps/eNFnOwOnjt1exdv01HlYm28+6YchPh0GTq6Cnw2YkcYudKlaCoqjQzx+GqEMrKh917o V/fuvde9+691737r3SW2tvXa29RuFtq5mlzSbV3TmdlZ+SkWfxY7dO3nhizmGeWWKOOeqxVRMIpz EXSOYPGW1o6r7r3Sp9+691//1t/j37r3Xvfuvde9+691737r3Xvfuvde9+691TNtv48717K7spsj 2f132LRddbh+QHzV763tTfd5/ApnsThcbsf499GbWzstBV42sqo93bGpKzJ0WMSdYqjHoeJqaaov 7r3QBYj4v9wbj+PW/jvzr3uev3X138F+uev+mdlV2U3mJh3J2buXtDfddXQRUGQoZs9mulTm9sY9 PukmGKWhdGiR4Wv7r3Qv0vUvd2U7iqcfmNl97ZHvTFfLvZ2a2t31lczuOk6l2b8RevsxtaWOnw+V ps7R7Tr/APSFszb1XRZjbEUT5TKZfLSyZAvAkc3v3XuklW9UfJ3E9a9k0ua2J2Pk9v8Axx3L2h0t 0LQ4Ws3xJuzd2E7l7jy/95/kLHj9k1OP3zuXEdefH3cVFhcRQ4p/v6gnLrSzwyuksPuvdBttD407 2ytVSYvsLozsDKdT5v5u9JZGTbmJ6r3ttHC0XXu1+kNyVGS37S9a5rfu/s/tXA7n7By2MocrXVGX nqVp6ItXJS1aNTj3XunOn6m+QM3XmRwHa3TPyF3hvDdXx/xGW+NOK2fl9z43bXW/yH7j3t2n2D2P ubsfOYzcGOpNg722LujeWDaPI5sRCjxuOlggBcMj+690PVH8cu0MvuuDtPd+G7Gy3bWV+fXTtFT7 iWu3tRYjb/TfSGB2bgNzb8pcBBWUGIx2B7Rx/WmRp6nKT0xjyVLlqSK7BotXuvdWgd9bz3xsLqbe G4Osdl5PsHsn7CLEbB2rjaKWsjrd35+rgwuCrc46GOPH7UwlfXJXZaqlkjSDHU0zBtehW917qomn +Nnyj+NG4a93av7kXsv4nfIbq/cXYHx72Zn9s9mUPYlduuPtHEdi7uzm69+bgpc92Rl9w773JPha iA4qE1WqnjhQmnQe690hOuepu4Nvbdx2H3J0521U/HGt7v2onbFb11sztvrzsjuLY2y+n92Pg6/c Xx4zu+d0btwlDmO0cliqbc9ViWiOfSiWSSPwQCST3XumPtLof5LZrMU+1tv7E73666zqOtopfjz1 lFid0d4Uuyd9bx37vbO5erzG/wDbve3UOM6W3zs6myeLmx9duKTK0uHx3koaWd2o9Fd7r3RiKf41 9nZTcFJ2Fuuj7V3F2jP88+ksTQburqjeOOgwvTPR23th7d3L2PFtmgyy4HF0Xa2P61r4q7LNHPHX x5WmVncaCfde6Nx/Lu6vpesPj39tVddbi633ruXsPsvdHYGL3TjcpjsvWZ3M75z2Qx9Qpyp82QxV BtqroqGjq1VVqIKUOdbl3b3Xuj2+/de6/9ff49+691737r3Xvfuvde9+691737r3Xvfuvde9+691 737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3X// 2Q== --=_related 0006EE4748257DC7_= Content-Type: image/jpeg Content-ID: <_2_10DA2C9C10DA28C80006EE4548257DC7> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAAlAS0DAREA AhEBAxEB/8QAHQAAAQUAAwEAAAAAAAAAAAAABQAEBgcIAgMJAf/EAEEQAAEDAwMCBQIEAwQHCQAA AAECAwQFBhEABxIhMQgTFCJBFVEJFjJhI0KBF1JxkSQoM2JygrE4ZXaDkqGjs8H/xAAbAQEAAwEB AQEAAAAAAAAAAAAAAQIDBAUGB//EADoRAAEDAgMFBgMHBAIDAAAAAAEAAhEDIRIxQQQiUWFxBROB kbHwMqHBBhQjQtHh8RUWUmIzQ3KCwv/aAAwDAQACEQMRAD8A034lfGTcOyW57lsU2iU2oR0xGpIe kuLCyV8sjAOOmNfUdndkUtuod89xBBXmbVtT6Lw1oUf2f8c917kbmW/bcy3KXDiVF5Tbj7LjhUgB tShjJ/3dbbZ2LS2fZ3Vg42WdDbTVqYCFEnfxG7wRJkNItijLDa1IGHXPg/PXXc37PUTnUKy/qDry FK7K8dF0XZZ1+VddCpTL9u09iYyhtxZS4pb6WyleT0ABJ1wbT2JSo1aTG1CcRIPktae2udiLhYBQ p38R+9mkFRtyhjCScKccz2/x13/27RJ/5Fh/UH6Bbh2tuqVfG3luXDLaQzJqcJuU600TwSpQyQM/ Gvi9ppijWdTabAr2abzUaHLO90+MC5KD47qHsW1Rae5QahDbkrqSlL9SgqaWs4GeOMp+3zrnWq1J WqzDtyizqpU5SIVOhMrkSJLysIabSOSlE/AAB0RZO3d/ESty0rJ2yu60YJuK2rxrRpjlSeJbTCSh wJdCk9w5jKgD8DPzoisDfbxbUfYTdLa+06hT36oxe8hyOJUZXJcU8m0NL4/zJUpZBx9tEV/JWTn9 tEVVp3Vqo8SQ2/8ATx/o5ohqQfVnzS5yAwPjHUd/30RWfVJTsGmS5LDHqn2WVuNsc+HmKCSQnlg4 yemcayqv7tjnxMCVpTbjeGzElU/cviXiUCx7TuFuiLmqrgWtcREnBjIb6OqKuB5cT07DP3GuggNr tpE2IBJ4TEevHMLJsupOeBcEiOMT+nzUiuPd9VKr1ZptPpbFRTTKS3U1yX6k3EaKnHAlDRWscUgp PLmVY+MayJIbUJHwOa3z/ThrkrNh3dx+YF3gP1NuWalLd9UFLzEWVWqXFqTnlIMJc5ouBxxOUIAz klXxge7uNbObDyxt4JHlnblrw1WYduB7rSJ9n6p1CuuiVKrSKXErECVU4+S9CYlIW81ggHkgHIwS Acj51m3eGJtwru3SA6yhNr7xPXPGoT7dHjxm6jUpMBwPVRtCmg0SOaEqCS6Tj9KRkaimQ9tN5sHs LukadOJyGqVNw1B/i4N6zr+2uilsO/7YqEuNFi3HSJMqVnyGGZzS1vYJB4JCsq6pUOn2P21YAuMD 3r6I7d+K2ninKrroiK4miqrEBNYUMinmUj1B9vL/AGeeX6evbt11Dd6cN4R26AXWlC9zr3/s4sep XEIX1Eww3/o3m+Vz5OJR+rirGOWe3xqhcQ5rQJLjC0Y3GSORPkJUVoe8FcTd1Hod2WU7a/1gOCDK TU2piHFoSFFKuAHHp8/fHTuRq0NJc0mCBPgM78vek85duCoBLTAnrkpzTL1t6tPlmn16mT3g0Xy3 GmNuKDYPErwkn2g9M9s6qbAuOQz5a+l1rBDgzU2jmu6h3TRbnQ8ujVeBVkMkBxUGSh4IJ7BXEnGc Hv8AbUwYnRVkTCidY3jpMW6rao1LdhVwVaW7EefhzkK9GpCQr3JSFZJ+xKe2q0yKj4/LhLp0sJU1 Pw2FxzBaI6kj6KUt3hQXocSW3W6cuJLe9NGfTLbKHnckeWhWcKVkEcR16atBkDU3HTihtJOmfLrw XJ+66JFrLVIfrEBmrOgFuA5KQl9eeow2TyPY/HxqBvSBpn5T6X6Id0Am0/x6oVam51t3tV6rTaNU 2ZkmnL4OhC0+/tlSBnKkgkAqxjPYnRu/T7wZTH79Dpxg6I/cf3bs/duo14TxTfcfcdFhNUyPGpj9 crlVeMen0yOoILygMqKlnohCQRlWDjI+MkUkuf3bBJiegHu3GFaAGGo4wB6nIe/WAhdn7rzqpdf5 Zui2H7SrbzCpURtctEpmS2n9XFxAA5DqSn7Dv8a0GFzXEG7bnpx87freM3EsLZFnZHnw8r+xMpg3 3bVUmxocK4aVLlyUlTDDE1pbjoGclKQrKgOKu390/bQAmY09/UKzt34rJwq66IiuJoqqxATWFDIp 5lI9Qfby/wBnnl+nr27ddQ3enDeEdugF1pXW1elvv1L6c1XaY5UPMW16RExsu80DK08M5ykdSMdP nUAgjEMonw49OakjCYPuckzG5dpLp0+e1ctKkxIDfmynI0xt3yU9gVBJJ6noB3J6Dro4hrcZy/VS AXOwDP3Plqg9O3bp9xN2xJoaYtQg1iQthxbtQZYdjFKeWPKJJcX1GUJ9wBBOrhpxtY7VpdxyAMfQ kWBCzLhgLhoQPMkT9QMypO3dlDeraqM3WaeusIzyp6ZSDIGByOW88u3Xt21Vu8CW3j+PWys7dIDr T/Pomz1/2vGlemduSkNSfPVG8lc5oL80EBTeCrPIEjKe/UffRu/AbecuaO3ZLrQj+iKvdzLPskU2 rXVcluUupPQIi31yZkZK1cEJJCckdvjGurZ620B7aFNxElYvawNLnBYQ8Elpm/fEEqvKjhmBSUPV JTaE4QhbpKW0AfGApXT9tfddu1fu+xCn+Yx5Lx9jbjrOedFLfxCrIt6y1WcaDRYVIMlEtTxhspb8 wjgRnHfudcv2fq1Kwqd44mIVtuY1obAzVs7yWLbts+Dyr1Gk0WDTZ02iwPUyIzCULe97R9xHfqSd eVsVarW7Tax7iYJj5rp2hoGzSBoot4IbJsa49nZcm5aRRZ04VR9AcqKG1OBHFGB7uuO+untuptFP aQ2kTEDzWeyNpmnLlR34oF7X/Ze7G0ln7VXFVLcbq9NMaNT6LLVHaecVI4NjCSB8gDXyRcSTOeq9 cRFsli2s2D4iWfE1TaBUJtbVvEuOlcWQ5PJlhrgopw7noOIV86hFrP8AD3uHdK6PFHfm1u71yVmu x4tuzItQotWmqkNBZcZQroSRnitQz+50RUfVtt6/QtofELsx9NnVBdj3LDrNKWy0pYQFvGOpIwOh cacaVj546Ir/AKM5VfEJ+IHshRa1CfjSbBtSHLrEV1PvjSm2fNUlY+FB1xpJB+Roi9UGkjBP7576 Is9JAHjoJ+fymR/8o0RaK0zsUWYrM2eqtQvq86PVoD7VvQIk6LR3XmFJaV6pfLk2o9FYGckHI6A6 wa0/cnf5gBo54SXA+ceC2e4Damn8pJcf/ZoBHlPOya2xZV0Sdi9wJlXpE4XHUm2ITcMxnPPcajob bQQg+459x6DrgntrbajioNw3LnYj4uHpE9CsqAwVyDk1paOGRy628VM7L25M/cy8qnUqIUSEU+nI pc6dEPFt0RgFKaUofqSpKclPUEa0rgmnX7s7znvg8jMeBnxWdIgHZg8S0NuPEWI49VW+z22lxUy+ 7fZqMKs06bSZbjrz4tyOiOsZUFgz/NSt1KkqIGQrv0BAzq9FzZxCwwkQbaRlqQYjztcqKzXXaTMu BnPWczlz/Wyktn2lXIyNvPOo1Qa9LcdSfkc4rifJbVy4rXke1J+Ceh1xsBFKiOFF4PUgwOp4LWvc 141qNI5jj0Qi3Nqn4G11mTU2rJYudu6GnpL3oViWhkPK9y+nINhISevt7H5zrsaQ2ts8ZRf55/v0 Va++Nqm8zh+WXzyQlW19z/2jToc2NWWpTtcM5ipwrcjymiOYWhwzluoWgdOqM4GMYJONY7FuCkHZ tzmw53/MD4zlEqds3+8w5Oy16CNIy06wr88RFJm1zZ6vwqdDkT5joY4R4rSnHFYfbJwlIJOACf6a zLcVWloMQvwsbrakQCZ4H0K42tshTKBXIddmVu4bjqENpSYn12eZCYxWMKKBxGCR065H7ZAOprGK dQMFyCJ1i9vf1K46YL2MxWyMaTb0VZ23tDOc8Nk+NBoHorvneZ54fY9PLfbEnkWitQCglSEDAJwe n31euQ0UoEtbhJA118wT1ta662720VjOZcAeo05HyXXSrPn3fcNWm2nZtQsKALbfpzrU2P6Ey5K0 q8sJSP1YOP4h+3XHTUVWucysZkOiB0IJMZCRLYyvzdGVIhr6IIu3M8iIzzN7+HRC7Rt1527dsEQd uKrbj9HUtmrVJ6nltDznl45FYGVpyCeasfqwNaGKtV7mGGuY4AG18Jz4ZxObtbhZOaW0e7ddwcDP LF8+eggcU3odJuWNQrItJ6z662/Q7rblS6gYhMUt+cshSFjqpOCSVY4gAdeo1NFwfUo1DaGOBniR 78cpWm02btIF8ZkRwj15I4u2l0q6bkp1Y2wn3VWajXjPgVppPlMpYUtJRylp9zPDiTxH+BxnWWyj dpM+FzSZPzxf7Tw/+rKdouXuNw5oAHyjl1+l1L9mreRam5t+QnbXkwFSJjkmHVRTw3FMc8f4KHsf cg8R09p+RjVqFtlwZEOPiMh5Qek2zSvevjN5DecGL+fHjmiu79IrFNuy0b3pFKfrwoin2ZlOi9X1 MupCSttP8yk/3R1OR8ZIpTd3VVziN1wg8oMj1vwhWeO9pBgN2mRz4j5W+tghlMeq+6u6lAuFVtVW 26FbseThdajiPIkPuo4cUt5J4gdeWcd/nVHtwUq9Vx+JuEDpck+n63ilQ4w2kBrJPTID68uFppmw 7dXcll2hTqPZMxqvqrQnG6kxk+QGUPOcip8HKSOOPLOP0gjJIz2U7VqLvhDQC7mIy5zPh8OUptNz tLTcuJA5G3l+6dq2vuf+0adDmxqy1KdrhnMVOFbkeU0RzC0OGct1C0Dp1RnAxjBJxrDYtwUg7Nuc 2HO/5gfGcolTtm/3mHJ2WvQRpGWnWFZdo2Q7SoW6deVaDNSuJyrTzT0VOHkyGSn2hBUMqbXyWCEn Cu2dYgmnsdNrReLjXMZjOwEgcclqYftUk2hsdQDkdDpOmqhFsWXOuC6qhJNl1CjQalbEmKuPJorU SOJmQrihttPRIUAUF0lZ4j3HAxeo2KNdrTNgW8bHynOwvF9ZVKbpqUC4RDr8Ijzi9ybEyABcItZN Anu0radmNatUor9LqLyKkqRTFMfxPIA89XTqk5A5qxkpx8a6KsvrNLDA7t4HI4QPCTJHHPNc43aL muEnG09RiJ+Qz4IJSrCq3prftlqxqhAvSDWxLl3apgCOtoLUsrEodV5SR7PuPv01FAt7yi9owtYN 4cdCI1n9vhutNoBis07xed08NQeUe96yfVzatyo2bu5OetV+TXn6645TXlQVqkLa81JCmemSkgr6 p6Ed841zU5Zs+z4bOBvx0z9810SHbQ/F8OAdJwn5zC09TgtNPihwKDgaTyCu+cDOddVWO8dGUlcV AEUmA8B6LOfj0vv8q7Ju0lp0ol1+UiGAD1LQ97n/ALDH9de12Hs/f7WHf4rn21+Gnh4oR+H3Yf0H aifcT7fCRX5hW2SOvkN+xH9CeR1t9odo7zagwXDQs9gZFLGcyoB+JifdYv24TP8Ao3r0fs1/2+Cx 7QsGq3N/z/qUSj/3LA7f8TOvH7Pt2oOp+q6a99m8lifbHwyX3vJasit2u1EMBLy4p8+X5R8xKQT0 /qNfZbZ2lseyVO6rNkwLrxqNCrUbiYU48fchjbXxF+Fh64ZKIMahR4blQfzyS0lqWguLz8gcSdfm lZwqVXPbkV9OwFrACgV6+JPbaq/ig2zuTGuqI7ZUWmtMvVYZDSFhlxJSf6qH+eslZDNr7nn7l+Mz xOVvaqe5PqlWtmpPUCbT18XFulyNwU2r4OQdEVcUKzvGLTtwLio1MmXEzd8liPVqtHbmD1LyCPKa ec65PROOv20RDdv9nfFVSt3rrmW8muovlK2FXFJizQZSkvYcT5pzk8sZ/poi93aYXDT4/m584NpC wrvyx1z++iKgU/8AboV/4TP/ANo0RaFffbjMuPPOJaabSVrcWoJSlIGSST2A1BIaJOSkAkwFX9X3 9sek1mk04V2FOVUFqT6mHMYWxGCQDyeWXAEA56dycdtS3ecW5WmdOnVQ7dbi5gc+vQaqSUzcO1a1 LEWnXNR58kpUoMxZ7TiyAMk8UqJwACTobNLjkLnkguQ0ZnJAnt56E3YIvBMeoO0lUkRUBLAS44S7 5QWkKUAUE9Qc9v3BAsGkvpMNi+I5SJvw9xa6gkBtRwuGTPOIy45+qKUzcqhT6dUpkmSqitU2UYcz 6un0oZdyMAqUeJ5ApUME9FJ+TjVAQWNfo7LrqOouDzB4KxBD3M1F/A5HoUFlb+WRFueFRjXoLolM reFRamsKiNFOfYtzzPao/AI6576lu8XDKBPW8W5/RQ7dDTxMdLTfl9UTre69tUi0apccepMVyn00 J9QKQ+1IWkqUAB0UAD1+SOmqvdgAcRYmFZjcbi0G4E+v6JhP3YdpluO16TZtwN0lqP6tcjzIJw1x 5cuIlcu3xjOrVfwSQ+0GPGY9VWn+KAWXkT4RPoiFV3QpFHtu36y+1LUzXHY7MOO02FvqU8AU5SFf A6nBPbpnWjmFtcbPqSelsz05qgeDRdW0HuBzXG4d2rbtNEhyruVOBHjueU5Jdo03yArOBh0M8CCe xBIPxnWIIdAGuS1wm64Xpu1RbFpUifOi1h9plpDx9NSpBSUqxj+KpAbSeoyFLBHbv01LjhdhOcx7 4+EqGDvAHNyIn3+/omDG+VvyLiFGTBuASfRiby+hyj7CrjjgEFzv/Nw4f72emrx8X+pj3w8YPJUx Waf8vfj4Su2498LStet0mlzak2mRPXwWS62j0XtCgZKVrStrII7p/wAcaq2HPLJ430tmJGvDj5qx szHHC2t9Y4cUPq/iAoFMrL0BmBUqq23IiRRNp/p3WHFyUc2Qj+KFLBGeqUnsf21NMGo5rcpJF+WZ 5AZyoeQxhfnAxW4THnKs7UKUtES0RfCMgg9tVc0OBaciiF2xa9Ms2isUmjxvR09gqLbPmKXxKlFS uqiT1JJ760Li6J0t5Ibuc7UmT1RXVUS0RLREtES0RLREtEXnD+ILeirl3dh26y8TFoUIBaR2Dz3u Uf8AEJCf89foX2epd1s7qoElxhfP9oVMTw0K7tlPFxtzHj2dYFFhVVtwoYpsdTjGEFfHBJP2Jyc6 8DbuyNrpiptD4IXdR2qmcFJqgn4mHX8i/wDDM/6I16P2ZM96ByXP2jkxWzv6sHwUys+0fRoHX/ma 15XZ4ntUDm75SuquJ2VUJ4WfFbaGyG2kug12PUXpi6g7L5RWuaOCkoA6/f2693tbsitttbG2IiFx bJtLKNPCVb3iD8IdjePK3rOumpVSq0FbUQrhyIYSXFMOe7gtKgR366+GfTNF5pHSy9trsbZXnHdH gRteg+Ouh7EtXHVXaDUIbcpdSUhv1KVKaWsgDHHujHb51RWW6dqfBpYP4eLV3bxR7jr9ws02hPty IbrLZ5N8kL9vAZzlCR9hknRFUv4byL28RniU3D8RFwvSYdMdbXTIsVKyGXVKI4spB7oaQlP/ADKz oiBbpXzXfAV+IXULznJm1Tb/AHFw9KKcrVwUoBQT91Mr6hP91WB30ReqMWSmTHbdbB4OoStPJODg jIyNEWfQf9ejscG0z1/80aItCynHGYzzjTJkOoQVIaSoJKyB0SCegz266q4kNJaJPBWaAXAOMBZU o0quv7p3lMuOjvTa8gRmyKTUKoymG0pHMMhUJhzkAOOeeAVJJHLJOppANomDMuMm9yLZcBprGaiq SajZsMNha08+PHTgjFr1CdX6zubSJqrjRTW6QyW6XGmzZMlOUnkGfWNpc5L7dUfPTIwdUcMey1NT ibGXO2tuPJWacO0U4tuu9c9LjSNeahtft+tR9iJblw+qiSkBnhErNZVESwhBHlNMwW/YslDas+YG 1khRAOMnSq4NdTeYJBk6yTEiMgAHDIyBIMCAq0RONosIPK2hJzJJGogmIkyVPLM3FYt6yLyuSl0q 36dHhw21w34tD+nCcs5SglPqFOLR5nNAPFIJCsKyFAWrYmMhtyXAAcRxgakGRqBBi9s6DQ5zQdGk zzGk6wYB58LSco+y12PWLVqSL0ap8S4T6uTG+mOuORFOYU6224uSVcVZIVyyT17EnUVaTWgUJlrD bmAZA6Tf1JVqVUvP3gCC4DwMZ9f2iIRK/BItax6Pa1diQbujVidHo7LKXJFPSlJGUlxwuPuKwUDJ BB//AE8/eawYRcy6f/GD7vdGD7vSc8Gwgedj7i2igsatwK9Pj2iLXmuvSahOoq4ki9al6MCM0hSu uDlCgogJ4fA+/Ss9+3vDeW479Y85EqT+BIyjCLf7SmtYambq0uxZVAoVegIYRJp6mKa81IjQ4iOT LnFx9KB5y0gJSoqBAGep7zh72r3jzIe0EzzJsOp+KNNCFJ/CYaTc2OgdQAZPSd2ddQURuS3I0So0 O3LkYvCfPWpTNuimvxY7EYsgKDjQVKUorSP531E4OABgASHOqVC5p/EAmeUnTKDrMuMXMqsBlOD/ AMdhHMiBPMXy3ReBC+bnWkFVi2ZM+emoXnMhobmQ5tGTIL0dvkVKQ23FmJad5KHJQynocdNVGEVn hgtmeRgNBBjKQZHQc1Yz3TS43BIHSSTrcwRB4X4hRirWfT3XYTNZjs0ChyHhHmSVW+UOkLGEpac+ jMBtfLHUr1ZjRUqNYTnYaEnTXLiOCq5xYwvGmfADX9uaOXzajlRuTcVuK7VXYdIpsdqog1tqMJEY M+chtDYhOdU8CMlWTk9cKI1k6pipvrvFnPJ8QbHoJEdNSFqxkPpUmZ4YHQyD55n5ZBRVNRbp12/m CPJLtRiSaE9DpMktKXLS7ECFIShtCOS0JcHEoSAPt112UwRXaDeX1GnoYl3yvpfhZcj4+7SMmsBH VrzA8p52Wydc63S0RLREtES0RLREtES0RLREtES0RLRFQ26fg8snd68ZNzVJydDqUhKW3jEd4pcK BxSoj74AH9NetsvatfZaeBmQXHU2WnUOIoNaHgUsWybrpNwQZ1VVLpkhEllDr2UFSewI+2tto7b2 mvSdSdEFZ09ip0yCMwprvf4crc8QK6X+YJExj6YHEtekc4554zn/ANI1x7Ht1XYCe61XRW2dtcNL lKq7tpR7j25VY9QS4/RnISYKsq/icUgBKs/cYBzrmZtL2VxtI+KVqWBzMJyVDq/Dq284kfUqyBjG PPHb/LXv/wBxbUy4AXnnYKZMrRVl2vFsm1aXb0JS3IlMjojMrdOVFKRgE/vr5urVNeo6q7Mlek1o Y0AKpa14Q7XrniYpu+L9RqAuWBHSw3ESpIjkJQpAyMZ7KOqqVcF1W1AvS2KtQKo151NqkVyHJbz+ ptxJSof5E6Ihu2m21vbSWZS7UtanN0yiU5ryWGEd+/uUo/zKUepJ7nREJ3a2WtLemFSIV1UtuoN0 ue1VIiz0W080oKGD/dOACPkaIrAT8fb7aIqtRtyhXiL/ADt9QcDoopp/ofLHAjkDy5Zzn9tEVq6I gsWz6TBqVaqEeOtibWQgTX233Eqc4pKEkEK9hAPdGD899REM7sZST4nNTMvDzmLIfTdsrfpJqy4z M1MiqpQiZLXU5K5DoQMJHnKcK04Bx7VDpoQHM7s5TPv36lAYcH6gQmKdkLBTLjSfyjSS5HaLKAqM koKTjqpB9q1dP1KBV369dWm5dx92GQ8OmSroBw93Ovj1ShbJ2RBQtCLfYeSot4Epxx/yw2srQlHm KVwSFEninAOSCCNGktiNIPOQIF8zAsJRwDpnUEcoJk2yub9bqcahSgd1WVRL3YhsV2nN1JiJITKa ZeJ4BwAgFSQcKGCfarIOeo1EAOD9RPzUycJboUAb2MsNpxlQtmGttmS9LRHc5LYS46lKVnyiSjGE JwnGE4GANBYRyjwmfZzUG884+WXr46p5C2ltSn0yNTWqUVUqPzKKc9JediqKlFRK2VLKFnkcgqSc dMYwNSbxN4EXv7N88+aaki0mTFvYtlkm8nZm1pcuHKdZqipELl6Rz63OBjZGCGsPewYAGE4GABoJ BxTfjqepzKGCMMW4acrZW04J3P2rtWryKc/VKSisO09pbMdVVdcmYSo5PLzVK5nPYqyR8EaWxF0X IA8Bl/OZ1T8obNgSfP3lkuidsxYs9ttKrSpLBbcS6hyHFTHcCknI97YSrGfjOD86lpLXNe3MGQoc A5pYcjZdlX2js64KlVKhU7ehVCdUkJRIkSUFxeEo4DgSf4Z4/KOJ6A9xnVA0BuEZTPs5/RXxGQeH 85Ilblj0S0pEp+kwvSOyWmGXVeatfJDKPLaHuUcYT06d/nJ1oXEgg6knxOazDQIjQR4TKO6qrJaI loiWiJaIloiWiJaIloiWiJaIloi//9k= --=_related 0006EE4748257DC7_=-- From nobody Thu Jan 8 00:13:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5481ACC8A; Thu, 8 Jan 2015 00:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TViD_eAoxQFc; Thu, 8 Jan 2015 00:13:36 -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 8B7551ACC85; Thu, 8 Jan 2015 00:13:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 866CBA15; Thu, 8 Jan 2015 09:13:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id y8CYJrh1EAwj; Thu, 8 Jan 2015 09:13: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; Thu, 8 Jan 2015 09:13:33 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC0952002C; Thu, 8 Jan 2015 09:13:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oHSea5VhnhnM; Thu, 8 Jan 2015 09:13:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4595C20017; Thu, 8 Jan 2015 09:13:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B83A930518F7; Thu, 8 Jan 2015 09:13:34 +0100 (CET) Date: Thu, 8 Jan 2015 09:13:34 +0100 From: Juergen Schoenwaelder To: feng.chong33@zte.com.cn Message-ID: <20150108081334.GA15460@elstar.local> Mail-Followup-To: feng.chong33@zte.com.cn, netmod@ietf.org, netmod References: <20150107143343.GB13482@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UaWk0UIRR_7i3v0xqdFNqfEiSKw Cc: netmod , netmod@ietf.org Subject: Re: [netmod] =?utf-8?b?562U5aSNOiAgVlJGWSA6WTE2OiBtb2R1bGUgYWR2ZXJ0?= =?utf-8?q?isement_optimization?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 08:13:38 -0000 On Thu, Jan 08, 2015 at 09:08:00AM +0800, feng.chong33@zte.com.cn wrote: > Hi, > > Why not use draft-frank-netconf-conformanc-00 ? It's very similar > with Y16-03. > > http://datatracker.ietf.org/doc/draft-frank-netconf-conformance/ > No, this I-D is similar to Y16-02. During the discussions, we observed that it is not necessary to introduce a new RPC to retrieve the data - the standard NETCONF/RESTCONF operations are good enough to retrieve the data. Hence the motion to adopt Y16-03. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 8 00:25:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4231ACC8F for ; Thu, 8 Jan 2015 00:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s-tDEA4uzhE for ; Thu, 8 Jan 2015 00:25: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 0FC991ACC8C for ; Thu, 8 Jan 2015 00:25:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CED22753 for ; Thu, 8 Jan 2015 09:24:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CR5XK0ER2e_u for ; Thu, 8 Jan 2015 09:24:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 8 Jan 2015 09:24:59 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB5442002C for ; Thu, 8 Jan 2015 09:24:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zaNLZz_7SWbG; Thu, 8 Jan 2015 09:24: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 E972C20017; Thu, 8 Jan 2015 09:24:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A3D4D305194C; Thu, 8 Jan 2015 09:24:59 +0100 (CET) Date: Thu, 8 Jan 2015 09:24:59 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150108082459.GA15583@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mFV1vfZafrlDG960GWXxMNXr_5E Subject: [netmod] VRFY :Y59: restrict use of 64-bit numbers in XPath expressions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 08:25:02 -0000 The 2015-01-07 virtual interim meeting proposal is to adopt Y59-01. Please speak up by Thursday 2015-01-15 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 8 00:39:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A351A8971 for ; Thu, 8 Jan 2015 00:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OokE5i2IHPDo for ; Thu, 8 Jan 2015 00:39:01 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B49601A6FF2 for ; Thu, 8 Jan 2015 00:39:00 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5374D1CC000F; Thu, 8 Jan 2015 09:39:06 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: <20150106212118.GB11692@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 08 Jan 2015 09:38:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BzWO6-iiR0pcq7vq_Imhj4dRZRg Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 08:39:03 -0000 Kent Watsen writes: >> - who believes a mechanism to define metadata annotations >> should be standardized > > > Not yet. > > First I think we need to clear the way for attributes to be used safely. > We used attributes in and also with-defaults, but in both > cases the client either accepted the contract of the protocol (base:1.1) > or explicitly opted into receiving the attributes (report-all-tagged). > Specifically, what happens to a legacy client if the attribute MUST be > semantically understood (e.g., the enabled/inactive) in order to correctly > process the data? Even if we don't care about the client, we might > want You are right but I think we have two separate issues here: 1. Annotations are defined via an extension, and that by definition means the client is free to ignore them. 2. The existing sentiment of letting a (legacy) client pick only a subset of modules from those advertised by the server means that the client in any case cannot be expected to support an annotation that is defined in a YANG module. As for #1, it would help to make "annotation" a built-in statement, and that was actually one of the questions I asked earlier: http://www.ietf.org/mail-archive/web/netmod/current/msg11391.html #2 could probably be addressed as a part of conformance statements. > to assert that the client will always echo back any attributes it receives > on config=true nodes - this might require a base:1.2 for NETCONF, I'm not > sure how to do this for RESTCONF. Perhaps I'm conflating what and how, > but it seems that we're skipping a step. I am not sure how the client could echo the attributes. In NETCONF, it would probably suffice that the client indicate support for particular annotations in its hello message - then the server knows it can use it. > > > > >> - who plans to use the proposed annotation extension statement > > As proposed, I don't see how it can be used. > > Specially, I'd need to see more examples around how to declare where > attributes can be used. For instance, how to specify that the "default" > and "enabled" parameter can only appear on config=true nodes or a > "last-sampled-timesamp" can show up only on specific config=false nodes? > Or that a "timestamp" or "Etag" attribute MUST be on top-level config node > and MAY be on other config nodes (yes, I know that RESTCONF uses HTTP > headers for this, but a similar mechanic may be desired for NETCONF). Any constraints can be specified in the description that is a part of annotation's definition. > > Note that as long as attributes are cross-cutting (applying to all config > nodes generically), then they'll likely only be used for "metadata". But, > if we introduce the ability for attributes to be used on specific nodes > (top-level node, or specific config=false node), then we open the door to > attributes being used for regular data (not just metadata), which I don't > think we want... Right. If an annotation is only intended for specific nodes, then the data modeller should consider making it a regular data node. Lada > > >> - who is willing to review the document during the WG phase > > I will, if it is promoted to a WG item. > > > > > Thanks, > Kent > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 00:47:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0FC1A8971 for ; Thu, 8 Jan 2015 00:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAD53oHMujGv for ; Thu, 8 Jan 2015 00:47:45 -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 AFA8A1A6FF2 for ; Thu, 8 Jan 2015 00:47:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7A2F4A5F for ; Thu, 8 Jan 2015 09:47:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VDQ4DdzjL-zK for ; Thu, 8 Jan 2015 09:47:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 8 Jan 2015 09:47:42 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 622D020037 for ; Thu, 8 Jan 2015 09:47:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mV-uvE89ZWGs; Thu, 8 Jan 2015 09:47:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0757020035; Thu, 8 Jan 2015 09:47:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C1F7030519FF; Thu, 8 Jan 2015 09:47:41 +0100 (CET) Date: Thu, 8 Jan 2015 09:47:41 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150108084741.GA15728@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BMWggEiPmqZRdCEJ3Nzlj8H-R_Q Subject: [netmod] minutes of the NETMOD 2015-01-07 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 08:47:46 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2015-01-07 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2015-01-07-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 10th YANG 1.1 Virtual Interim Wednesday, January 97, 2015, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants AB = Andy Bierman BC = Benoit Claise JS = Juergen Schoenwaelder DR = David Reid EV = Eric Voit IB = Ignas Bagdonas KW = Kent Watsen LL = Ladislav Lhotka * Pending Actions - Y18 fix "when" expression context problem Pending action MB... - Y25 make enum numbering purely informative and optional JS to start a thread on the mailing list. There once was rough consensus for Y25-01 - we need to check what happens on the list. - Y57 non-unique leaf-list There was an action item for BL on 2014-10-15. Discuss today? - Y45 better conformance mechanism List of conformance use cases (action MB) * Y07 do not allow when or if-feature on keys This issue is in the REVIEW state but there was quite some discussion on the mailing list. Where are we with this one? LL: It was legal to have if-feature on a key in YANG 1.0, even though it may not be too useful. AB: Since YANG 1.0 does not have optional keys, the server is going to reject this unless the expressions do match the parent (in which case the if-feature or when statement is redundant but not harmful). AB: The only valid if-feature/when must be redundant. JS: Should we add text to the guidelines about this so that tools are encouraged to flag this? AB: I agree. JS to followup on the mailing list thread, trying to summarize what was discussed today and to force a resolution of this issue. * Y59 restrict use of 64-bit numbers in XPath expressions Moved to open, quite some discussion recently on the mailing list. Where are we with this one? LL: I updated the text in the issues file just a few minutes before the meeting. JS: This is SVN revision 104. AB: The text is fine. Proposal: Adopt Y59-01 * Y45 better conformance mechanism How to resolve this? Do we need to collect the requirements a solution must satisfy? It sometimes feels like going in circles on this. Skipped since MB was not joining the meeting. * AOB LL: What about a structure statement as part of YANG 1.1? KW: May not work since RESTCONF won't wait for YANG 1.1. LL: It may be OK to use it in RESTCONF as an extension but there should be an 'official' solution. AB: It is not a step forward to use three different schema languages (YANG, XSD, something for JSON) in RESTCONF. JS: What is the benefit of having this extension rolled into YANG 1.1? JS: We should encourage using YANG extensions where possible. If a "structure" YANG extension that works with YANG 1.0 and 1.1 can be written today, then I do not see an urgent need to make this part of YANG itself. A team of people (AB, KW, MB?, LL?) will produce an initial I-D defining such a YANG extension. Once such an I-D is available, JS will work with the NETCONF chairs and Benoit Claise to (a) determine whether there is support for this approach in the community and to (b) determine how this can be best handled process wise (that is which of the two WGs can host this work). --DocE+STaALJfprDB-- From nobody Thu Jan 8 01:22:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4021A9135 for ; Thu, 8 Jan 2015 01:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT-kl2AXQBvv for ; Thu, 8 Jan 2015 01:22:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 075361A897B for ; Thu, 8 Jan 2015 01:22:00 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E5A21280056; Thu, 8 Jan 2015 10:21:57 +0100 (CET) Date: Thu, 08 Jan 2015 10:21:57 +0100 (CET) Message-Id: <20150108.102157.2289650364805875177.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150107143216.GA13482@elstar.local> References: <20150107143216.GA13482@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jpgcw_weHGZEz_mE5zSzfDJuqWI Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 09:22:10 -0000 Hi, Juergen Schoenwaelder wrote: > The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. The reasons for proposing Y09-03 (instead of Y09-02) were: 1. The instance-identifier syntax proposed in Y09-02 doesn't work, b/c empty strings and 0-values integers would also return "true" in the expression "not(key)". But this turned out to be a false claim; the syntax proposed in Y09-02 is correct. 2. Y09-02 is tricky to implement in "common databases", since they require values for all keys. But the idea for how to handle Y09-03 in these databases was to store additional info that the default value is set. The same technique can be used to handle purely optional keys. Thus, I prefer Y09-02. /martin From nobody Thu Jan 8 01:37:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689031A8996 for ; Thu, 8 Jan 2015 01:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8cuxEtp9swE for ; Thu, 8 Jan 2015 01:37:29 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 86BAC1A8968 for ; Thu, 8 Jan 2015 01:37:29 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CDD371280056; Thu, 8 Jan 2015 10:37:28 +0100 (CET) Date: Thu, 08 Jan 2015 10:37:28 +0100 (CET) Message-Id: <20150108.103728.1499085884469962335.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150107145943.GE13482@elstar.local> References: <20150107145943.GE13482@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6jgnuTboc2UW_W9g3gGCaHWnNVk Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 09:37:33 -0000 Hi, Juergen Schoenwaelder wrote: > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. I don't think Y34-04 is sufficient. If I understand Y34-04 (add 'root) correctly, the difference between it and Y34-02 (add 'anydata') is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as 'anydata' with the constraint that it only can hande top-level nodes. As an example of why this is not sufficient, YANG PATCH uses anyxml with non-top-level nodes. It would not be possible to use 'root' in this case. 'anydata' would be a better match. /martin From nobody Thu Jan 8 01:38:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEC51ACCE5 for ; Thu, 8 Jan 2015 01:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0knW0DP8k0nm for ; Thu, 8 Jan 2015 01:38:52 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 764ED1A8968 for ; Thu, 8 Jan 2015 01:38:52 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C3A111CC000F for ; Thu, 8 Jan 2015 10:38:59 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 08 Jan 2015 10:38:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BK9GY-_r9RjzvdRzoH8nUgcWUSc Subject: [netmod] if-feature on identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 09:38:54 -0000 Hi, some routing folks came up with the idea that it would be useful to allow if-feature on identities (the discussion was related to crypto-algorithms). What's behind it is the same issue we have with the iana-interface-type module: a server advertising that module should in fact be prepared to receive all kinds of weird interface types. This is not only annoying but it could also have security implications. In my view, this is exactly the problem that identities (as opposed to enumerations) are able to avoid. If an identity for an interface type (or crypto-algorithm or whatever) was always defined in the same module as config and state data for that interface type, all would be fine. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 01:51:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3959F1ACCF4 for ; Thu, 8 Jan 2015 01:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgyKQDOy-XNW for ; Thu, 8 Jan 2015 01:51:41 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 10E231A19F0 for ; Thu, 8 Jan 2015 01:51:41 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 7DD8A1CC000F; Thu, 8 Jan 2015 10:51:48 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 08 Jan 2015 10:51:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ceLg6zDGZGsoeQmChuyfOrGdQf8 Subject: Re: [netmod] Y45: conformance-stmt proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 09:51:43 -0000 Andy Bierman writes: > Hi, > > I hope we can resolve this issue on the mailing list, since > it was skipped in the interim meeting. > > IMO import-by-revision is fatally flawed. > The problem with representing the conformance dependency chain > in the import-stmt is that not every module is using import-by-revision, > and if A.1 imports B.1 and B.1 imports C.any, then the dependency > chain for module A.1 is not deterministic. > > import-by-revision everywhere is going to be unmanageable, > even if all the effort to update every YANG module in existence > was made. Why is it necessary to do such updates? If module A imports B@2014-01-08, then it can continue using definitions from that particular revision of B forever, even if B is updated. > > Instead, a conformance-stmt much simpler than the SMIv2 > MODULE-COMPLIANCE macro is needed: > > module foo { > ... > import ietf-yang-types { prefix yang; } > import ietf-inet-types { prefix inet; } > import ietf-interfaces { prefix if; } > > revision 2014-01-05; > .... > > conformance 2014-01-05 { > module ietf-inet-types@2013-07-15; > module ietf-yang-types@2013-07-15; > module ietf-interfaces@2014-05-08; > } > } > I don't understand: how is this different from the case when the revisions of imported modules are specified directly in import statements? Lada > > Tools can generate this stmt or can be fairly easily generated by hand. > Import-by-revision would no longer be used. > > There would be 1 or more conformance-stmts in descending > date order, like the revision-stmt history. > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 02:05:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A1B1ACD01 for ; Thu, 8 Jan 2015 02:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qviLOiaTqaP for ; Thu, 8 Jan 2015 02:05:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8F61ACCFF for ; Thu, 8 Jan 2015 02:05:55 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 9ADC21280056; Thu, 8 Jan 2015 11:05:54 +0100 (CET) Date: Thu, 08 Jan 2015 11:05:54 +0100 (CET) Message-Id: <20150108.110554.937715174693668373.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20150106212118.GB11692@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PBXanscTHMDxZuhESCUmY2bk1Uk Cc: netmod@ietf.org Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 10:05:57 -0000 Kent Watsen wrote: > > > > - who believes a mechanism to define metadata annotations > > should be standardized > > > Not yet. > > First I think we need to clear the way for attributes to be used safely. > We used attributes in and also with-defaults, but in both > cases the client either accepted the contract of the protocol (base:1.1) > or explicitly opted into receiving the attributes (report-all-tagged). > Specifically, what happens to a legacy client if the attribute MUST be > semantically understood (e.g., the enabled/inactive) in order to correctly > process the data? Note that the draft just defines the mechanism to specify the *syntax* of meta data, not the semantics. In the specific case of inactive, lots of works on the semantics is needed, but that needs to happen in a separate document. (I think that a client needs to send "with-inactive" in the get-config/get in order to signal to the server that it wants to receive the inactive nodes). /martin From nobody Thu Jan 8 02:12:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C2B1A89A8 for ; Thu, 8 Jan 2015 02:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwbOQOdpLW9l for ; Thu, 8 Jan 2015 02:12:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5514E1A89A7 for ; Thu, 8 Jan 2015 02:12:11 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 99F3212809D5; Thu, 8 Jan 2015 11:12:10 +0100 (CET) Date: Thu, 08 Jan 2015 11:12:10 +0100 (CET) Message-Id: <20150108.111210.390242656752383270.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/l4M-rtA21Er2j6eQvVsUkVvwea0 Cc: netmod@ietf.org Subject: Re: [netmod] if-feature on identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 10:12:13 -0000 Ladislav Lhotka wrote: > Hi, > > some routing folks came up with the idea that it would be useful to allow > if-feature on identities (the discussion was related to > crypto-algorithms). This is part of Y11, already in the current draft for yang-1.1. > What's behind it is the same issue we have with the iana-interface-type > module: a server advertising that module should in fact be prepared to > receive all kinds of weird interface types. Receive yes, but that is not the same thing as accept. > In my view, this is exactly the problem that identities (as opposed to > enumerations) are able to avoid. If an identity for an interface type > (or crypto-algorithm or whatever) was always defined in the same module > as config and state data for that interface type, all would be fine. Agreed. /martin From nobody Thu Jan 8 02:22:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108D41ACD00 for ; Thu, 8 Jan 2015 02:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOH6ulLNwE8C for ; Thu, 8 Jan 2015 02:22:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6371C1A89A3 for ; Thu, 8 Jan 2015 02:22:47 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 651C81411DA; Thu, 8 Jan 2015 11:22:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420712565; bh=fyGEL5P9bIM3jbJ8kzzyMWm7H2OkfCtGA/KLsIWrWyY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Oj4wp1dTylC1UypcGLVRUrFl+P/ZIyhGZ8U4ZcWzTojkJDmaGcDfOwaUJTqpm3u/F R5FFuutPQgYLNFKhYGh0kOdhxfOtJHmfm9BFfljoja3eBCIOQTc5TPfuto8Ft4+8C7 j6xj8Bw5UJMQf/cjkqliFYTVeLU8yDc4jscCSPlY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150108.102157.2289650364805875177.mbj@tail-f.com> Date: Thu, 8 Jan 2015 11:22:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0CD84218-D27C-4DB2-8E4A-8D9D651BE308@nic.cz> References: <20150107143216.GA13482@elstar.local> <20150108.102157.2289650364805875177.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yEn-iFbFZeKDeV-Th8oClFbAjpo Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 10:22:51 -0000 > On 08 Jan 2015, at 10:21, Martin Bjorklund wrote: >=20 > Hi, >=20 > Juergen Schoenwaelder wrote: >> The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. >=20 > The reasons for proposing Y09-03 (instead of Y09-02) were: >=20 > 1. The instance-identifier syntax proposed in Y09-02 doesn't work, > b/c empty strings and 0-values integers would also return "true" > in the expression "not(key)". >=20 > But this turned out to be a false claim; the syntax proposed in > Y09-02 is correct. >=20 > 2. Y09-02 is tricky to implement in "common databases", since they > require values for all keys. In some common databases (e.g. mongodb) a declaration of a key is just = an instruction for the server to generate an index. I think it is more a = limitation of NETCONF=E2=80=99s edit-config design. An implication for both Y09-02 and Y09-03 is that if a key is not set at = the time a list entry is created, it cannot be set afterwards.=20 >=20 > But the idea for how to handle Y09-03 in these databases was to > store additional info that the default value is set. The same > technique can be used to handle purely optional keys. >=20 > Thus, I prefer Y09-02. Me too, Lada >=20 >=20 > /martin >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 02:45:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0BE1ACD02 for ; Thu, 8 Jan 2015 02:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTuDozbOdmYE for ; Thu, 8 Jan 2015 02:45:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA7D1A89AD for ; Thu, 8 Jan 2015 02:45:43 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 22CC4140264; Thu, 8 Jan 2015 11:45:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420713942; bh=4zuVkHWVdBpaGkO4kIt9I6QeCyQYFvv6+VTaJRxTMho=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tRQ6/muu8d9FenIfBARl7YeCVfj7N/3uYml7XgJSSzHjoo1Y++tHvL7g8ObdXTt4A Rx0jTiPD2X9brcrNuLfy2UjFIRxqaffEVkJ+P9DI6SKWkIHdSKizLhFhFo3q7T3hBy XKMAK+hV4C66Ct6BtHgNbq9632Ruj83II0QlnxHU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150108.111210.390242656752383270.mbj@tail-f.com> Date: Thu, 8 Jan 2015 11:45:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A541DEE-9A15-4F93-AC9F-94C50085967D@nic.cz> References: <20150108.111210.390242656752383270.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] if-feature on identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 10:45:44 -0000 > On 08 Jan 2015, at 11:12, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> some routing folks came up with the idea that it would be useful to = allow >> if-feature on identities (the discussion was related to >> crypto-algorithms). >=20 > This is part of Y11, already in the current draft for yang-1.1. Oh, I didn=E2=80=99t realize (or forgot) that Y11 includes identities, = too. But then I think it would be a real nuisance to define a feature = for each interface type along with the identity itself and putting = if-feature in all identity definitions. Also, a server would have to separately advertise support for the = identity value on one hand, and for the data corresponding to that = interface type on the other. We had that discussion before but I still think iana-interface-type has = more drawbacks than benefits. >=20 >> What's behind it is the same issue we have with the = iana-interface-type >> module: a server advertising that module should in fact be prepared = to >> receive all kinds of weird interface types. >=20 > Receive yes, but that is not the same thing as accept. Yes, but an implementor has to keep that in mind. Lada >=20 >=20 >> In my view, this is exactly the problem that identities (as opposed = to >> enumerations) are able to avoid. If an identity for an interface type >> (or crypto-algorithm or whatever) was always defined in the same = module >> as config and state data for that interface type, all would be fine. >=20 > Agreed. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 03:44:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300F11A8990 for ; Thu, 8 Jan 2015 03:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTMdVGPA-atg for ; Thu, 8 Jan 2015 03:43:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BFC1A0368 for ; Thu, 8 Jan 2015 03:43:57 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 48880140B0A; Thu, 8 Jan 2015 12:43:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420717436; bh=ZFa6ksp6uHJoS+zBOombKgTFW/Pd+hwf8Q+LkuVJ6hw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TfeH+/tjXxwzlffazuR5RAVzAzYoCQC6PJohvkkMUtSWVO4WJpOvqSTl+D2j7ZOTk w7QxfaqVpibFLJXOvuDic4ghuvC9k5Q9VeX8i+q6B5tJ/fjmOxUuE5UFZ3clfBY7Vb VQF8hkPtiT7KV5fsZZ3qP+gOiA/WoE12ki5lrTdk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150108.110554.937715174693668373.mbj@tail-f.com> Date: Thu, 8 Jan 2015 12:43:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <295BFBE7-CA6E-4CF4-B6C3-95FD874A1B80@nic.cz> References: <20150106212118.GB11692@elstar.local> <20150108.110554.937715174693668373.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:44:00 -0000 > On 08 Jan 2015, at 11:05, Martin Bjorklund wrote: >=20 > Kent Watsen wrote: >>=20 >>=20 >>> - who believes a mechanism to define metadata annotations >>> should be standardized >>=20 >>=20 >> Not yet. =20 >>=20 >> First I think we need to clear the way for attributes to be used = safely. >> We used attributes in and also with-defaults, but in = both >> cases the client either accepted the contract of the protocol = (base:1.1) >> or explicitly opted into receiving the attributes = (report-all-tagged). >> Specifically, what happens to a legacy client if the attribute MUST = be >> semantically understood (e.g., the enabled/inactive) in order to = correctly >> process the data? >=20 > Note that the draft just defines the mechanism to specify the *syntax* > of meta data, not the semantics. In the specific case of inactive, > lots of works on the semantics is needed, but that needs to happen in > a separate document. (I think that a client needs to send > "with-inactive" in the get-config/get in order to signal to the server > that it wants to receive the inactive nodes). Hmm, but what happens if an old client creates data inside a subtree = that is tagged as inactive? For some annotations including this one the semantics will have to be = =E2=80=9Ceither you support it, or go away." Lada >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 03:53:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CBD1ACD1A for ; Thu, 8 Jan 2015 03:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phhZcoqvnNdF for ; Thu, 8 Jan 2015 03:53:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFD41ACD05 for ; Thu, 8 Jan 2015 03:53:37 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 2D7481280056; Thu, 8 Jan 2015 12:53:36 +0100 (CET) Date: Thu, 08 Jan 2015 12:53:36 +0100 (CET) Message-Id: <20150108.125336.1998913946492695859.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <295BFBE7-CA6E-4CF4-B6C3-95FD874A1B80@nic.cz> References: <20150108.110554.937715174693668373.mbj@tail-f.com> <295BFBE7-CA6E-4CF4-B6C3-95FD874A1B80@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:53:39 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDggSmFu IDIwMTUsIGF0IDExOjA1LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+ PiANCj4gPj4gDQo+ID4+PiAtIHdobyBiZWxpZXZlcyBhIG1lY2hhbmlzbSB0byBkZWZpbmUgbWV0 YWRhdGEgYW5ub3RhdGlvbnMNCj4gPj4+ICAgc2hvdWxkIGJlIHN0YW5kYXJkaXplZA0KPiA+PiAN Cj4gPj4gDQo+ID4+IE5vdCB5ZXQuICANCj4gPj4gDQo+ID4+IEZpcnN0IEkgdGhpbmsgd2UgbmVl ZCB0byBjbGVhciB0aGUgd2F5IGZvciBhdHRyaWJ1dGVzIHRvIGJlIHVzZWQNCj4gPj4gc2FmZWx5 Lg0KPiA+PiBXZSB1c2VkIGF0dHJpYnV0ZXMgaW4gPGVkaXQtY29uZmlnPiBhbmQgYWxzbyB3aXRo LWRlZmF1bHRzLCBidXQgaW4NCj4gPj4gYm90aA0KPiA+PiBjYXNlcyB0aGUgY2xpZW50IGVpdGhl ciBhY2NlcHRlZCB0aGUgY29udHJhY3Qgb2YgdGhlIHByb3RvY29sDQo+ID4+IChiYXNlOjEuMSkN Cj4gPj4gb3IgZXhwbGljaXRseSBvcHRlZCBpbnRvIHJlY2VpdmluZyB0aGUgYXR0cmlidXRlcyAo cmVwb3J0LWFsbC10YWdnZWQpLg0KPiA+PiBTcGVjaWZpY2FsbHksIHdoYXQgaGFwcGVucyB0byBh IGxlZ2FjeSBjbGllbnQgaWYgdGhlIGF0dHJpYnV0ZSBNVVNUIGJlDQo+ID4+IHNlbWFudGljYWxs eSB1bmRlcnN0b29kIChlLmcuLCB0aGUgZW5hYmxlZC9pbmFjdGl2ZSkgaW4gb3JkZXIgdG8NCj4g Pj4gY29ycmVjdGx5DQo+ID4+IHByb2Nlc3MgdGhlIGRhdGE/DQo+ID4gDQo+ID4gTm90ZSB0aGF0 IHRoZSBkcmFmdCBqdXN0IGRlZmluZXMgdGhlIG1lY2hhbmlzbSB0byBzcGVjaWZ5IHRoZSAqc3lu dGF4Kg0KPiA+IG9mIG1ldGEgZGF0YSwgbm90IHRoZSBzZW1hbnRpY3MuICBJbiB0aGUgc3BlY2lm aWMgY2FzZSBvZiBpbmFjdGl2ZSwNCj4gPiBsb3RzIG9mIHdvcmtzIG9uIHRoZSBzZW1hbnRpY3Mg aXMgbmVlZGVkLCBidXQgdGhhdCBuZWVkcyB0byBoYXBwZW4gaW4NCj4gPiBhIHNlcGFyYXRlIGRv Y3VtZW50LiAgKEkgdGhpbmsgdGhhdCBhIGNsaWVudCBuZWVkcyB0byBzZW5kDQo+ID4gIndpdGgt aW5hY3RpdmUiIGluIHRoZSBnZXQtY29uZmlnL2dldCBpbiBvcmRlciB0byBzaWduYWwgdG8gdGhl IHNlcnZlcg0KPiA+IHRoYXQgaXQgd2FudHMgdG8gcmVjZWl2ZSB0aGUgaW5hY3RpdmUgbm9kZXMp Lg0KPiANCj4gSG1tLCBidXQgd2hhdCBoYXBwZW5zIGlmIGFuIG9sZCBjbGllbnQgY3JlYXRlcyBk YXRhIGluc2lkZSBhIHN1YnRyZWUNCj4gdGhhdCBpcyB0YWdnZWQgYXMgaW5hY3RpdmU/DQoNCkFu IG9sZCBjbGllbnQgdGhhdCBkb2Vzbid0IHNlbmQgd2l0aC1pbmFjdGl2ZSB3aWxsIG5vdCByZWNl aXZlDQppbmFjdGl2ZSBkYXRhLCBzbyBpdCB3b24ndCBrbm93IHRoYXQgaXQgaXMgdGhlcmUuDQoN CkFsc28sIHdpdGgtaW5hY3RpdmUgaXMgbmVlZGVkIGluIGVkaXQtY29uZmlnL2NvcHktY29uZmln Lg0KDQo+IEZvciBzb21lIGFubm90YXRpb25zIGluY2x1ZGluZyB0aGlzIG9uZSB0aGUgc2VtYW50 aWNzIHdpbGwgaGF2ZSB0byBiZQ0KPiDigJxlaXRoZXIgeW91IHN1cHBvcnQgaXQsIG9yIGdvIGF3 YXkuIg0KDQpOb3QgZm9yIHRoaXMgb25lLCBidXQgKm1heWJlKiBmb3Igc29tZSBvdGhlciA7KQ0K DQoNCi9tYXJ0aW4NCg== From nobody Thu Jan 8 04:09:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C751ACD18 for ; Thu, 8 Jan 2015 04:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UbWP792zaKa for ; Thu, 8 Jan 2015 04:08:17 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B99061ACD37 for ; Thu, 8 Jan 2015 04:08:01 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DC0331CC003F; Thu, 8 Jan 2015 13:08:07 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150108.125336.1998913946492695859.mbj@tail-f.com> References: <20150108.110554.937715174693668373.mbj@tail-f.com> <295BFBE7-CA6E-4CF4-B6C3-95FD874A1B80@nic.cz> <20150108.125336.1998913946492695859.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 08 Jan 2015 13:07:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 12:08:51 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >>=20 >> > On 08 Jan 2015, at 11:05, Martin Bjorklund wrote: >> >=20 >> > Kent Watsen wrote: >> >>=20 >> >>=20 >> >>> - who believes a mechanism to define metadata annotations >> >>> should be standardized >> >>=20 >> >>=20 >> >> Not yet.=20=20 >> >>=20 >> >> First I think we need to clear the way for attributes to be used >> >> safely. >> >> We used attributes in and also with-defaults, but in >> >> both >> >> cases the client either accepted the contract of the protocol >> >> (base:1.1) >> >> or explicitly opted into receiving the attributes (report-all-tagged). >> >> Specifically, what happens to a legacy client if the attribute MUST be >> >> semantically understood (e.g., the enabled/inactive) in order to >> >> correctly >> >> process the data? >> >=20 >> > Note that the draft just defines the mechanism to specify the *syntax* >> > of meta data, not the semantics. In the specific case of inactive, >> > lots of works on the semantics is needed, but that needs to happen in >> > a separate document. (I think that a client needs to send >> > "with-inactive" in the get-config/get in order to signal to the server >> > that it wants to receive the inactive nodes). >>=20 >> Hmm, but what happens if an old client creates data inside a subtree >> that is tagged as inactive? > > An old client that doesn't send with-inactive will not receive > inactive data, so it won't know that it is there. Right, so it may think it can create its own (active) data there. > > Also, with-inactive is needed in edit-config/copy-config. An old client that doesn't know about with-inactive can't put it there. Lada > >> For some annotations including this one the semantics will have to be >> =E2=80=9Ceither you support it, or go away." > > Not for this one, but *maybe* for some other ;) > > > /martin --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 07:27:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B4A1A6EE0 for ; Thu, 8 Jan 2015 07:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5i0D839W_6k for ; Thu, 8 Jan 2015 07:27:05 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C351A8A8B for ; Thu, 8 Jan 2015 07:27:03 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id EFCEB140264; Thu, 8 Jan 2015 16:27:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420730822; bh=Tm6P0jGy5uEuj8TXimm0CmDlnr9Va7/mZPixd0JtZzY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=glmfw7mK4IHfbRK6Qfj+soxSbLoA+ew+ANimW1BAvd5a4tcqkgXxi6HzKt2ClUVaS DzbtW11oOZRcHoO60Wd8aTjEhx+kSGwKDrWl7DdKdmgXNd+faMwcNJWwdkSPQsdpVa jncdeXBdLJHIeEXWp2brPEptkbAS6C1G77M1f9Bc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 8 Jan 2015 16:27:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82AC7222-94EC-4773-AD5E-8E08B40F6B13@nic.cz> References: <20150107143216.GA13482@elstar.local> <20150108.102157.2289650364805875177.mbj@tail-f.com> <0CD84218-D27C-4DB2-8E4A-8D9D651BE308@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:27:08 -0000 > On 08 Jan 2015, at 16:19, Andy Bierman wrote: >=20 > On Thu, Jan 8, 2015 at 2:22 AM, Ladislav Lhotka wrote: >>=20 >>> On 08 Jan 2015, at 10:21, Martin Bjorklund wrote: >>>=20 >>> Hi, >>>=20 >>> Juergen Schoenwaelder wrote: >>>> The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. >>>=20 >>> The reasons for proposing Y09-03 (instead of Y09-02) were: >>>=20 >>> 1. The instance-identifier syntax proposed in Y09-02 doesn't work, >>> b/c empty strings and 0-values integers would also return "true" >>> in the expression "not(key)". >>>=20 >>> But this turned out to be a false claim; the syntax proposed in >>> Y09-02 is correct. >>>=20 >>> 2. Y09-02 is tricky to implement in "common databases", since they >>> require values for all keys. >>=20 >> In some common databases (e.g. mongodb) a declaration of a key is = just an instruction for the server to generate an index. I think it is = more a limitation of NETCONF=E2=80=99s edit-config design. >>=20 >> An implication for both Y09-02 and Y09-03 is that if a key is not set = at the time a list entry is created, it cannot be set afterwards. >>=20 >>>=20 >>> But the idea for how to handle Y09-03 in these databases was to >>> store additional info that the default value is set. The same >>> technique can be used to handle purely optional keys. >>>=20 >>> Thus, I prefer Y09-02. >>=20 >> Me too, Lada >>=20 >>>=20 >=20 >=20 > Neither solution works. > I agree with David that they should not be added at all to YANG. >=20 > Please answer the questions below wrt/ how lists with default keys = work: >=20 > What if the designer does not want a list to automatically instantiate = entries? > How is this accomplished? >=20 > typedef X { > type int32; > default 42; > } >=20 > list broken { > key x; > leaf x { type X; } > leaf y { type string; mandatory true; } > } >=20 > Does the server automatically create a default entry for x=3D42? No, it doesn=E2=80=99t, see Y09-02: "All key leafs can be optional, but = a list instance MUST have at least one of the key leafs instantiated, = =E2=80=A6=E2=80=9D. Lada > If so, then isn't the mandatory-stmt violated immediately? > Are must-stmts in the default key leaf evaluated? >=20 > Are requests for list "broken" allowed to omit the > leaf? Is the server supposed to fill in x=3D42 in such cases? >=20 >=20 >=20 >=20 >>>=20 >>> /martin >=20 >=20 > Andy >=20 >=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 07:40:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E191A8A9C for ; Thu, 8 Jan 2015 07:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwXCstQb6j7V for ; Thu, 8 Jan 2015 07:40:36 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371A51A87EE for ; Thu, 8 Jan 2015 07:40:36 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so9859169lam.5 for ; Thu, 08 Jan 2015 07:40:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OiECRJFjA7qCEAgK3U+VWoWpZkFmE+Jv8r9UcRlSRfA=; b=N0shf9r5fO7HhlRAB7qxrFbkvqAZi2zn0FfkpxWmOdlE4+f7zbfPOQa3FO2BKDX0Z+ jjVup4IoSOzUQPKvjNNb8bwvv9eNQMwTAiPBkeDcbAMQKbfNHDQNmR4JV0TTYzpc0C72 SU/yQx82cp8QaKLxrszQNU3nPwam6h/YkeFzZU/pb6dNozonylxdOzjYadOalK/Taikf NZ3ApBjhhOSxyMpB4o5k8cEapfRjaDeV+/YRG8z1eV1W6KUyBQPj0aifzQL18hWOLnfy HavCl0qPY4EKTnSJHvTeskoVliepERrZ4rvCtNnlGWhWRaLu4z4beWQ5x/5VRA4P2lQc CrZw== X-Gm-Message-State: ALoCoQnqhwLdWVIcHo5/xzfvC3kWRCtCuRaL5v4WWvH9tqiXKw9BvPfdsgedrQ4zg76RPbCvwCKz MIME-Version: 1.0 X-Received: by 10.152.27.130 with SMTP id t2mr14529431lag.28.1420731634679; Thu, 08 Jan 2015 07:40:34 -0800 (PST) Received: by 10.112.77.231 with HTTP; Thu, 8 Jan 2015 07:40:34 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Jan 2015 07:40:34 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y45: conformance-stmt proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:40:44 -0000 On Thu, Jan 8, 2015 at 1:51 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> Hi, >> >> I hope we can resolve this issue on the mailing list, since >> it was skipped in the interim meeting. >> >> IMO import-by-revision is fatally flawed. >> The problem with representing the conformance dependency chain >> in the import-stmt is that not every module is using import-by-revision, >> and if A.1 imports B.1 and B.1 imports C.any, then the dependency >> chain for module A.1 is not deterministic. >> >> import-by-revision everywhere is going to be unmanageable, >> even if all the effort to update every YANG module in existence >> was made. > > Why is it necessary to do such updates? If module A imports > B@2014-01-08, then it can continue using definitions from that > particular revision of B forever, even if B is updated. > IMO (from a couple decades of dealing with MIB module updates it is much easier to just make sure the latest revision of any module in use does not change the definition of any other modules. SMIv2 never needed import-by-revision. >> >> Instead, a conformance-stmt much simpler than the SMIv2 >> MODULE-COMPLIANCE macro is needed: >> >> module foo { >> ... >> import ietf-yang-types { prefix yang; } >> import ietf-inet-types { prefix inet; } >> import ietf-interfaces { prefix if; } >> >> revision 2014-01-05; >> .... >> >> conformance 2014-01-05 { >> module ietf-inet-types@2013-07-15; >> module ietf-yang-types@2013-07-15; >> module ietf-interfaces@2014-05-08; >> } >> } >> > > I don't understand: how is this different from the case when the > revisions of imported modules are specified directly in import statements? > I picked a bad example. The idea is the conformance macro flattens out the dependency tree for each module. module foo { ... import ietf-ip { prefix ip; } revision 2014-01-05; .... conformance 2014-01-05 { use-module ietf-ip@2014-06-16; use-module ietf-interfaces@2014-05-08; use-module ietf-yang-types@2013-07-15; use-module ietf-inet-types@2013-07-15; } } Note that none of these published modules use import-by-revision. The only way to capture the dependency chain for these imported modules is to add some statement to the importing module. > Lada Andy > >> >> Tools can generate this stmt or can be fairly easily generated by hand. >> Import-by-revision would no longer be used. >> >> There would be 1 or more conformance-stmts in descending >> date order, like the revision-stmt history. >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Thu Jan 8 07:56:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB1E1A8AB4 for ; Thu, 8 Jan 2015 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWYw0qgAYDQY for ; Thu, 8 Jan 2015 07:56:47 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820AC1A8AB8 for ; Thu, 8 Jan 2015 07:56:44 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id DF8B712A28069 for ; Thu, 8 Jan 2015 15:56:38 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t08FuewV032591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Jan 2015 10:56:40 -0500 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 10:56:40 -0500 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: Identifying "sensitive" or "security" data nodes (RFC6087bis-01, RFC6536) Thread-Index: AdArW6+9o6mpUO0sTp2zVgtTwdAdYQ== Date: Thu, 8 Jan 2015 15:56:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] Identifying "sensitive" or "security" data nodes (RFC6087bis-01, RFC6536) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:56:50 -0000 Hi guys, I made a verbal comment back in IETF91 for RFC6087bis-01 (and a few others)= and someone recommended at the meeting that it would be useful if I could = post them on the list. Finally getting to that - sorry for the delay. I'm wondering whether it is really possible to adhere to the bullets in sec= tion 4.6 of RFC6087bis-01: o Writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be explained. o Readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. o Operations (i.e., YANG 'rpc' statements) that are potentially harmful to system behavior or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Would we really get agreement across more than 3 people of which data nodes= are "especially disruptive" and which data nodes are not ? There are doze= ns/hundreds of knobs in most systems that can disrupt service (probably *mo= st* nodes), cause a NE to be unmanageable, etc. If you combined the reque= sts of 10 vendors/operators (to make a superset) you'd end up with a large = number of knobs being labeled "disruptive" (we each have our own pet peeves= , or have seen human error in different areas cause service impacts). As = we start to accept more and more nodes as "disruptive" it is a slippery slo= pe and where do you draw the line ? I can see this causing annoying arguments and requests for changes & churn = on modules (or just not being used/useful). It should at least be changed = to "SHOULD" instead of "MUST". Other opinions ? Is it advantageous enough to have "disruptive" labeling "= mostly right" (by the opinion of the author(s)) in modules or should we lea= ve it as an exercise for the user of the module to determine what they cons= ider dangerous (and then use things like NACM to manage it) ? Similar text is found in RFC6536 section 3.7.3: Designers need to clearly identify any sensitive data, notifications, or protocol operations defined within a YANG module. For such definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" statement ought to be present, in addition to a clear description of the security risks. This idea is also expressed in http://trac.tools.ietf.org/area/ops/trac/wik= i/yang-security-guidelines. Jason From nobody Thu Jan 8 08:05:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1D21A875D for ; Thu, 8 Jan 2015 08:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt24ce4ZgNW4 for ; Thu, 8 Jan 2015 08:04:57 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067D11A70FD for ; Thu, 8 Jan 2015 08:04:28 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:c7d:c203:7069:81c3] (unknown [IPv6:2001:718:1a02:1:c7d:c203:7069:81c3]) by mail.nic.cz (Postfix) with ESMTPSA id 6FC6114104B; Thu, 8 Jan 2015 17:04:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420733066; bh=vIuDcxvxbvEjH5L6v4zR0pJUBZ7FUejl2TBF0TCnLLA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x9R4PH5taad1Hc6Spxs14FDB98rnnHZZIBTC380n0gPJq40XMhYyuffklwVzUREw2 oH9AnRfK1gKqkWttkt4T1K9ORxTn81BEQY9aWofoT2zawAwglKqHdKNE+J8QK/wx1i I0AiYxnHQ4XiSEWvjAmYU5AkMG/te2U2dye653HY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 8 Jan 2015 17:04:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y45: conformance-stmt proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:05:00 -0000 > On 08 Jan 2015, at 16:40, Andy Bierman wrote: >=20 > On Thu, Jan 8, 2015 at 1:51 AM, Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> Hi, >>>=20 >>> I hope we can resolve this issue on the mailing list, since >>> it was skipped in the interim meeting. >>>=20 >>> IMO import-by-revision is fatally flawed. >>> The problem with representing the conformance dependency chain >>> in the import-stmt is that not every module is using = import-by-revision, >>> and if A.1 imports B.1 and B.1 imports C.any, then the dependency >>> chain for module A.1 is not deterministic. >>>=20 >>> import-by-revision everywhere is going to be unmanageable, >>> even if all the effort to update every YANG module in existence >>> was made. >>=20 >> Why is it necessary to do such updates? If module A imports >> B@2014-01-08, then it can continue using definitions from that Oh, it=E2=80=99s 2015 already. :-) >> particular revision of B forever, even if B is updated. >>=20 >=20 > IMO (from a couple decades of dealing with MIB module updates > it is much easier to just make sure the latest revision of any module > in use does not change the definition of any other modules. It=E2=80=99s easier for module users but such a requirement = significantly raises the bar for the module development process. > SMIv2 never needed import-by-revision. >=20 >=20 >>>=20 >>> Instead, a conformance-stmt much simpler than the SMIv2 >>> MODULE-COMPLIANCE macro is needed: >>>=20 >>> module foo { >>> ... >>> import ietf-yang-types { prefix yang; } >>> import ietf-inet-types { prefix inet; } >>> import ietf-interfaces { prefix if; } >>>=20 >>> revision 2014-01-05; >>> .... >>>=20 >>> conformance 2014-01-05 { >>> module ietf-inet-types@2013-07-15; >>> module ietf-yang-types@2013-07-15; >>> module ietf-interfaces@2014-05-08; >>> } >>> } >>>=20 >>=20 >> I don't understand: how is this different from the case when the >> revisions of imported modules are specified directly in import = statements? >>=20 >=20 >=20 > I picked a bad example. > The idea is the conformance macro flattens out the dependency > tree for each module. >=20 > module foo { > ... > import ietf-ip { prefix ip; } >=20 > revision 2014-01-05; > .... >=20 > conformance 2014-01-05 { > use-module ietf-ip@2014-06-16; > use-module ietf-interfaces@2014-05-08; > use-module ietf-yang-types@2013-07-15; > use-module ietf-inet-types@2013-07-15; > } > } >=20 >=20 > Note that none of these published modules use import-by-revision. > The only way to capture the dependency chain for these imported > modules is to add some statement to the importing module. OK, but what if ietf-ip also has a conformance statement and its = revision of ietf-interfaces is different? Lada >=20 >=20 >> Lada >=20 >=20 > Andy >=20 >>=20 >>>=20 >>> Tools can generate this stmt or can be fairly easily generated by = hand. >>> Import-by-revision would no longer be used. >>>=20 >>> There would be 1 or more conformance-stmts in descending >>> date order, like the revision-stmt history. >>>=20 >>>=20 >>> Andy >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 08:13:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4D51A875D for ; Thu, 8 Jan 2015 08:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRtuewCxUflf for ; Thu, 8 Jan 2015 08:13:34 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8DD1A871F for ; Thu, 8 Jan 2015 08:13:32 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so9950634lab.13 for ; Thu, 08 Jan 2015 08:13:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BeE5C5zMcZBzxdhZjZkM2QrMY0lREYoAynHj7i5HAaQ=; b=YU8YKNoEDHOp43YpDqemx7InQe73Qa4Ww2j6Rx+OxiRUQDsjaPP+r5hh6yU9znuX2w abK+wGQp/x4mQDF6oTnGHyn8lwE9JKDVttcoULpT18vSI5fkBu4p29TVWKQBkXRULiQv isQtT87j3VlHuxsrK0CfOU891aTCS5QHXj8cnBmF7IG58e5ngafj+Lc6siQL/kFCYtUf 7nrPZg5M2V9IeiekGVsADp+sFuhcYOEVsoUKyEfC5BqrVpecGisN5ji6okzNpvxAAgGO LO31dSI3dazxP/Ui3Kj6XOKE6lga6zWWwhKwsuQ0K1P8lLXCkhOSDsmeD9sCF5wprGwj GwxA== X-Gm-Message-State: ALoCoQmkNKYx8ITG1rum+gF5SfN9EKBdHc2Ky8/55YY9hn8Tv5uO4wM8zR8tfxpXqBHjtudl/pdf MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr14881422lam.15.1420733610968; Thu, 08 Jan 2015 08:13:30 -0800 (PST) Received: by 10.112.77.231 with HTTP; Thu, 8 Jan 2015 08:13:30 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Jan 2015 08:13:30 -0800 Message-ID: From: Andy Bierman To: "Sterne, Jason (Jason)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Identifying "sensitive" or "security" data nodes (RFC6087bis-01, RFC6536) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:13:36 -0000 On Thu, Jan 8, 2015 at 7:56 AM, Sterne, Jason (Jason) wrote: > Hi guys, > > I made a verbal comment back in IETF91 for RFC6087bis-01 (and a few other= s) and someone recommended at the meeting that it would be useful if I coul= d post them on the list. Finally getting to that - sorry for the delay. > > I'm wondering whether it is really possible to adhere to the bullets in s= ection 4.6 of RFC6087bis-01: > > o Writable data nodes that could be especially disruptive if abused > MUST be explicitly listed by name and the associated security > risks MUST be explained. > > o Readable data nodes that contain especially sensitive information > or that raise significant privacy concerns MUST be explicitly > listed by name and the reasons for the sensitivity/privacy > concerns MUST be explained. > > o Operations (i.e., YANG 'rpc' statements) that are potentially > harmful to system behavior or that raise significant privacy > concerns MUST be explicitly listed by name and the reasons for the > sensitivity/privacy concerns MUST be explained. > > Would we really get agreement across more than 3 people of which data nod= es are "especially disruptive" and which data nodes are not ? There are do= zens/hundreds of knobs in most systems that can disrupt service (probably *= most* nodes), cause a NE to be unmanageable, etc. If you combined the req= uests of 10 vendors/operators (to make a superset) you'd end up with a larg= e number of knobs being labeled "disruptive" (we each have our own pet peev= es, or have seen human error in different areas cause service impacts). A= s we start to accept more and more nodes as "disruptive" it is a slippery s= lope and where do you draw the line ? > > I can see this causing annoying arguments and requests for changes & chur= n on modules (or just not being used/useful). It should at least be change= d to "SHOULD" instead of "MUST". > > Other opinions ? Is it advantageous enough to have "disruptive" labeling= "mostly right" (by the opinion of the author(s)) in modules or should we l= eave it as an exercise for the user of the module to determine what they co= nsider dangerous (and then use things like NACM to manage it) ? > I don't think the IESG would agree with your logic. The wiggle-room is in the WG decision that a specific node could be especially disruptive. > Similar text is found in RFC6536 section 3.7.3: > > Designers need to clearly identify any sensitive data, notifications, > or protocol operations defined within a YANG module. For such > definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" > statement ought to be present, in addition to a clear description of > the security risks. > > This idea is also expressed in http://trac.tools.ietf.org/area/ops/trac/w= iki/yang-security-guidelines. > > Jason Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jan 8 08:27:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC21A876C for ; Thu, 8 Jan 2015 08:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHq3AsUm-C-r for ; Thu, 8 Jan 2015 08:27:07 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706711A875D for ; Thu, 8 Jan 2015 08:27:07 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so3743905lbd.9 for ; Thu, 08 Jan 2015 08:27:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z/cs5Gr5CyozT5hxtyVcJ5Gov8SxZ5DnRbbjFDudZYo=; b=c0scnsAHJTyWZPmra+SyvwvcZ+OK3mbuJGp6B/v2j/TNNJa0GWmLFcrMoeEfUL93zm SJOaYzXSJTw9xhPs3Zszd23N7IgvMoLQOEePh/qpRIrdVEzHgEQfQpGqKP7mtdd0ZSgh YhHil8nKXuFNPLMdnNp7LhKoz3VbwVhBNYFFmAKG3oQnEgaP4+6DLHOlqLTar7EEkYkW UM/SXNyxLT7pC1kNNhm3pBGTNlxkZ0AFgv1Fow6tZ1weDQKXY/2cIabPKoO22pVhEUYL 77IrFZqfPWsjs5dlxeJnA2sQRtEPLDLqg7+wlWQuLpo0i3zYTtPi7pKTnikVseaSh5Em bjfQ== X-Gm-Message-State: ALoCoQmC0S1EzUwBd8/fz9iD6arf86HTnNEH2mqO8DaoBQuzGxtZ9rgZ2skPtHK8ZhJuoRLKDJr1 MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr14730138laf.82.1420730379510; Thu, 08 Jan 2015 07:19:39 -0800 (PST) Received: by 10.112.77.231 with HTTP; Thu, 8 Jan 2015 07:19:39 -0800 (PST) In-Reply-To: <0CD84218-D27C-4DB2-8E4A-8D9D651BE308@nic.cz> References: <20150107143216.GA13482@elstar.local> <20150108.102157.2289650364805875177.mbj@tail-f.com> <0CD84218-D27C-4DB2-8E4A-8D9D651BE308@nic.cz> Date: Thu, 8 Jan 2015 07:19:39 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:27:09 -0000 On Thu, Jan 8, 2015 at 2:22 AM, Ladislav Lhotka wrote: > >> On 08 Jan 2015, at 10:21, Martin Bjorklund wrote: >> >> Hi, >> >> Juergen Schoenwaelder wrote: >>> The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. >> >> The reasons for proposing Y09-03 (instead of Y09-02) were: >> >> 1. The instance-identifier syntax proposed in Y09-02 doesn't work, >> b/c empty strings and 0-values integers would also return "true" >> in the expression "not(key)". >> >> But this turned out to be a false claim; the syntax proposed in >> Y09-02 is correct. >> >> 2. Y09-02 is tricky to implement in "common databases", since they >> require values for all keys. > > In some common databases (e.g. mongodb) a declaration of a key is just an= instruction for the server to generate an index. I think it is more a limi= tation of NETCONF=E2=80=99s edit-config design. > > An implication for both Y09-02 and Y09-03 is that if a key is not set at = the time a list entry is created, it cannot be set afterwards. > >> >> But the idea for how to handle Y09-03 in these databases was to >> store additional info that the default value is set. The same >> technique can be used to handle purely optional keys. >> >> Thus, I prefer Y09-02. > > Me too, Lada > >> Neither solution works. I agree with David that they should not be added at all to YANG. Please answer the questions below wrt/ how lists with default keys work: What if the designer does not want a list to automatically instantiate entr= ies? How is this accomplished? typedef X { type int32; default 42; } list broken { key x; leaf x { type X; } leaf y { type string; mandatory true; } } Does the server automatically create a default entry for x=3D42? If so, then isn't the mandatory-stmt violated immediately? Are must-stmts in the default key leaf evaluated? Are requests for list "broken" allowed to omit the leaf? Is the server supposed to fill in x=3D42 in such cases? >> >> /martin Andy >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jan 8 08:37:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC7F1A00FD for ; Thu, 8 Jan 2015 08:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHWf_vysG2B7 for ; Thu, 8 Jan 2015 08:37:41 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27501A0111 for ; Thu, 8 Jan 2015 08:37:40 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so3806062lbv.11 for ; Thu, 08 Jan 2015 08:37:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UeYCdgYQD1dgE0LE7QEzS5bxxMfq7fa+BEzfGRrOJ7o=; b=BUYPhLYUjxAoNiLmuXQNmhteaIYfem9kOs9zph9ZVIVMzdNvlubI+UHW+OCMQZBCEk rAlAv38aeQPfMExxQdFvmfQV6JkJFPcxXhaOpfYGgix9UglTTsR0+NmmNAjMjHoaT7QQ EbwbEVEYiEHBiuTnTYWgXNP6Yr+vJ39EV4zamvXhSqvs/JSTc9vjQk49LIifE2xj0kqf Y1lJUzKigMHphOiTDc3lqE4QiAVR2po/cbNbjRmUtvICQ7KhMlZBDtNTqCS9GlR64OtC 4PnA8r+aW9ncMtkPRiNvmJPni4LULTmuFTAVU5fH/VmLv9akP158i4I/16ie99JRntUs NoXw== X-Gm-Message-State: ALoCoQmzeyVIeOWdcLhaII0BJHT0xhuq/Jqh8FzJO+lZj4XPvagpzY7u9MvY/F20HHy0b18otd5O MIME-Version: 1.0 X-Received: by 10.152.27.130 with SMTP id t2mr15049932lag.28.1420735058996; Thu, 08 Jan 2015 08:37:38 -0800 (PST) Received: by 10.112.77.231 with HTTP; Thu, 8 Jan 2015 08:37:38 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Jan 2015 08:37:38 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y45: conformance-stmt proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 16:37:43 -0000 On Thu, Jan 8, 2015 at 8:04 AM, Ladislav Lhotka wrote: > >> On 08 Jan 2015, at 16:40, Andy Bierman wrote: >> >> On Thu, Jan 8, 2015 at 1:51 AM, Ladislav Lhotka wrote: >>> Andy Bierman writes: >>> >>>> Hi, >>>> >>>> I hope we can resolve this issue on the mailing list, since >>>> it was skipped in the interim meeting. >>>> >>>> IMO import-by-revision is fatally flawed. >>>> The problem with representing the conformance dependency chain >>>> in the import-stmt is that not every module is using import-by-revisio= n, >>>> and if A.1 imports B.1 and B.1 imports C.any, then the dependency >>>> chain for module A.1 is not deterministic. >>>> >>>> import-by-revision everywhere is going to be unmanageable, >>>> even if all the effort to update every YANG module in existence >>>> was made. >>> >>> Why is it necessary to do such updates? If module A imports >>> B@2014-01-08, then it can continue using definitions from that > > Oh, it=E2=80=99s 2015 already. :-) > >>> particular revision of B forever, even if B is updated. >>> >> >> IMO (from a couple decades of dealing with MIB module updates >> it is much easier to just make sure the latest revision of any module >> in use does not change the definition of any other modules. > > It=E2=80=99s easier for module users but such a requirement significantly= raises the bar for the module development process. > >> SMIv2 never needed import-by-revision. >> >> >>>> >>>> Instead, a conformance-stmt much simpler than the SMIv2 >>>> MODULE-COMPLIANCE macro is needed: >>>> >>>> module foo { >>>> ... >>>> import ietf-yang-types { prefix yang; } >>>> import ietf-inet-types { prefix inet; } >>>> import ietf-interfaces { prefix if; } >>>> >>>> revision 2014-01-05; >>>> .... >>>> >>>> conformance 2014-01-05 { >>>> module ietf-inet-types@2013-07-15; >>>> module ietf-yang-types@2013-07-15; >>>> module ietf-interfaces@2014-05-08; >>>> } >>>> } >>>> >>> >>> I don't understand: how is this different from the case when the >>> revisions of imported modules are specified directly in import statemen= ts? >>> >> >> >> I picked a bad example. >> The idea is the conformance macro flattens out the dependency >> tree for each module. >> >> module foo { >> ... >> import ietf-ip { prefix ip; } >> >> revision 2014-01-05; >> .... >> >> conformance 2014-01-05 { >> use-module ietf-ip@2014-06-16; >> use-module ietf-interfaces@2014-05-08; >> use-module ietf-yang-types@2013-07-15; >> use-module ietf-inet-types@2013-07-15; >> } >> } >> >> >> Note that none of these published modules use import-by-revision. >> The only way to capture the dependency chain for these imported >> modules is to add some statement to the importing module. > > OK, but what if ietf-ip also has a conformance statement and its revision= of ietf-interfaces is different? > In this example, the ietf-interfaces info is derived from the ietf-ip modul= e. The "foo" module cannot pick which modules and revisions that the "ietf-interfaces" module imports. But you are correct that flattening out the dependency chain either has to pick the most recent common version, list duplicates, or list a set of t= rees. The conformance-stmt will not really help, except to capture the revision dates where import-by-revision is not used. IMO changing every YANG module to use import-by-revision is not feasible, or a good idea. And import-by-revision everywhere still doesn't work. (Cannot have multiple revisions of an augmented object for example). It would be better to say that exported static typede= fs (not identityref) MUST NOT be expanded, and exported groupings MUST NOT be expanded. They can be corrected, which is a case-by-case judgement call= . BTW, include-by-revision SHOULD be used everywhere. There is currently a hole in conformance because submodules are not supported in the or in the 'schema' list. > Lada > Andy >> >> >>> Lada >> >> >> Andy >> >>> >>>> >>>> Tools can generate this stmt or can be fairly easily generated by hand= . >>>> Import-by-revision would no longer be used. >>>> >>>> There would be 1 or more conformance-stmts in descending >>>> date order, like the revision-stmt history. >>>> >>>> >>>> Andy >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu Jan 8 10:00:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7931A8AF9 for ; Thu, 8 Jan 2015 10:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEBTNJeLB1nV for ; Thu, 8 Jan 2015 10:00:48 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A427E1A8F40 for ; Thu, 8 Jan 2015 10:00:48 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 78D879ECECC0C for ; Thu, 8 Jan 2015 18:00:43 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t08HwxfX028589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Jan 2015 13:00:45 -0500 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 13:00:28 -0500 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: comments on RFC6087bis-01 Thread-Index: AdArbPtoOaTzCL/WRZ6OFcWOgUZIhw== Date: Thu, 8 Jan 2015 18:00:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] comments on RFC6087bis-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:00:50 -0000 Hi guys, RFC6087 contains a lot of useful guidelines. It would be really nice if s= ome of the guidelines were illustrated with some examples. If various folk= s know some of this stuff well and can provide an example off the top of th= eir heads it would help make an update easier. ### Section 5.2 Perhaps add a few examples of valid and invalid identifiers ? Good: leaf my-interface container Hello6789012345678901234567890123456789012345678901234567= 8901234 list _a10-locations.in.canada Bad: leaf xml-config (can't start with 'xml') container Hello6789012345678901234567890123456789012345678901234567= 89012345 (65 chars) list 5alive (can't start with a digit) ### Section 5.3.3 After the discussion about 64bit values in YANG settles out we should likel= y move this into its own section and put more comprehensive information in = the doc. There is a nice example for the last XPath expression point (for 'when' sta= tements). It would be great to get an example for the other 3 points (mix= ing of yang & xpath space, xpath conversions and xpath with identities). ### Section 5.6 I know there has been a lot of recent debate over how modules include/impor= t each other. If it has settled out enough to update this section that wou= ld be great (I don't think it has) - otherwise this is just a placeholder c= omment to update that part of the doc. We should probably continue that de= bate in the other email threads and not drag it into this particular email = thread. ### Section 5.9 The paragraph about mandatory definitions seems to somewhat conflict with t= he 'type' leaf in the ietf-interfaces module. RFC6087bis says that a manda= tory leaf must be provided by the client. RFC6020 section 7.6.5 says the = leaf must *exist* (but doesn't seem to require the client to necessarily pr= ovide it). ### Section 5.10 Does someone have an example for "since a double-quoted string can modify t= he content" ? Regards, Jason From nobody Fri Jan 9 01:25:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA4E1A86EB for ; Fri, 9 Jan 2015 01:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IMiJe-By-pp for ; Fri, 9 Jan 2015 01:25:40 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 401541A86E8 for ; Fri, 9 Jan 2015 01:25:39 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E5B961CC010E; Fri, 9 Jan 2015 10:25:46 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150108.111210.390242656752383270.mbj@tail-f.com> References: <20150108.111210.390242656752383270.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 09 Jan 2015 10:25:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] if-feature on identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:25:42 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> Hi, >> >> some routing folks came up with the idea that it would be useful to allow >> if-feature on identities (the discussion was related to >> crypto-algorithms). > > This is part of Y11, already in the current draft for yang-1.1. With if-feature on an identity, what is be the rule for identities derived from it? Are they required to have the same or stricter if-feature? And how about identityrefs? I think the distributed nature of identities makes it a bit awkward, so I wonder whether it is really needed to allow if-feature on identities. Perhaps it could suffice to have if-feature as an XPath function (actually, I thought it was planned to have it). Lada > >> What's behind it is the same issue we have with the iana-interface-type >> module: a server advertising that module should in fact be prepared to >> receive all kinds of weird interface types. > > Receive yes, but that is not the same thing as accept. > > >> In my view, this is exactly the problem that identities (as opposed to >> enumerations) are able to avoid. If an identity for an interface type >> (or crypto-algorithm or whatever) was always defined in the same module >> as config and state data for that interface type, all would be fine. > > Agreed. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 01:41:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB841A86EB for ; Fri, 9 Jan 2015 01:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4SWmYC7Lf_7 for ; Fri, 9 Jan 2015 01:41:33 -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 A74F01A86E8 for ; Fri, 9 Jan 2015 01:41:33 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 057C2703; Fri, 9 Jan 2015 10:41:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9Fd8XdIC11OT; Fri, 9 Jan 2015 10:41:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Jan 2015 10:41:31 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 436172002C; Fri, 9 Jan 2015 10:41:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g6xdsePXmpdB; Fri, 9 Jan 2015 10:33:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CB6520017; Fri, 9 Jan 2015 10:41:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 64E1B3053DDC; Fri, 9 Jan 2015 10:41:30 +0100 (CET) Date: Fri, 9 Jan 2015 10:41:30 +0100 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20150109094130.GA19760@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] comments on RFC6087bis-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:41:36 -0000 On Thu, Jan 08, 2015 at 06:00:27PM +0000, Sterne, Jason (Jason) wrote: > > ### Section 5.10 > > Does someone have an example for "since a double-quoted string can modify the content" ? > I think the wording here needs to improve. The issue is that double quoted strings (i) allow backslash substitutions and (ii) white space stripping. OLD A single quoted string SHOULD be used to specify the pattern, since a double-quoted string can modify the content. NEW A single quoted string SHOULD be used to specify the pattern, since a backslash substitutions and white space stripping can occur in a double-quoted string. As an example, the pattern '\d' accepts any of the digits 0..9 while the pattern "\d" is an undefined backslash substitution in YANG 1.0 and likely causing an error in YANG 1.1. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 9 01:48:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FA81A870B for ; Fri, 9 Jan 2015 01:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF_-f9KfxQSP for ; Fri, 9 Jan 2015 01:47:55 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan11.extendcp.co.uk [79.170.45.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B455A1A86F5 for ; Fri, 9 Jan 2015 01:47:55 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan8.hi.local) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Y9WAZ-0002s5-Tc; Fri, 09 Jan 2015 09:47:51 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=www.outitgoes.com) by mailscan8.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Y9WAX-0005Hs-FM; Fri, 09 Jan 2015 09:47:52 +0000 Received: from localhost ([127.0.0.1]) by webmail6.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Y9WAX-0000sc-9E; Fri, 09 Jan 2015 09:47:49 +0000 Message-Id: <0b47149f9b169ee969975778df1634b8c9c0f479@webmail.hansfords.net> From: "Jonathan Hansford" To: "Juergen Schoenwaelder" , "Sterne Jason (Jason)" X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 10.0.1.197 in-reply-to: <20150109094130.GA19760@elstar.local> Date: Fri, 09 Jan 2015 09:47:49 +0000 Content-Type: multipart/alternative; boundary="=_8d69a0632d780ca6476c809dadbcfcf4" MIME-Version: 1.0 X-Authenticated-As: jonathan@hansfords.net Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] comments on RFC6087bis-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 09:47:58 -0000 --=_8d69a0632d780ca6476c809dadbcfcf4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In NEW:=0A=C2=A0s/a backslash substitutions/backslash substitutions=0As/= likely causing/likely to cause=0A=0A----- Original Message -----=0AFrom:= "Juergen Schoenwaelder" =0ATo:"Sterne Jason (Jason)" =0ACc:"netmod@ietf= org" =0ASent:Fri, 9 Jan 2015 10:41:30 +0100=0ASubject:Re: [netmod] comm= ents on RFC6087bis-01=0A=0A On Thu, Jan 08, 2015 at 06:00:27PM +0000, St= erne, Jason (Jason)=0Awrote:=0A > =0A > ### Section 5.10=0A > =0A > Does= someone have an example for "since a double-quoted string can=0Amodify= the content" ?=0A > =0A=0A I think the wording here needs to improve. T= he issue is that double=0A quoted strings (i) allow backslash substituti= ons and (ii) white space=0A stripping.=0A=0A OLD=0A=0A A single quoted s= tring SHOULD be used to specify the=0A pattern, since a double-quoted st= ring can modify the content.=0A=0A NEW=0A=0A A single quoted string SHOU= LD be used to specify the pattern, since=0A a backslash substitutions an= d white space stripping can occur in a=0A double-quoted string.=0A=0A As= an example, the pattern 'd' accepts any of the digits 0..9 while=0A the= pattern "d" is an undefined backslash substitution in YANG 1.0=0A and l= ikely causing an error in YANG 1.1.=0A=0A /js=0A=0A -- =0A Juergen Schoe= nwaelder Jacobs University Bremen gGmbH=0A Phone: +49 421 200 3587 Campu= s Ring 1, 28759 Bremen, Germany=0A Fax: +49 421 200 3103 =0A=0A ________= _______________________________________=0A netmod mailing list=0A netmod= @ietf.org=0A https://www.ietf.org/mailman/listinfo/netmod=0A --=_8d69a0632d780ca6476c809dadbcfcf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In NEW:
=C2=A0s/a backslash substitutions/= backslash substitutions
s/likely causing/likely to cause


----- Original Message -----
Fro= m:
"Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.d= e>

To:
"Sterne Jason= (Jason)" <jason.sterne@alcatel-lucent.com>
Cc:
"netmod@ietf.org" <netmod@ietf.org>
=
Sent:
Fri, 9 Jan 2015 10:41:30 +01= 00
Subject:
Re: [netmod] comm= ents on RFC6087bis-01


=0AOn Thu, Jan 08, 2015 at 06:00:= 27PM +0000, Sterne, Jason (Jason) wrote:
=0A>
=0A> ###= Section 5.10
=0A>
=0A> Does someone have an example fo= r "since a double-quoted string can modify the content" ?
=0A> <= br />
=0AI think the wording here needs to improve. The issue is th= at double
=0Aquoted strings (i) allow backslash substitutions and (= ii) white space
=0Astripping.

=0AOLD

=0A A= single quoted string SHOULD be used to specify the
=0A pattern,= since a double-quoted string can modify the content.

=0ANEW<= br />
=0A A single quoted string SHOULD be used to specify the pa= ttern, since
=0A a backslash substitutions and white space stripp= ing can occur in a
=0A double-quoted string.

=0AAs an= example, the pattern '\d' accepts any of the digits 0..9 while
=0A= the pattern "\d" is an undefined backslash substitution in YANG 1.0
=0Aand likely causing an error in YANG 1.1.

=0A/js
=0A--
=0AJuergen Schoenwaelder Jacobs University Brem= en gGmbH
=0APhone: +49 421 200 3587 Campus Ring 1, 28759 Br= emen, Germany
=0AFax: +49 421 200 3103 <http://www.jac= obs-university.de/>

=0A___________________________________= ____________
=0Anetmod mailing list
=0Anetmod@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/netmod
--=_8d69a0632d780ca6476c809dadbcfcf4-- From nobody Fri Jan 9 02:26:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEA91A8741 for ; Fri, 9 Jan 2015 02:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-Z1aiSmOtQ8 for ; Fri, 9 Jan 2015 02:25:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BB01A8740 for ; Fri, 9 Jan 2015 02:25:59 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 08FE013FCB8 for ; Fri, 9 Jan 2015 11:25:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420799158; bh=v00W+WdzoSP5S67yh9GEAfBX9wffkwye+Xor2rrBf1Y=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=dmOHQThmAS4lbnai4oHn7E9D+0I7UqTxlunOyPwtTVORwc4BX/x+Me/sCinhMyWFY odZbAgGJpsjRcdPQKyFqNigd7bt9nvEEOZ47dEtUhGDQIBNog6piJEZRaVbR3Zc0tY iA6+59G9TKZaIH7YvofXNt+bCbHm2T/IT6h3gOO8= From: Ladislav Lhotka Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 9 Jan 2015 11:25:57 +0100 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 10:26:01 -0000 Hi, YANG has this peculiar rule for double-quoted strings: If the double-quoted string contains a line break followed by space or tab characters that are used to indent the text according to the layout in the YANG file, this leading whitespace is stripped from the string, up to and including the column of the double quote character, or to the first non-whitespace character, whichever occurs first. In this process, a tab character is treated as 8 space characters. As I recently found out, this kind of whitespace stripping is difficult = to implement with some standard parser libraries because the parser has = to be able to get the column of the opening double quote. And even if it = is possible, it slows down parsing. The existing practice shows such multi-line strings are only used in = descriptions and references where whitespace stripping is not needed at = all - e.g., for translation to YIN format such strings have to be = re-formatted anyway. In all other cases it is IMO much better to use = concatenation "..." + "..." So I=E2=80=99d suggest to remove whitespace stripping in YANG 1.1, for = the benefit of parsers and the spec itself. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 02:29:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5590A1A874B for ; Fri, 9 Jan 2015 02:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlUjflBGyO8P for ; Fri, 9 Jan 2015 02:29:17 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CD41A8741 for ; Fri, 9 Jan 2015 02:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5690; q=dns/txt; s=iport; t=1420799357; x=1422008957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=We1i0plhRbqg8PH1Y1a9UWsHy/TuWGma084jzTt/++k=; b=GROgMtGGUA4Dg0lN0R1eW5Aj6t5REPZuJm+1r2fNNdcdKzEB5R7depNL Cp9cg7qlK6H1aBf3h5AR/cpulGvrzGJJ0aRCGpMEKOPgg0tISS7efHbfr VQ3GP6xsnpbJrsg93YkKgNj4KXtc1SNL4r2hlzxZIdlDB6oynniCB/xCk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAAytr1StJA2D/2dsb2JhbABcgwZSWASDAcBUghsKhSdKAhx8QwEBAQEBfYQMAQEBAwEBAQEgEToLBQcEAgEIEAEEAQEBAgIGHQMCAgIlCxQBCAgCBAENBQgTiAkIDbQNk3QBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjicxBwaCYi6BEwWONYoXgnGNcCKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,729,1413244800"; d="scan'208";a="111721824" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 09 Jan 2015 10:29:16 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t09ATGAC012134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 10:29:16 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.210]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 04:29:16 -0600 From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" To: Andy Bierman , Ladislav Lhotka Thread-Topic: [netmod] VRFY :Y09: introduce optional keys Thread-Index: AQIZB9zhX47IqhXn3GPDbxh9jY79XwDqoO6DAhUpr1gCoRo/JJv4zXNw Date: Fri, 9 Jan 2015 10:29:15 +0000 Message-ID: <013A9B371AC6DF4C8AD261897D8F243E117A4FD2@xmb-aln-x08.cisco.com> References: <20150107143216.GA13482@elstar.local> <20150108.102157.2289650364805875177.mbj@tail-f.com> <0CD84218-D27C-4DB2-8E4A-8D9D651BE308@nic.cz> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.23.97] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 10:29:20 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQo+IFNlbnQ6 IDA4IEphbnVhcnkgMjAxNSAxNToyMA0KPiBUbzogTGFkaXNsYXYgTGhvdGthDQo+IENjOiBuZXRt b2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFZSRlkgOlkwOTogaW50cm9kdWNl IG9wdGlvbmFsIGtleXMNCj4gDQo+IE9uIFRodSwgSmFuIDgsIDIwMTUgYXQgMjoyMiBBTSwgTGFk aXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPg0KPiA+PiBPbiAwOCBKYW4g MjAxNSwgYXQgMTA6MjEsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90ZToN Cj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPj4+IFRoZSAyMDE0LTEy LTAzIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIHByb3Bvc2FsIGlzIHRvIGFkb3B0IFkwOS0wMy4N Cj4gPj4NCj4gPj4gVGhlIHJlYXNvbnMgZm9yIHByb3Bvc2luZyBZMDktMDMgKGluc3RlYWQgb2Yg WTA5LTAyKSB3ZXJlOg0KPiA+Pg0KPiA+PiAgMS4gVGhlIGluc3RhbmNlLWlkZW50aWZpZXIgc3lu dGF4IHByb3Bvc2VkIGluIFkwOS0wMiBkb2Vzbid0IHdvcmssDQo+ID4+ICAgICBiL2MgZW1wdHkg c3RyaW5ncyBhbmQgMC12YWx1ZXMgaW50ZWdlcnMgd291bGQgYWxzbyByZXR1cm4gInRydWUiDQo+ ID4+ICAgICBpbiB0aGUgZXhwcmVzc2lvbiAibm90KGtleSkiLg0KPiA+Pg0KPiA+PiAgQnV0IHRo aXMgdHVybmVkIG91dCB0byBiZSBhIGZhbHNlIGNsYWltOyB0aGUgc3ludGF4IHByb3Bvc2VkIGlu DQo+ID4+ICBZMDktMDIgaXMgY29ycmVjdC4NCj4gPj4NCj4gPj4gIDIuIFkwOS0wMiBpcyB0cmlj a3kgdG8gaW1wbGVtZW50IGluICJjb21tb24gZGF0YWJhc2VzIiwgc2luY2UgdGhleQ0KPiA+PiAg ICAgcmVxdWlyZSB2YWx1ZXMgZm9yIGFsbCBrZXlzLg0KPiA+DQo+ID4gSW4gc29tZSBjb21tb24g ZGF0YWJhc2VzIChlLmcuIG1vbmdvZGIpIGEgZGVjbGFyYXRpb24gb2YgYSBrZXkgaXMganVzdA0K PiBhbiBpbnN0cnVjdGlvbiBmb3IgdGhlIHNlcnZlciB0byBnZW5lcmF0ZSBhbiBpbmRleC4gSSB0 aGluayBpdCBpcyBtb3JlIGENCj4gbGltaXRhdGlvbiBvZiBORVRDT05G4oCZcyBlZGl0LWNvbmZp ZyBkZXNpZ24uDQo+ID4NCj4gPiBBbiBpbXBsaWNhdGlvbiBmb3IgYm90aCBZMDktMDIgYW5kIFkw OS0wMyBpcyB0aGF0IGlmIGEga2V5IGlzIG5vdCBzZXQNCj4gYXQgdGhlIHRpbWUgYSBsaXN0IGVu dHJ5IGlzIGNyZWF0ZWQsIGl0IGNhbm5vdCBiZSBzZXQgYWZ0ZXJ3YXJkcy4NCj4gPg0KPiA+Pg0K PiA+PiAgQnV0IHRoZSBpZGVhIGZvciBob3cgdG8gaGFuZGxlIFkwOS0wMyBpbiB0aGVzZSBkYXRh YmFzZXMgd2FzIHRvDQo+ID4+ICBzdG9yZSBhZGRpdGlvbmFsIGluZm8gdGhhdCB0aGUgZGVmYXVs dCB2YWx1ZSBpcyBzZXQuICBUaGUgc2FtZQ0KPiA+PiAgdGVjaG5pcXVlIGNhbiBiZSB1c2VkIHRv IGhhbmRsZSBwdXJlbHkgb3B0aW9uYWwga2V5cy4NCj4gPj4NCj4gPj4gVGh1cywgSSBwcmVmZXIg WTA5LTAyLg0KPiA+DQo+ID4gTWUgdG9vLCBMYWRhDQoNCkkgdGhpbmsgdGhhdCBhcyB3ZWxsIGFz IG5vdCBoYXZpbmcgYW55IGRvd25zaWRlcywgWTA5LTAyIGFjdHVhbGx5IGFkZHJlc3NlcyB0aGUg c2V0IG9mIGlzc3VlcyBiZXR0ZXIgdGhhbiBZMDktMDM7IHNvbWV0aW1lcyB0aGVyZSBpc24ndCBh IGRlZmF1bHQgdGhhdCBtYWtlcyBzZW5zZSwgaW4gd2hpY2ggY2FzZSBhZGRpbmcgYWJzZW5jZSB0 byB0aGUgdmFsdWUgc3BhY2Ugb2YgYSBrZXkgaXMgaW1wb3J0YW50Lg0KDQo+IE5laXRoZXIgc29s dXRpb24gd29ya3MuDQo+IEkgYWdyZWUgd2l0aCBEYXZpZCB0aGF0IHRoZXkgc2hvdWxkIG5vdCBi ZSBhZGRlZCBhdCBhbGwgdG8gWUFORy4NCg0KSXMgdGhlIGtleSBjb25jZXJuIGhlcmUgdGhlIGhh bmRsaW5nIG9mIGRlZmF1bHQgdmFsdWVzPw0KDQo+IFBsZWFzZSBhbnN3ZXIgdGhlIHF1ZXN0aW9u cyBiZWxvdyB3cnQvIGhvdyBsaXN0cyB3aXRoIGRlZmF1bHQga2V5cyB3b3JrOg0KPiANCj4gV2hh dCBpZiB0aGUgZGVzaWduZXIgZG9lcyBub3Qgd2FudCBhIGxpc3QgdG8gYXV0b21hdGljYWxseSBp bnN0YW50aWF0ZQ0KPiBlbnRyaWVzPw0KPiBIb3cgaXMgdGhpcyBhY2NvbXBsaXNoZWQ/DQoNCklm IHdlIGRvIGhhdmUgZGVmYXVsdHMsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgaGF2aW5nIGEg ZGVmYXVsdCB2YWx1ZSBmb3IgYSBrZXkgc2hvdWxkbid0IG1lYW4gYSBsaXN0IGVudHJ5IGlzIGF1 dG9tYXRpY2FsbHkgaW5zdGFudGlhdGVkIC0tIGkuZS4gdGhlcmUgc2hvdWxkIHN0aWxsIGJlIG5v IGxpc3QgZW50cmllcyB1bnRpbCB0aGV5IGFyZSBleHBsaWNpdGx5IGNyZWF0ZWQuDQoNClBlcmhh cHMgdGhpcyBjb3VsZCBiZSBtYWRlIGV4cGxpY2l0IGJ5IHJlcXVpcmluZyB0aGF0IGF0IGxlYXN0 IG9uZSBrZXkgaGFzIG5vIGRlZmF1bHQgdmFsdWU/DQoNCj4gICB0eXBlZGVmIFggew0KPiAgICAg IHR5cGUgaW50MzI7DQo+ICAgICAgZGVmYXVsdCA0MjsNCj4gICB9DQo+IA0KPiAgIGxpc3QgYnJv a2VuIHsNCj4gICAgICBrZXkgeDsNCj4gICAgICBsZWFmIHggeyB0eXBlIFg7IH0NCj4gICAgICBs ZWFmIHkgeyB0eXBlIHN0cmluZzsgbWFuZGF0b3J5IHRydWU7IH0NCj4gICB9DQo+IA0KPiBEb2Vz IHRoZSBzZXJ2ZXIgYXV0b21hdGljYWxseSBjcmVhdGUgYSBkZWZhdWx0IGVudHJ5IGZvciB4PTQy Pw0KPiBJZiBzbywgdGhlbiBpc24ndCB0aGUgbWFuZGF0b3J5LXN0bXQgdmlvbGF0ZWQgaW1tZWRp YXRlbHk/DQo+IEFyZSBtdXN0LXN0bXRzIGluIHRoZSBkZWZhdWx0IGtleSBsZWFmIGV2YWx1YXRl ZD8NCj4gDQo+IEFyZSA8ZWRpdC1jb25maWc+IHJlcXVlc3RzIGZvciBsaXN0ICJicm9rZW4iIGFs bG93ZWQgdG8gb21pdCB0aGUgPHg+DQo+IGxlYWY/ICBJcyB0aGUgc2VydmVyIHN1cHBvc2VkIHRv IGZpbGwgaW4geD00MiBpbiBzdWNoIGNhc2VzPw0KDQpQZXIgUkZDNjAyMCBzZWN0aW9uIDcuNi4x Og0KDQogICAiLi4uIGlmIHRoZSBsZWFmJ3MgdHlwZSBoYXMNCiAgIGEgZGVmYXVsdCB2YWx1ZSwg YW5kIHRoZSBsZWFmIGlzIG5vdCBtYW5kYXRvcnksIHRoZW4gdGhlIGxlYWYncw0KICAgZGVmYXVs dCB2YWx1ZSBpcyB0aGUgdHlwZSdzIGRlZmF1bHQgdmFsdWUuICBJbiBhbGwgb3RoZXIgY2FzZXMs IHRoZQ0KICAgbGVhZiBkb2VzIG5vdCBoYXZlIGEgZGVmYXVsdCB2YWx1ZS4iDQoNClNvIGluIHRo aXMgZXhhbXBsZSwgc2luY2UgdGhlIGxlYWYgaXMgbWFuZGF0b3J5LCB0aGUgZGVmYXVsdCB2YWx1 ZSBpcyBpZ25vcmVkLCBhbmQgdGhlIGNsaWVudCBtdXN0IHNwZWNpZnkgYSB2YWx1ZS4gKE90aGVy d2lzZSB0aGlzIHNhbWUgcHJvYmxlbSB3b3VsZCBhcHBseSB0byBhbnkgbGVhZiBpbiB0aGUgbGlz dC4pDQoNCkNoZWVycywNClBleW1hbg0KDQo+ID4+DQo+ID4+IC9tYXJ0aW4NCj4gDQo+IA0KPiBB bmR5DQo+IA0KPiANCj4gPj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+PiBuZXRt b2RAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCj4gPg0KPiA+IC0tDQo+ID4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiA+ IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5n IGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Fri Jan 9 02:34:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5201A8743 for ; Fri, 9 Jan 2015 02:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 016JPeJzNrs0 for ; Fri, 9 Jan 2015 02:34:41 -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 CF1431A8742 for ; Fri, 9 Jan 2015 02:34:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 990166F4; Fri, 9 Jan 2015 11:34:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sYp9ExTIbt-f; Fri, 9 Jan 2015 11:34:32 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Jan 2015 11:34:38 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5E022002C; Fri, 9 Jan 2015 11:34:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kPZPx0Mciz9Y; Fri, 9 Jan 2015 11:34:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74F7A2002F; Fri, 9 Jan 2015 11:34:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5FC313053E4B; Fri, 9 Jan 2015 11:34:39 +0100 (CET) Date: Fri, 9 Jan 2015 11:34:38 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150109103438.GA19947@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 10:34:42 -0000 We are supposed to be done in March with YANG 1.1. This is not the time to add new issues unless they are bug fixes. I do not think this is a bug fix. /js On Fri, Jan 09, 2015 at 11:25:57AM +0100, Ladislav Lhotka wrote: > Hi, > > YANG has this peculiar rule for double-quoted strings: > > If the double-quoted string contains a line break followed by space > or tab characters that are used to indent the text according to the > layout in the YANG file, this leading whitespace is stripped from the > string, up to and including the column of the double quote character, > or to the first non-whitespace character, whichever occurs first. In > this process, a tab character is treated as 8 space characters. > > As I recently found out, this kind of whitespace stripping is difficult to implement with some standard parser libraries because the parser has to be able to get the column of the opening double quote. And even if it is possible, it slows down parsing. > > The existing practice shows such multi-line strings are only used in descriptions and references where whitespace stripping is not needed at all - e.g., for translation to YIN format such strings have to be re-formatted anyway. In all other cases it is IMO much better to use concatenation > > "..." > + "..." > > So I’d suggest to remove whitespace stripping in YANG 1.1, for the benefit of parsers and the spec itself. > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 9 02:52:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78D41A874D for ; Fri, 9 Jan 2015 02:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beLRcRKA9KlI for ; Fri, 9 Jan 2015 02:52:18 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E393F1A8747 for ; Fri, 9 Jan 2015 02:52:17 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so13799871lab.13 for ; Fri, 09 Jan 2015 02:52:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CSe1dds4QCLFn8WLTk+vHXvQvNxEQJ/SsoUs1O6+eGk=; b=YhgnmJO2YnxPyRoqsmh73xi8XNlo9N9m9K400MNFqvMZnHOCo4Sm7aqdrfvhGQoDHZ qTXlwzrNomG5fkyVqQBtPWDiR2MzuK5p2cSwbalQZx4aEt/Y83Zvu3PzllpEOrZA8MJc RaHnLMK0hoaqlPulsThbM7NXRL1QQlno9Cj6GQw7Q1lf/ZycTMmcwz1LpIazHLdWrIZs PP3ZlvqTYcAfGDl7gwPGb2GZxjtUoK0E0BcRcN3/a3rMPS9Pn7y4cu7ERCwGZCK5H5zy w1+wkOMhlZluAe4ahCYRPGvyD2y4LQjTsyY2cqyXnIlAS5l7jW2chLUL93SzUhoxHUFt hNmA== X-Gm-Message-State: ALoCoQleeEAi+MROT2FORMDozNw3Gpg/enHI3qV8cH0Y7aVw7s4IVlDOrgwOcKwZt/kyhByt8leF MIME-Version: 1.0 X-Received: by 10.112.8.69 with SMTP id p5mr20717914lba.97.1420800736343; Fri, 09 Jan 2015 02:52:16 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 9 Jan 2015 02:52:16 -0800 (PST) In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E117A4FD2@xmb-aln-x08.cisco.com> References: <20150107143216.GA13482@elstar.local> <20150108.102157.2289650364805875177.mbj@tail-f.com> <0CD84218-D27C-4DB2-8E4A-8D9D651BE308@nic.cz> <013A9B371AC6DF4C8AD261897D8F243E117A4FD2@xmb-aln-x08.cisco.com> Date: Fri, 9 Jan 2015 02:52:16 -0800 Message-ID: From: Andy Bierman To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 10:52:21 -0000 Hi, I do not think this is a minor change to YANG so it is inappropriate for a minor update. Solutions which alter the instance-identifier data type will break NACM and this is also not a minor update change. I do not know of any real use-cases in which a value cannot be selected that means not-in-use. The "union" data-type can almost always be used to create a typedef for this purpose. There is no real operational need to suppress sending a few key leafs during a "create" operation. NETCONF is not optimized for small message size in any way. I do not think that lack of optional keys is a bug in YANG and therefore it should not be part of YANG 1.1 at all. Andy On Fri, Jan 9, 2015 at 2:29 AM, Peyman Owladi -X (powladi - Ensoft Ltd at Cisco) wrote: > >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: 08 January 2015 15:20 >> To: Ladislav Lhotka >> Cc: netmod@ietf.org >> Subject: Re: [netmod] VRFY :Y09: introduce optional keys >> >> On Thu, Jan 8, 2015 at 2:22 AM, Ladislav Lhotka wrote: >> > >> >> On 08 Jan 2015, at 10:21, Martin Bjorklund wrote: >> >> >> >> Hi, >> >> >> >> Juergen Schoenwaelder wrote: >> >>> The 2014-12-03 virtual interim meeting proposal is to adopt Y09-03. >> >> >> >> The reasons for proposing Y09-03 (instead of Y09-02) were: >> >> >> >> 1. The instance-identifier syntax proposed in Y09-02 doesn't work, >> >> b/c empty strings and 0-values integers would also return "true" >> >> in the expression "not(key)". >> >> >> >> But this turned out to be a false claim; the syntax proposed in >> >> Y09-02 is correct. >> >> >> >> 2. Y09-02 is tricky to implement in "common databases", since they >> >> require values for all keys. >> > >> > In some common databases (e.g. mongodb) a declaration of a key is just >> an instruction for the server to generate an index. I think it is more a >> limitation of NETCONF=E2=80=99s edit-config design. >> > >> > An implication for both Y09-02 and Y09-03 is that if a key is not set >> at the time a list entry is created, it cannot be set afterwards. >> > >> >> >> >> But the idea for how to handle Y09-03 in these databases was to >> >> store additional info that the default value is set. The same >> >> technique can be used to handle purely optional keys. >> >> >> >> Thus, I prefer Y09-02. >> > >> > Me too, Lada > > I think that as well as not having any downsides, Y09-02 actually address= es the set of issues better than Y09-03; sometimes there isn't a default th= at makes sense, in which case adding absence to the value space of a key is= important. > >> Neither solution works. >> I agree with David that they should not be added at all to YANG. > > Is the key concern here the handling of default values? > >> Please answer the questions below wrt/ how lists with default keys work: >> >> What if the designer does not want a list to automatically instantiate >> entries? >> How is this accomplished? > > If we do have defaults, I would have thought that having a default value = for a key shouldn't mean a list entry is automatically instantiated -- i.e.= there should still be no list entries until they are explicitly created. > > Perhaps this could be made explicit by requiring that at least one key ha= s no default value? > >> typedef X { >> type int32; >> default 42; >> } >> >> list broken { >> key x; >> leaf x { type X; } >> leaf y { type string; mandatory true; } >> } >> >> Does the server automatically create a default entry for x=3D42? >> If so, then isn't the mandatory-stmt violated immediately? >> Are must-stmts in the default key leaf evaluated? >> >> Are requests for list "broken" allowed to omit the >> leaf? Is the server supposed to fill in x=3D42 in such cases? > > Per RFC6020 section 7.6.1: > > "... if the leaf's type has > a default value, and the leaf is not mandatory, then the leaf's > default value is the type's default value. In all other cases, the > leaf does not have a default value." > > So in this example, since the leaf is mandatory, the default value is ign= ored, and the client must specify a value. (Otherwise this same problem wou= ld apply to any leaf in the list.) > > Cheers, > Peyman > >> >> >> >> /martin >> >> >> Andy >> >> >> >> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> > >> > >> > >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 9 04:20:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A091A8789 for ; Fri, 9 Jan 2015 04:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHNSJCTrBn4y for ; Fri, 9 Jan 2015 04:20:10 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6BA1A878B for ; Fri, 9 Jan 2015 04:20:07 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 03F6D1280056; Fri, 9 Jan 2015 13:20:03 +0100 (CET) Date: Fri, 09 Jan 2015 13:20:02 +0100 (CET) Message-Id: <20150109.132002.2120454718067291504.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <013A9B371AC6DF4C8AD261897D8F243E117A4FD2@xmb-aln-x08.cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 12:20:13 -0000 Hi, Andy Bierman wrote: > Hi, > > I do not think this is a minor change to YANG so it is > inappropriate for a minor update. > > Solutions which alter the instance-identifier data type will > break NACM and this is also not a minor update change. It is correct that in order to use YANG 1.1 optional keys w/ NACM, NACM needs to be updated to YANG version 1.1. But this update may happen anyway - see http://www.ietf.org/mail-archive/web/netconf/current/msg09669.html > I do not know of any real use-cases in which a value > cannot be selected that means not-in-use. As soon as the key has type 'string', you need to pick an "unlikely" value, e.g. the empty string or some weird string like "$__$". This is not very pretty. Also, one reason for YANG's success so far is that it is possible to closely follow the native (CLI) interface on the devices. (compare w/ MIBs). Many CLIs have the concept of optional keys, and it is pretty natural concept. > There is no real operational need to suppress sending > a few key leafs during a "create" operation. NETCONF > is not optimized for small message size in any way. This is not the reason; the reason is that the resulting model is more "direct" and clear, with less noise. /martin From nobody Fri Jan 9 05:34:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E71A879C for ; Fri, 9 Jan 2015 05:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUZBmx7Lb8lh for ; Fri, 9 Jan 2015 05:34:06 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799511A00F4 for ; Fri, 9 Jan 2015 05:34:06 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so8083099lbv.0 for ; Fri, 09 Jan 2015 05:34:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SjbVnWG0amB7GSo+aPHqq1ymE0pWZkUWAbQQ+Jw9cqQ=; b=TM70b5EbcXkrVEqZus3cJIMVE2ABaGv3Wlbrn/mhXRZ7Vd6iPZnAghpcjFs3lRsVuS Pe9rr5kR+bBhioGJHunl6yMf1dD1xgL+cUmwgDpEQV/k1uBTiylpq70u//YjWtC5NOhB bir8qqSNcnUsEjtTgraRDNtPhKzlc7ZVw4vsR83Jb33r8+fAs7botcUO556JgTS/HOtw kVuKQli0e075zK9VS/FRWbM8L83j7qRCLHTk4EuQd+l3h5L8t+SXhCsmV3F2daUeTJDd KJ7AMAV0AXcgfvCZBNuSb8rKRq9SznTJRL33WdeDlb21flRiQlkYm8qQsnpkOuYLvzMq fSQw== X-Gm-Message-State: ALoCoQlnXOYetZRZFqVUAT370YKp2jdw103tblOWoHbObRu9QHWM5mw4/AyEvmvt1H3khgdagig0 MIME-Version: 1.0 X-Received: by 10.152.87.142 with SMTP id ay14mr21523766lab.45.1420810444733; Fri, 09 Jan 2015 05:34:04 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 9 Jan 2015 05:34:04 -0800 (PST) In-Reply-To: <20150109.132002.2120454718067291504.mbj@tail-f.com> References: <013A9B371AC6DF4C8AD261897D8F243E117A4FD2@xmb-aln-x08.cisco.com> <20150109.132002.2120454718067291504.mbj@tail-f.com> Date: Fri, 9 Jan 2015 05:34:04 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 13:34:08 -0000 On Fri, Jan 9, 2015 at 4:20 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I do not think this is a minor change to YANG so it is >> inappropriate for a minor update. >> >> Solutions which alter the instance-identifier data type will >> break NACM and this is also not a minor update change. > > It is correct that in order to use YANG 1.1 optional keys w/ NACM, > NACM needs to be updated to YANG version 1.1. > > But this update may happen anyway - see > http://www.ietf.org/mail-archive/web/netconf/current/msg09669.html > > >> I do not know of any real use-cases in which a value >> cannot be selected that means not-in-use. > > As soon as the key has type 'string', you need to pick an "unlikely" > value, e.g. the empty string or some weird string like "$__$". This > is not very pretty. > It should be easy to pick the zero-length string since this should never be used as an identifier string in a key. There are no use cases where zero-length string is an important value. > Also, one reason for YANG's success so far is that it is possible to > closely follow the native (CLI) interface on the devices. (compare w/ > MIBs). Many CLIs have the concept of optional keys, and it is pretty > natural concept. > It is a big change and is not really needed. CLI is ad-hoc and non-standard. Not sure why it is relevant here. > >> There is no real operational need to suppress sending >> a few key leafs during a "create" operation. NETCONF >> is not optimized for small message size in any way. > > This is not the reason; the reason is that the resulting model is more > "direct" and clear, with less noise. > So it is slightly more elegant than the existing workaround. IMO that is not worth much. Unlike if-feature expressions, you have not come up with a single example that cannot easily be accomplished with YANG 1.0. > > /martin Andy From nobody Fri Jan 9 05:48:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD771A8789 for ; Fri, 9 Jan 2015 05:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fMPqIrFaE3N for ; Fri, 9 Jan 2015 05:47:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374021A877B for ; Fri, 9 Jan 2015 05:47:53 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 6972A140A83; Fri, 9 Jan 2015 14:47:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420811271; bh=NUNl6Dk4GAuquND27SBF821NTolxomQrGY5GaYBHns4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=m1P7AChkeW+YqlhNuFy90SCiB8UGjrZYR3H9it/wmLv/XmTrGldIfdOyAB6B62eWM 1eM85Vp7QFW6UfLPD/8U06c2p0aRGxqVtMbzEiQZEjCDIUaU5WeVNSmxsNulJsrvYU 63kOWtAHMgPNGPgCsnyTUNuizL4XxyXFFdI0TtDw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150109103438.GA19947@elstar.local> Date: Fri, 9 Jan 2015 14:47:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> References: <20150109103438.GA19947@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 13:47:58 -0000 > On 09 Jan 2015, at 11:34, Juergen Schoenwaelder = wrote: >=20 > We are supposed to be done in March with YANG 1.1. This is not the > time to add new issues unless they are bug fixes. >=20 > I do not think this is a bug fix. Guess what: even pyang=E2=80=99s parser doesn=E2=80=99t implement this = CLR correctly, and that tells you something - it doesn=E2=80=99t take = into account that a tab is equivalent to eight spaces. If some applications need this kind of trimming, they should do it = themselves and not impose it on the parser. This fancy feature just adds = extra complexity that=E2=80=99s not needed at all. Lada >=20 > /js >=20 > On Fri, Jan 09, 2015 at 11:25:57AM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> YANG has this peculiar rule for double-quoted strings: >>=20 >> If the double-quoted string contains a line break followed by space >> or tab characters that are used to indent the text according to the >> layout in the YANG file, this leading whitespace is stripped from = the >> string, up to and including the column of the double quote = character, >> or to the first non-whitespace character, whichever occurs first. = In >> this process, a tab character is treated as 8 space characters. >>=20 >> As I recently found out, this kind of whitespace stripping is = difficult to implement with some standard parser libraries because the = parser has to be able to get the column of the opening double quote. And = even if it is possible, it slows down parsing. >>=20 >> The existing practice shows such multi-line strings are only used in = descriptions and references where whitespace stripping is not needed at = all - e.g., for translation to YIN format such strings have to be = re-formatted anyway. In all other cases it is IMO much better to use = concatenation >>=20 >> "..." >> + "..." >>=20 >> So I=E2=80=99d suggest to remove whitespace stripping in YANG 1.1, = for the benefit of parsers and the spec itself. >>=20 >> Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 05:49:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E441A879C for ; Fri, 9 Jan 2015 05:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PftO9ZqtGGIE for ; Fri, 9 Jan 2015 05:49:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD981A877B for ; Fri, 9 Jan 2015 05:49:52 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 776BD1280052; Fri, 9 Jan 2015 14:49:51 +0100 (CET) Date: Fri, 09 Jan 2015 14:49:51 +0100 (CET) Message-Id: <20150109.144951.1213736659707093011.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150109.132002.2120454718067291504.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 13:49:54 -0000 Andy Bierman wrote: > So it is slightly more elegant than the existing workaround. > IMO that is not worth much. Unlike if-feature expressions, > you have not come up with a single example that cannot > easily be accomplished with YANG 1.0. I argue that using dummy values that means that the key really doesn't exist is not "easily accomplished". But here's an example from a previous email: list address { key "ip vrf"; leaf ip { ... } leaf vrf { if-feature vrf; ... } ... } Even without the if-feature statement, this gets ugly in YANG 1.0. /martin From nobody Fri Jan 9 06:37:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64951A89FC for ; Fri, 9 Jan 2015 06:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNOn6Avkjf-J for ; Fri, 9 Jan 2015 06:37:47 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0CC11A89B5 for ; Fri, 9 Jan 2015 06:37:47 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so15115133lab.9 for ; Fri, 09 Jan 2015 06:37:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZoaDXPzhTb/cIYmXS5ZJ/jnd73l34G732j296cYlP28=; b=SHv+fqRzFQLtuTNZp8TyEwULafhEv7OJX87Di8w+7LkityuE+08X1JI0lnrwtbx3Wb dhws5MibmYBCDZyNBDKwPZP9ezT80RQRMXyAe+Xb16NC2NUrr4RCevWSz46BgW5jHO7E ZxkZY0KeXNwc52v0NYeRs/cUATbtumtuTmtf5xmG09wauUXFwTy1nKXOaiuk6zi1LA/e ctx423DUD0PKGN6x8kr8TNKc1w3+SfMPCIeJfanPO67cW3tyr3mcNJVL3R7sXn9gtGlr Gp6OB+95IiugviH9wk1P1wgEfws6V7JrXlMa/yqQ3a2EvlHm83+TaNw7PsZYck+EadQT UPMQ== X-Gm-Message-State: ALoCoQkzziw9u0X5k3h2Mzrbh5Q+jtpIXdf/LYpqJFpfcVZVpiVzCgEUc/cPUepfqxr0cK2OuTDi MIME-Version: 1.0 X-Received: by 10.112.8.69 with SMTP id p5mr21768947lba.97.1420814265782; Fri, 09 Jan 2015 06:37:45 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 9 Jan 2015 06:37:45 -0800 (PST) In-Reply-To: <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> References: <20150109103438.GA19947@elstar.local> <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> Date: Fri, 9 Jan 2015 06:37:45 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:37:49 -0000 On Fri, Jan 9, 2015 at 5:47 AM, Ladislav Lhotka wrote: > >> On 09 Jan 2015, at 11:34, Juergen Schoenwaelder wrote: >> >> We are supposed to be done in March with YANG 1.1. This is not the >> time to add new issues unless they are bug fixes. >> >> I do not think this is a bug fix. > > Guess what: even pyang=E2=80=99s parser doesn=E2=80=99t implement this CL= R correctly, and that tells you something - it doesn=E2=80=99t take into ac= count that a tab is equivalent to eight spaces. > > If some applications need this kind of trimming, they should do it themse= lves and not impose it on the parser. This fancy feature just adds extra co= mplexity that=E2=80=99s not needed at all. I don't see a reason to remove the trimming requirements. It matters for a multi-line default-stmt value. It is better to make the tools deal with the whitespace, rather than the readers and writers. > > Lada > Andy >> >> /js >> >> On Fri, Jan 09, 2015 at 11:25:57AM +0100, Ladislav Lhotka wrote: >>> Hi, >>> >>> YANG has this peculiar rule for double-quoted strings: >>> >>> If the double-quoted string contains a line break followed by space >>> or tab characters that are used to indent the text according to the >>> layout in the YANG file, this leading whitespace is stripped from the >>> string, up to and including the column of the double quote character, >>> or to the first non-whitespace character, whichever occurs first. In >>> this process, a tab character is treated as 8 space characters. >>> >>> As I recently found out, this kind of whitespace stripping is difficult= to implement with some standard parser libraries because the parser has to= be able to get the column of the opening double quote. And even if it is p= ossible, it slows down parsing. >>> >>> The existing practice shows such multi-line strings are only used in de= scriptions and references where whitespace stripping is not needed at all -= e.g., for translation to YIN format such strings have to be re-formatted a= nyway. In all other cases it is IMO much better to use concatenation >>> >>> "..." >>> + "..." >>> >>> So I=E2=80=99d suggest to remove whitespace stripping in YANG 1.1, for = the benefit of parsers and the spec itself. >>> >>> Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 9 06:43:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997731A8972 for ; Fri, 9 Jan 2015 06:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSgR3ts8L32H for ; Fri, 9 Jan 2015 06:43:22 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C40201A6F12 for ; Fri, 9 Jan 2015 06:43:21 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so8378501lbd.9 for ; Fri, 09 Jan 2015 06:43:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/1wiEsaqoymVecfirqzlcAQC0uqqIqaY9Xid0Fxe9nM=; b=GK7nJTTBQbEWpG6gXCgPLLmBEyOaV0N8ZNUYYf5RlaX6Ujz8rzJPTkH3gLoks/nXes Mfh+l3e/Nf1S0Ifbaf8gfOEM2MtYanO3Ck+SxlaE9Ye4c/IJki0AeRCVOYFkll+evmxM GXBgYa8M7r8PCOQGIN8VaGhsgkNPBHqxw68YfBvibXpBsRuKQ5Yhnpz5NwjXnx5sVuZW BeBp+mhy9I4m69/FKXf5Kz4aVqN6vJHk42JnUQ2cahOORQ13huQ7RuEQgyLiakZOxrG3 4MzefH3g9fylJDWhunSHgONlsKswwy7xbKx87zPopP8mm0dizh5eAM1A6ZrilYSyXQsw aptQ== X-Gm-Message-State: ALoCoQl4ErXyzMoVanlW5tqd/Mi4Dv6u0DDBts/UkRRzanuyDaZQTJTaYP5yUA1Qu7HNpjlP71vg MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr21840297lbz.100.1420814600271; Fri, 09 Jan 2015 06:43:20 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 9 Jan 2015 06:43:20 -0800 (PST) In-Reply-To: <20150109.144951.1213736659707093011.mbj@tail-f.com> References: <20150109.132002.2120454718067291504.mbj@tail-f.com> <20150109.144951.1213736659707093011.mbj@tail-f.com> Date: Fri, 9 Jan 2015 06:43:20 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:43:23 -0000 Hi, I do not support this new feature at all, but Y09-03 is the least objectionable solution. Y09-02 is unacceptable because it requires changing a base type. IMO the list below should be redesigned so feature-dependent data is not part of the key. It is not hard to pick empty string as "no VRF". Andy On Fri, Jan 9, 2015 at 5:49 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> So it is slightly more elegant than the existing workaround. >> IMO that is not worth much. Unlike if-feature expressions, >> you have not come up with a single example that cannot >> easily be accomplished with YANG 1.0. > > I argue that using dummy values that means that the key really doesn't > exist is not "easily accomplished". But here's an example from a > previous email: > > list address { > key "ip vrf"; > leaf ip { ... } > leaf vrf { > if-feature vrf; > ... > } > ... > } > > Even without the if-feature statement, this gets ugly in YANG 1.0. > > > /martin From nobody Fri Jan 9 06:51:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AD71A89B1 for ; Fri, 9 Jan 2015 06:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EO_2oWEg3yU9 for ; Fri, 9 Jan 2015 06:51:20 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980761A9131 for ; Fri, 9 Jan 2015 06:51:19 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 3E880140A83; Fri, 9 Jan 2015 15:51:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420815078; bh=dfDlNfS6BuOIQBuec/4ddtmniPHJOfT1F+XLrxmTA74=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=o10xzYTA8EZn4n/OCxNwM5HyMA0wjp4fGQQVFCBG2YpOBgxfPMYpFBKzN+wAGFiCL 7lx2wtrlJ32/Ek6mV4nqyVeCQx2ItC8amFh4P8LMUlhi2ebe3Fuff+dWU3QekPIFCc Zt1fN8yb6NHz2ych2CfDOzSFArodG9slnZYrOpS8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Jan 2015 15:51:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150109103438.GA19947@elstar.local> <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:51:23 -0000 > On 09 Jan 2015, at 15:37, Andy Bierman wrote: >=20 > On Fri, Jan 9, 2015 at 5:47 AM, Ladislav Lhotka wrote: >>=20 >>> On 09 Jan 2015, at 11:34, Juergen Schoenwaelder = wrote: >>>=20 >>> We are supposed to be done in March with YANG 1.1. This is not the >>> time to add new issues unless they are bug fixes. >>>=20 >>> I do not think this is a bug fix. >>=20 >> Guess what: even pyang=E2=80=99s parser doesn=E2=80=99t implement = this CLR correctly, and that tells you something - it doesn=E2=80=99t = take into account that a tab is equivalent to eight spaces. >>=20 >> If some applications need this kind of trimming, they should do it = themselves and not impose it on the parser. This fancy feature just adds = extra complexity that=E2=80=99s not needed at all. >=20 >=20 > I don't see a reason to remove the trimming requirements. > It matters for a multi-line default-stmt value. default "foo bar"; Or perhaps when ". =3D 'foo bar'"; This gives me goosebumps! > It is better to make the tools deal with the whitespace, rather > than the readers and writers. Module readers and writers are not affected at all, they could continue = doing the same as before. Lada >=20 >=20 >>=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>> /js >>>=20 >>> On Fri, Jan 09, 2015 at 11:25:57AM +0100, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> YANG has this peculiar rule for double-quoted strings: >>>>=20 >>>> If the double-quoted string contains a line break followed by = space >>>> or tab characters that are used to indent the text according to = the >>>> layout in the YANG file, this leading whitespace is stripped from = the >>>> string, up to and including the column of the double quote = character, >>>> or to the first non-whitespace character, whichever occurs first. = In >>>> this process, a tab character is treated as 8 space characters. >>>>=20 >>>> As I recently found out, this kind of whitespace stripping is = difficult to implement with some standard parser libraries because the = parser has to be able to get the column of the opening double quote. And = even if it is possible, it slows down parsing. >>>>=20 >>>> The existing practice shows such multi-line strings are only used = in descriptions and references where whitespace stripping is not needed = at all - e.g., for translation to YIN format such strings have to be = re-formatted anyway. In all other cases it is IMO much better to use = concatenation >>>>=20 >>>> "..." >>>> + "..." >>>>=20 >>>> So I=E2=80=99d suggest to remove whitespace stripping in YANG 1.1, = for the benefit of parsers and the spec itself. >>>>=20 >>>> Lada >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 06:57:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58FD1A0197 for ; Fri, 9 Jan 2015 06:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x33EHjKbz_HT for ; Fri, 9 Jan 2015 06:56:56 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991F31A00E7 for ; Fri, 9 Jan 2015 06:56:55 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so14862998lab.6 for ; Fri, 09 Jan 2015 06:56:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TUeGdWLxW1rgm2rpgA+Gqle4yLRsMYQLqc9w3crbMzM=; b=Cjw56eeEZqEYazALgNeX0vzxpxbfrVM/hBQCqyhQedGUoItB1k7KThrGk76hrq4eMR 0sh+iRkRQTw/pXdvA4azPVrVvdAWdT1/hwqHVUYW8mv0TABxVLqaM06u/35BPgtZ479s cLbJFiTHXQtfofINfRqVz8qaWCUjXnFcTRwf65A7lqd5AWkrN0dyxtUYN1YwC8vR0x1Z RlwYOFAS1stVjGV4KzMX5qkfPaA5qxJrsGV5o6DXfIEgDJ2dOfypq9b99rUJkOGOOpJH jJvIglgO3O3RnsXcUpLCz/ykj7Cir3gy2tEqW2twSF49SlrCqo0Flkf0JHNdCVq2/IaQ v/9A== X-Gm-Message-State: ALoCoQlgv4+qqmLFXm9tNR5gAvM1g6Nemgz81BBwu8vBV73jLr1xzL5yWGJBNaVhSSGkjyU4DiPI MIME-Version: 1.0 X-Received: by 10.152.206.108 with SMTP id ln12mr21892491lac.3.1420815414091; Fri, 09 Jan 2015 06:56:54 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 9 Jan 2015 06:56:54 -0800 (PST) In-Reply-To: References: <20150109103438.GA19947@elstar.local> <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> Date: Fri, 9 Jan 2015 06:56:54 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 14:57:00 -0000 On Fri, Jan 9, 2015 at 6:51 AM, Ladislav Lhotka wrote: > >> On 09 Jan 2015, at 15:37, Andy Bierman wrote: >> >> On Fri, Jan 9, 2015 at 5:47 AM, Ladislav Lhotka wrote: >>> >>>> On 09 Jan 2015, at 11:34, Juergen Schoenwaelder wrote: >>>> >>>> We are supposed to be done in March with YANG 1.1. This is not the >>>> time to add new issues unless they are bug fixes. >>>> >>>> I do not think this is a bug fix. >>> >>> Guess what: even pyang=E2=80=99s parser doesn=E2=80=99t implement this = CLR correctly, and that tells you something - it doesn=E2=80=99t take into = account that a tab is equivalent to eight spaces. >>> >>> If some applications need this kind of trimming, they should do it them= selves and not impose it on the parser. This fancy feature just adds extra = complexity that=E2=80=99s not needed at all. >> >> >> I don't see a reason to remove the trimming requirements. >> It matters for a multi-line default-stmt value. > > default "foo > bar"; > > Or perhaps > > when ". =3D 'foo > bar'"; > > This gives me goosebumps! > >> It is better to make the tools deal with the whitespace, rather >> than the readers and writers. > > Module readers and writers are not affected at all, they could continue d= oing the same as before. > This takes away a feature from YANG 1.0 so IMO it breaks backward compatibi= lity. I do not think it is too difficult to implement. > Lada Andy > > >> >> >>> >>> Lada >>> >> >> Andy >> >>>> >>>> /js >>>> >>>> On Fri, Jan 09, 2015 at 11:25:57AM +0100, Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> YANG has this peculiar rule for double-quoted strings: >>>>> >>>>> If the double-quoted string contains a line break followed by space >>>>> or tab characters that are used to indent the text according to the >>>>> layout in the YANG file, this leading whitespace is stripped from th= e >>>>> string, up to and including the column of the double quote character= , >>>>> or to the first non-whitespace character, whichever occurs first. I= n >>>>> this process, a tab character is treated as 8 space characters. >>>>> >>>>> As I recently found out, this kind of whitespace stripping is difficu= lt to implement with some standard parser libraries because the parser has = to be able to get the column of the opening double quote. And even if it is= possible, it slows down parsing. >>>>> >>>>> The existing practice shows such multi-line strings are only used in = descriptions and references where whitespace stripping is not needed at all= - e.g., for translation to YIN format such strings have to be re-formatted= anyway. In all other cases it is IMO much better to use concatenation >>>>> >>>>> "..." >>>>> + "..." >>>>> >>>>> So I=E2=80=99d suggest to remove whitespace stripping in YANG 1.1, fo= r the benefit of parsers and the spec itself. >>>>> >>>>> Lada >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>>> Fax: +49 421 200 3103 >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jan 9 07:03:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02511A6F12 for ; Fri, 9 Jan 2015 07:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb0FdbbGkDEN for ; Fri, 9 Jan 2015 07:03:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6A11A89B1 for ; Fri, 9 Jan 2015 07:03:39 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:a430:281d:e5af:a838] (unknown [IPv6:2001:718:1a02:1:a430:281d:e5af:a838]) by mail.nic.cz (Postfix) with ESMTPSA id AAC3C140A83; Fri, 9 Jan 2015 16:03:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420815817; bh=vdPZ2IJbrWSi6KOv/FuNZMtaxdZoaakKCTd1pWlHStM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=P+qB/BI5kvqEJoOEMmnQ5NwC9OEQmWPFt+zDbotT9cDZnA2LmJPNMo8+xslz6AZoz a5IGVqxiWQ03YxgXVhumRVBxJvs30vCz/6gA2nIM3VGddOyN0qM9tkq2A7tY5e3NgZ 19+NP0xWHoNug8EVdcETZ9YWxyzehUBxzq5avQaQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Jan 2015 16:03:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150109.132002.2120454718067291504.mbj@tail-f.com> <20150109.144951.1213736659707093011.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 15:03:41 -0000 > On 09 Jan 2015, at 15:43, Andy Bierman wrote: >=20 > Hi, >=20 > I do not support this new feature at all, but Y09-03 is the > least objectionable solution. Y09-02 is unacceptable > because it requires changing a base type. Which base type? >=20 > IMO the list below should be redesigned so feature-dependent data > is not part of the key. It is not hard to pick empty string as "no = VRF=E2=80=9D. Y09-02 or -03 would allow for an elegant solution to the problem of the = key for static routes that was discussed in relation to the routing = module. Currently the static-route list uses only = =E2=80=9Cdestination-address=E2=80=9D as the key but it is conceivable = that it will be necessary to support multiple routes with the same = destination address. As a new key leaf cannot be added later, a solution = might be to add a dummy key now, e. g. a numeric =E2=80=9Cid=E2=80=9D = that could be used for discriminating entries where necessary. But it = only makes sense if the =E2=80=9Cid=E2=80=9D key part was optional = because adding a unique number to every route is a nuisance. Lada >=20 > Andy >=20 >=20 > On Fri, Jan 9, 2015 at 5:49 AM, Martin Bjorklund = wrote: >> Andy Bierman wrote: >>> So it is slightly more elegant than the existing workaround. >>> IMO that is not worth much. Unlike if-feature expressions, >>> you have not come up with a single example that cannot >>> easily be accomplished with YANG 1.0. >>=20 >> I argue that using dummy values that means that the key really = doesn't >> exist is not "easily accomplished". But here's an example from a >> previous email: >>=20 >> list address { >> key "ip vrf"; >> leaf ip { ... } >> leaf vrf { >> if-feature vrf; >> ... >> } >> ... >> } >>=20 >> Even without the if-feature statement, this gets ugly in YANG 1.0. >>=20 >>=20 >> /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 07:12:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939681A89FB for ; Fri, 9 Jan 2015 07:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNg-0xuEVSUq for ; Fri, 9 Jan 2015 07:12:41 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4B31A00FF for ; Fri, 9 Jan 2015 07:12:41 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ms9so14916942lab.10 for ; Fri, 09 Jan 2015 07:12:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N4x+iw/YQmYSzfROEZRiE5QPBwqvqkwnJPbsodL/LMY=; b=Q9wMQHWsjIEI1xAP3ywnwBvqtOot968Qnmytquqr4A4OVlLTBzfjPA3yEdaf5Kp2Ux FzwXfAHIHpFnjvOOEtmPdSqrLZBwuIKFv6/7nUqruas0wW8H0I7AL8ZFxykprIK8+B17 lQrpVq/0Md2T3N9A4U1euLm4F5ov3WMBppD+UIiCiOm45gotS1Tg1B4wpkMpWfxrQdPF xdK6KpzW7fJDVFZhV63j2xVaBcH1bGg0xtVAxf6zL+2RtMyUbavCxFzm9EwE4Kx9hXQt 1j88QaBpnbc0n8ckmiqCAVuISR9QulbMr64+gEX/pb7/4v5ubWgJ7keutr23xI52uDs1 TQlA== X-Gm-Message-State: ALoCoQlpkZbVL5iikBpemmKzUud6IT/cD1PgqOMwyEbY55ApgQSAhP7zGJ4BiXnsuqfZN0fRMez2 MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr21843522lam.15.1420816359492; Fri, 09 Jan 2015 07:12:39 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 9 Jan 2015 07:12:39 -0800 (PST) In-Reply-To: References: <20150109.132002.2120454718067291504.mbj@tail-f.com> <20150109.144951.1213736659707093011.mbj@tail-f.com> Date: Fri, 9 Jan 2015 07:12:39 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 15:12:46 -0000 On Fri, Jan 9, 2015 at 7:03 AM, Ladislav Lhotka wrote: > >> On 09 Jan 2015, at 15:43, Andy Bierman wrote: >> >> Hi, >> >> I do not support this new feature at all, but Y09-03 is the >> least objectionable solution. Y09-02 is unacceptable >> because it requires changing a base type. > > Which base type? > instance-identifier >> >> IMO the list below should be redesigned so feature-dependent data >> is not part of the key. It is not hard to pick empty string as "no VRF= =E2=80=9D. > > Y09-02 or -03 would allow for an elegant solution to the problem of the k= ey for static routes that was discussed in relation to the routing module. = Currently the static-route list uses only =E2=80=9Cdestination-address=E2= =80=9D as the key but it is conceivable that it will be necessary to suppor= t multiple routes with the same destination address. As a new key leaf cann= ot be added later, a solution might be to add a dummy key now, e. g. a nume= ric =E2=80=9Cid=E2=80=9D that could be used for discriminating entries wher= e necessary. But it only makes sense if the =E2=80=9Cid=E2=80=9D key part w= as optional because adding a unique number to every route is a nuisance. > > Lada > Andy >> >> Andy >> >> >> On Fri, Jan 9, 2015 at 5:49 AM, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> So it is slightly more elegant than the existing workaround. >>>> IMO that is not worth much. Unlike if-feature expressions, >>>> you have not come up with a single example that cannot >>>> easily be accomplished with YANG 1.0. >>> >>> I argue that using dummy values that means that the key really doesn't >>> exist is not "easily accomplished". But here's an example from a >>> previous email: >>> >>> list address { >>> key "ip vrf"; >>> leaf ip { ... } >>> leaf vrf { >>> if-feature vrf; >>> ... >>> } >>> ... >>> } >>> >>> Even without the if-feature statement, this gets ugly in YANG 1.0. >>> >>> >>> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jan 9 07:21:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAF51A0366 for ; Fri, 9 Jan 2015 07:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCjV7JThYZn0 for ; Fri, 9 Jan 2015 07:21:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4881A009E for ; Fri, 9 Jan 2015 07:21:55 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id A4F00140A83; Fri, 9 Jan 2015 16:21:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420816913; bh=xCKIWPgroTQI9tnPkzgVVH3qfe4IpWZgyxZ0BDdpqa0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KB1UeiT4oU2WI5LjbnM/oODwkEPlgR3IkGNRcnHVHeqNOQc4xHmv28saeHvWRV7pr MvvzmvtGnABduJc38dQd3pQZA/aaAsmsTaBee95Kl7UW+YaEvbaDe6i8cAstTYFyYS BQqI7jYoEZaFQo8NhGV6zvEitviA1K4mUxALrPZI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Jan 2015 16:21:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <591B30D1-3855-4C2C-A70C-466C22F0D613@nic.cz> References: <20150109.132002.2120454718067291504.mbj@tail-f.com> <20150109.144951.1213736659707093011.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 15:21:58 -0000 > On 09 Jan 2015, at 16:12, Andy Bierman wrote: >=20 > On Fri, Jan 9, 2015 at 7:03 AM, Ladislav Lhotka wrote: >>=20 >>> On 09 Jan 2015, at 15:43, Andy Bierman wrote: >>>=20 >>> Hi, >>>=20 >>> I do not support this new feature at all, but Y09-03 is the >>> least objectionable solution. Y09-02 is unacceptable >>> because it requires changing a base type. >>=20 >> Which base type? >>=20 >=20 > instance-identifier OK, but is only a minor extension, and doesn=E2=80=99t change the = semantics of the existing uses. Easy to do, IMO. Lada >=20 >=20 >>>=20 >>> IMO the list below should be redesigned so feature-dependent data >>> is not part of the key. It is not hard to pick empty string as "no = VRF=E2=80=9D. >>=20 >> Y09-02 or -03 would allow for an elegant solution to the problem of = the key for static routes that was discussed in relation to the routing = module. Currently the static-route list uses only = =E2=80=9Cdestination-address=E2=80=9D as the key but it is conceivable = that it will be necessary to support multiple routes with the same = destination address. As a new key leaf cannot be added later, a solution = might be to add a dummy key now, e. g. a numeric =E2=80=9Cid=E2=80=9D = that could be used for discriminating entries where necessary. But it = only makes sense if the =E2=80=9Cid=E2=80=9D key part was optional = because adding a unique number to every route is a nuisance. >>=20 >> Lada >>=20 >=20 >=20 > Andy >=20 >>>=20 >>> Andy >>>=20 >>>=20 >>> On Fri, Jan 9, 2015 at 5:49 AM, Martin Bjorklund = wrote: >>>> Andy Bierman wrote: >>>>> So it is slightly more elegant than the existing workaround. >>>>> IMO that is not worth much. Unlike if-feature expressions, >>>>> you have not come up with a single example that cannot >>>>> easily be accomplished with YANG 1.0. >>>>=20 >>>> I argue that using dummy values that means that the key really = doesn't >>>> exist is not "easily accomplished". But here's an example from a >>>> previous email: >>>>=20 >>>> list address { >>>> key "ip vrf"; >>>> leaf ip { ... } >>>> leaf vrf { >>>> if-feature vrf; >>>> ... >>>> } >>>> ... >>>> } >>>>=20 >>>> Even without the if-feature statement, this gets ugly in YANG 1.0. >>>>=20 >>>>=20 >>>> /martin >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 08:51:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654BF1A87CE for ; Fri, 9 Jan 2015 08:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYq2BIfo0CdM for ; Fri, 9 Jan 2015 08:50:58 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E1C1A6FCB for ; Fri, 9 Jan 2015 08:50:58 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so15392451lab.13 for ; Fri, 09 Jan 2015 08:50:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L/68nnb9RpPWTb6mShthnaO+/wMloHvf5CEy6K6jNAg=; b=djQ915mhw4WELBVzFGpV88Hsm7FKXr3tP/TgXTPLy3Ob8mHeWvkBA3yZwkYUo70F+o X0e8fuY41GLoaPQYQYryhPS+AvjKUDFxnhhIDH2rvAh5QiHugTTglJkRyhdnJ6kpENoh K5BykwJaG/JkzQ3wj1vRmSIajQ8vWM6A5OGzGEfjSM7Rlb9bSxyDjWDwOKyHmQfWTXSk hsmWnqtDwbWPJlUev367vV4L0bQqvGs2LDFlqO+8+1mC+jSWEo3+4uVp9AApwqZgArRu DrvCkqC9jpT4NoXnIquxP+RfEA4H0Zg7aTAyTYc3GjLxB0nd708OL3aKRHZ5yVWeir7B 818g== X-Gm-Message-State: ALoCoQn5ClB0lENzfFSWlaK4SD71Mh9DEhUt06VvyvaPvpXe3Oqp1wAGvpC55YljmKyK0ieOeL8R MIME-Version: 1.0 X-Received: by 10.112.12.65 with SMTP id w1mr22517697lbb.68.1420822256418; Fri, 09 Jan 2015 08:50:56 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 9 Jan 2015 08:50:56 -0800 (PST) In-Reply-To: <591B30D1-3855-4C2C-A70C-466C22F0D613@nic.cz> References: <20150109.132002.2120454718067291504.mbj@tail-f.com> <20150109.144951.1213736659707093011.mbj@tail-f.com> <591B30D1-3855-4C2C-A70C-466C22F0D613@nic.cz> Date: Fri, 9 Jan 2015 08:50:56 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 16:51:00 -0000 On Fri, Jan 9, 2015 at 7:21 AM, Ladislav Lhotka wrote: > >> On 09 Jan 2015, at 16:12, Andy Bierman wrote: >> >> On Fri, Jan 9, 2015 at 7:03 AM, Ladislav Lhotka wrote: >>> >>>> On 09 Jan 2015, at 15:43, Andy Bierman wrote: >>>> >>>> Hi, >>>> >>>> I do not support this new feature at all, but Y09-03 is the >>>> least objectionable solution. Y09-02 is unacceptable >>>> because it requires changing a base type. >>> >>> Which base type? >>> >> >> instance-identifier > > OK, but is only a minor extension, and doesn=E2=80=99t change the semanti= cs of the existing uses. Easy to do, IMO. > I do not agree that it is minor at all. It would significantly impact the server design and implementation which assumes that all list instances use all keys. Both solutions undo this MUST in 7.8.2: All key leafs MUST be given values when a list entry is created. IMO this enhancement is minor in value but major in system and conformance impact. > Lada Andy > >> >> >>>> >>>> IMO the list below should be redesigned so feature-dependent data >>>> is not part of the key. It is not hard to pick empty string as "no VR= F=E2=80=9D. >>> >>> Y09-02 or -03 would allow for an elegant solution to the problem of the= key for static routes that was discussed in relation to the routing module= . Currently the static-route list uses only =E2=80=9Cdestination-address=E2= =80=9D as the key but it is conceivable that it will be necessary to suppor= t multiple routes with the same destination address. As a new key leaf cann= ot be added later, a solution might be to add a dummy key now, e. g. a nume= ric =E2=80=9Cid=E2=80=9D that could be used for discriminating entries wher= e necessary. But it only makes sense if the =E2=80=9Cid=E2=80=9D key part w= as optional because adding a unique number to every route is a nuisance. >>> >>> Lada >>> >> >> >> Andy >> >>>> >>>> Andy >>>> >>>> >>>> On Fri, Jan 9, 2015 at 5:49 AM, Martin Bjorklund wrot= e: >>>>> Andy Bierman wrote: >>>>>> So it is slightly more elegant than the existing workaround. >>>>>> IMO that is not worth much. Unlike if-feature expressions, >>>>>> you have not come up with a single example that cannot >>>>>> easily be accomplished with YANG 1.0. >>>>> >>>>> I argue that using dummy values that means that the key really doesn'= t >>>>> exist is not "easily accomplished". But here's an example from a >>>>> previous email: >>>>> >>>>> list address { >>>>> key "ip vrf"; >>>>> leaf ip { ... } >>>>> leaf vrf { >>>>> if-feature vrf; >>>>> ... >>>>> } >>>>> ... >>>>> } >>>>> >>>>> Even without the if-feature statement, this gets ugly in YANG 1.0. >>>>> >>>>> >>>>> /martin >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jan 9 08:57:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D03B1A7D82 for ; Fri, 9 Jan 2015 08:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0sQjVVmyI-Q for ; Fri, 9 Jan 2015 08:57:25 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357D91A6F87 for ; Fri, 9 Jan 2015 08:57:25 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id CFE89140A83; Fri, 9 Jan 2015 17:57:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420822643; bh=+7jLWv/nZNNd6OkvhFJItRidZah8O9FzzLHgNNZH0H0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ucu8Xrk1u02m7QaukfPlDmRB84ZjNcYgFw5NKRg+u+cadxv430EHKfIIt9Ne2FCee BBne+rQTxOWLVTzcqlXnWNXiDNc0Sr13eN5S7VlCjmvyPAhPKJfjv+sI1Je24hsfRt PNCRgMDQHqx5JyS8ya2R1r/5e5QwwIRcKgPNytEI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 9 Jan 2015 17:57:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150109.132002.2120454718067291504.mbj@tail-f.com> <20150109.144951.1213736659707093011.mbj@tail-f.com> <591B30D1-3855-4C2C-A70C-466C22F0D613@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 16:57:27 -0000 > On 09 Jan 2015, at 17:50, Andy Bierman wrote: >=20 > On Fri, Jan 9, 2015 at 7:21 AM, Ladislav Lhotka wrote: >>=20 >>> On 09 Jan 2015, at 16:12, Andy Bierman wrote: >>>=20 >>> On Fri, Jan 9, 2015 at 7:03 AM, Ladislav Lhotka = wrote: >>>>=20 >>>>> On 09 Jan 2015, at 15:43, Andy Bierman wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I do not support this new feature at all, but Y09-03 is the >>>>> least objectionable solution. Y09-02 is unacceptable >>>>> because it requires changing a base type. >>>>=20 >>>> Which base type? >>>>=20 >>>=20 >>> instance-identifier >>=20 >> OK, but is only a minor extension, and doesn=E2=80=99t change the = semantics of the existing uses. Easy to do, IMO. >>=20 >=20 > I do not agree that it is minor at all. > It would significantly impact the server design and implementation > which assumes that all list instances use all keys. My comment was about the extension of instance-identifier syntax and = their interpretation. Otherwise I agree that the changes induced by = optional keys may be non-trivial. Lada >=20 > Both solutions undo this MUST in 7.8.2: >=20 > All key leafs MUST be given values when a list entry is created. >=20 > IMO this enhancement is minor in value but major in system > and conformance impact. >=20 >=20 >=20 >> Lada >=20 > Andy >=20 >>=20 >>>=20 >>>=20 >>>>>=20 >>>>> IMO the list below should be redesigned so feature-dependent data >>>>> is not part of the key. It is not hard to pick empty string as = "no VRF=E2=80=9D. >>>>=20 >>>> Y09-02 or -03 would allow for an elegant solution to the problem of = the key for static routes that was discussed in relation to the routing = module. Currently the static-route list uses only = =E2=80=9Cdestination-address=E2=80=9D as the key but it is conceivable = that it will be necessary to support multiple routes with the same = destination address. As a new key leaf cannot be added later, a solution = might be to add a dummy key now, e. g. a numeric =E2=80=9Cid=E2=80=9D = that could be used for discriminating entries where necessary. But it = only makes sense if the =E2=80=9Cid=E2=80=9D key part was optional = because adding a unique number to every route is a nuisance. >>>>=20 >>>> Lada >>>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>> On Fri, Jan 9, 2015 at 5:49 AM, Martin Bjorklund = wrote: >>>>>> Andy Bierman wrote: >>>>>>> So it is slightly more elegant than the existing workaround. >>>>>>> IMO that is not worth much. Unlike if-feature expressions, >>>>>>> you have not come up with a single example that cannot >>>>>>> easily be accomplished with YANG 1.0. >>>>>>=20 >>>>>> I argue that using dummy values that means that the key really = doesn't >>>>>> exist is not "easily accomplished". But here's an example from a >>>>>> previous email: >>>>>>=20 >>>>>> list address { >>>>>> key "ip vrf"; >>>>>> leaf ip { ... } >>>>>> leaf vrf { >>>>>> if-feature vrf; >>>>>> ... >>>>>> } >>>>>> ... >>>>>> } >>>>>>=20 >>>>>> Even without the if-feature statement, this gets ugly in YANG = 1.0. >>>>>>=20 >>>>>>=20 >>>>>> /martin >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 13:01:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AFE1A03C7 for ; Fri, 9 Jan 2015 13:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwXUeMp_Fe0O for ; Fri, 9 Jan 2015 13:01:41 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA991A03A1 for ; Fri, 9 Jan 2015 13:01:40 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 60DCDE095CF95; Fri, 9 Jan 2015 21:01:35 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t09L1bd8019206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 16:01:37 -0500 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 9 Jan 2015 16:01:36 -0500 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] VRFY :Y16: module advertisement optimization Thread-Index: AQHQKob0JUmYGFy4rUOnAxO4aFq6Npy4R0MQ Date: Fri, 9 Jan 2015 21:01:36 +0000 Message-ID: References: <20150107143343.GB13482@elstar.local> In-Reply-To: <20150107143343.GB13482@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] VRFY :Y16: module advertisement optimization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 21:01:43 -0000 Is there a potential race condition between receiving the and the results of the ? I suppose this is pretty unlikely in most servers but if any future servers= have capabilities that can change somewhat dynamically then we may want to= include the in the response to the request (to bind the capabilities to a signature) so the client c= an do a double check that they are still working with the same . The hello should still include the . On another note -> is there any need out there to allow a server to adverti= se (async) to a client that it's capabilities have changed ? I could imag= ine, for example, a system that supports in service upgrades (and manages t= o keep the NETCONF session going during the upgrade) could suddenly have so= me different capabilities. Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Wednesday, January 07, 2015 9:34 AM To: netmod@ietf.org Subject: [netmod] VRFY :Y16: module advertisement optimization The 2014-12-03 virtual interim meeting proposal is to adopt Y16-03. Please speak up by Wednesday 2015-01-14 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minut= es available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 9 14:59:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5832E1A1A75 for ; Fri, 9 Jan 2015 14:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkzVokx2W6S3 for ; Fri, 9 Jan 2015 14:59:01 -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 A7A181A1AA9 for ; Fri, 9 Jan 2015 14:58:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNU36424; Fri, 09 Jan 2015 22:58:57 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 Jan 2015 22:58:56 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Fri, 9 Jan 2015 14:58:44 -0800 From: Linda Dunbar To: "netmod@ietf.org" , "deanb@juniper.net" , "kkoushik@brocade.com" , "yihuan@cisco.com" , "dblair@cisco.com" Thread-Topic: Questions to draft-ietf-netmod-acl-model-00 Thread-Index: AdAsX9CwibQXa732QGuEkrDUKZcJng== Date: Fri, 9 Jan 2015 22:58:43 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645E8E3DD@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.208] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645E8E3DDdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Questions to draft-ietf-netmod-acl-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 22:59:03 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645E8E3DDdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dean, et al, On Page 15, the definition of "metadata" missed potential matching criteria= of "packet length", which is described in the "metadata" definition. Is it possible to add more constraints, such as "apply ACL when there is co= ngestion", etc? On Page 12, the "acl-transport-header-fields" only allows port range. If th= e matching criteria is a specific port number, is it still necessary to hav= e both "lower-port" and "upper-port" specified? On Figure 2 (Page 18), the "" below "" should really be "= ", isn't it? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645E8E3DDdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean, et al,

 

On Page 15, the definition of “metadata”= missed potential matching criteria of “packet length”, which i= s described in the “metadata” definition.

Is it possible to add more constraints, such as R= 20;apply ACL when there is congestion”, etc?

 

 

On Page 12, the “acl-transport-header-fields&#= 8221; only allows port range. If the matching criteria is a specific port n= umber, is it still necessary to have both “lower-port” and R= 20;upper-port” specified?

 

 

On Figure 2 (Page 18), the “<actions/>&#= 8221;  below “<deny/>” should really be “</= action>”, isn’t it?

 

 

Thanks, Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F645E8E3DDdfweml701chm_-- From nobody Fri Jan 9 15:39:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60401A3BA7 for ; Fri, 9 Jan 2015 15:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1vyK-81Z9NG for ; Fri, 9 Jan 2015 15:39:40 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DCE1A1BDE for ; Fri, 9 Jan 2015 15:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11395; q=dns/txt; s=iport; t=1420846779; x=1422056379; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=GxOHnITmxmhoeF32v11gDl4u/UiX6RSxff7N3niKGwc=; b=GgoHiRs/LJEskEeRThHQV5jz17nqM1VrY9XUEZJggsFhZjpIE8jr7TGk G8hFzAWfE9oz6m50YJJyrMHZKwNnW67X9gp1dHaiRgU7ylHzkvF9OQsCQ 1ekZVF+fbrrSMXxsY/fA0iwj8++XtvzZbJ9L9EvOggf/YZMt4pA5ac5eL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYEAHVlsFStJssW/2dsb2JhbABbg1hYxgmFbwKBWQEBAQEBfYQMAQEBBG4KDQQcAwECChYPCQMCAQIBOwIIBg0GAgEBBQuIGA3KUQEBAQEBAQEDAQEBAQEBARuPKAEBPhgGhCMFl0OBDoJxgheLXiKDbz0xAYEEBxcGgRoBAQE X-IronPort-AV: E=Sophos;i="5.07,734,1413244800"; d="scan'208,217";a="301557830" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 09 Jan 2015 23:39:37 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t09Ndawd020303 for ; Fri, 9 Jan 2015 23:39:36 GMT Message-ID: <54B066B8.8000705@cisco.com> Date: Sat, 10 Jan 2015 00:39:36 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETMOD Working Group References: <54B0667E.9040404@cisco.com> In-Reply-To: <54B0667E.9040404@cisco.com> X-Forwarded-Message-Id: <54B0667E.9040404@cisco.com> Content-Type: multipart/alternative; boundary="------------090402090500060609050604" Archived-At: Subject: [netmod] Fwd: YANG Model Coordination Group - seeking candidates X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 23:39:43 -0000 This is a multi-part message in MIME format. --------------090402090500060609050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. Sorry for the potential duplicates. Regards, Benoit -------- Original Message -------- Subject: YANG Model Coordination Group - seeking candidates Date: Sat, 10 Jan 2015 00:38:38 +0100 From: Benoit Claise To: IETF-Discussion list Dear all, You may have seen this "IESG YANG Model Work Redistribution" message [1]: A YANG Model Coordination group (a RFC2418 directorate) will be created by the IESG to assist the AD and complement the work of the YANG Doctors, Operations and Management Directorate, Routing Area Directorate, and IAB liaison managers. The YANG doctors' responsibility to validate models remains unchanged. The YANG Model Coordination group will consist of three members and report to the Operations and Management AD that is responsible for the YANG Model work. The OPS ADs, in collaboration with the Routing ADs (since there is much routing-related YANG modeling work) will select candidates for this YANG Model Coordination Group. The high level mission is: Help with the development and coordination of the numerous YANG models within the IETF, and the promotion of YANG modeling in the industry. Practically, we seek candidates: - Familiar with YANG, - Familiar with the IETF, - Connected with (or aware of) the YANG data modeling efforts in the industry, - Connected to YANG models implementation, - Ready to commit approximately 1/3 of a full time job, for a period of one year. The role of the YANG Model Coordination group will be re-assessed after one year and may be continued. If so, new nominations will be sought and existing members of the group will be able to stand again or step down. The job description consists of: - Compiling, publishing, and maintaining an inventory of YANG models both produced by the IETF and available at other locations. - Evaluating and documenting how the existing YANG models fit together. Example: can the IGP, QoS, and ACL YANG models work together? - Documenting and tracking open issues (especially the issues crossing drafts, WGs, and areas) including issues of interaction and overlap of YANG models. - Generating and leading the discussions on the resolution of the open issues, in collaboration with the authors, WGs, WG chairs, YANG doctors, rtg-yang-coord mailing list, and the appropriate ADs - Participating in YANG model related design teams, as needed, to assist in the coordination as well as technical work. - Assisting with the coordination of design teams working to produce YANG models that describe and enable the provisioning and management of services. - Documenting and tracking functionality missing from YANG models including entire missing models. - Documenting YANG issues arising from YANG models - Producing monthly reports for the IETF community and present a summary of progress at each IETF meeting in the OPS-AREA meeting. - Close work with the OPS AD on building a community of YANG modelers that will bring YANG work into the IETF as appropriate, and that will enable interactions between IETF YANG models and models produced outside the IETF . Note that the practical details of the daily job will be discussed with the candidates. If you are ready for the challenge, please let the Routing and OPS ADs know ("ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" ). We will accept candidates for a two weeks period starting now. The selected candidates will be announced soon after. Regards, Alia, Adrian, Joel, and Benoit [1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13576.html --------------090402090500060609050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.
Sorry for the potential duplicates.

Regards, Benoit


-------- Original Message --------
Subject: YANG Model Coordination Group - seeking candidates
Date: Sat, 10 Jan 2015 00:38:38 +0100
From: Benoit Claise <bclaise@cisco.com>
To: IETF-Discussion list <ietf@ietf.org>


Dear all,

You may have seen this "IESG YANG Model Work Redistribution" message [1]:

A YANG Model Coordination group (a RFC2418 directorate) will be created by the IESG to assist the AD and complement the work of the YANG Doctors, Operations and Management Directorate, Routing Area Directorate, and IAB liaison managers. The YANG doctors' responsibility to validate models remains unchanged. The YANG Model Coordination group will consist of three members and report to the Operations and Management AD that is responsible for the YANG Model work.

The OPS ADs, in collaboration with the Routing ADs (since there is much routing-related YANG modeling work) will select candidates for this YANG Model Coordination Group.

The high level mission is:
Help with the development and coordination of the numerous YANG models within the IETF, and the promotion of YANG modeling in the industry.
Practically, we seek candidates:
- Familiar with YANG,
- Familiar with the IETF,
- Connected with (or aware of) the YANG data modeling efforts in the industry,
- Connected to YANG models implementation,
- Ready to commit approximately 1/3 of a full time job, for a period of one year. The role of the YANG Model Coordination group will be re-assessed after one year and may be continued. If so, new nominations will be sought and existing members of the group will be able to stand again or step down.

The job description consists of:
- Compiling, publishing, and maintaining an inventory of YANG models both produced by the IETF and available at other locations.    
- Evaluating and documenting how the existing YANG models fit together.
  Example: can the IGP, QoS, and ACL YANG models work together?
- Documenting and tracking open issues (especially the issues crossing drafts, WGs, and areas) including issues of interaction and overlap of YANG models.
- Generating and leading the discussions on the resolution of the open issues, in collaboration with the authors, WGs, WG chairs, YANG doctors, rtg-yang-coord mailing list, and the appropriate ADs
- Participating in YANG model related design teams, as needed, to assist in the coordination as well as technical work.
- Assisting with the coordination of design teams working to produce YANG models that describe and enable the provisioning and management of services.
- Documenting and tracking functionality missing from YANG models including entire missing models.
- Documenting YANG issues arising from YANG models
- Producing monthly reports for the IETF community and present a summary of progress at each IETF meeting in the OPS-AREA meeting.
- Close work with the OPS AD on building a community of YANG modelers that will bring YANG work into the IETF as appropriate, and that will enable interactions between IETF YANG models and models produced outside the IETF .
Note that the practical details of the daily job will be discussed with the candidates.
  
If you are ready for the challenge, please let the Routing and OPS ADs know ("ops-ads@tools.ietf.org" <ops-ads@tools.ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>).

We will accept candidates for a two weeks period starting now. The selected candidates will be announced soon after.

Regards, Alia, Adrian, Joel, and Benoit


[1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13576.html






--------------090402090500060609050604-- From nobody Fri Jan 9 22:16:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905031A1B62 for ; Fri, 9 Jan 2015 22:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57l0SCPvYP7q for ; Fri, 9 Jan 2015 22:16:50 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 242901A1B60 for ; Fri, 9 Jan 2015 22:16:48 -0800 (PST) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 6D3D61CC006D; Sat, 10 Jan 2015 07:16:55 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20150109103438.GA19947@elstar.local> <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Sat, 10 Jan 2015 07:16:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 06:16:55 -0000 Andy Bierman writes: > On Fri, Jan 9, 2015 at 5:47 AM, Ladislav Lhotka wrote: >> >>> On 09 Jan 2015, at 11:34, Juergen Schoenwaelder wrote: >>> >>> We are supposed to be done in March with YANG 1.1. This is not the >>> time to add new issues unless they are bug fixes. >>> >>> I do not think this is a bug fix. >> >> Guess what: even pyang=E2=80=99s parser doesn=E2=80=99t implement this C= LR correctly, and that tells you something - it doesn=E2=80=99t take into a= ccount that a tab is equivalent to eight spaces. >> >> If some applications need this kind of trimming, they should do it thems= elves and not impose it on the parser. This fancy feature just adds extra c= omplexity that=E2=80=99s not needed at all. > > > I don't see a reason to remove the trimming requirements. > It matters for a multi-line default-stmt value. Actually, it is outright broken: I guess the meaning of a module should not depend on the indentation of its statements, but it is not the case here: default "foo\n\t\tbar"; # two spaces of indentation gives a different default value than default "foo\n\t\tbar"; # four spaces of indentation Isn't this a clear bug? Lada > It is better to make the tools deal with the whitespace, rather > than the readers and writers. > > >> >> Lada >> > > Andy > >>> >>> /js >>> >>> On Fri, Jan 09, 2015 at 11:25:57AM +0100, Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> YANG has this peculiar rule for double-quoted strings: >>>> >>>> If the double-quoted string contains a line break followed by space >>>> or tab characters that are used to indent the text according to the >>>> layout in the YANG file, this leading whitespace is stripped from the >>>> string, up to and including the column of the double quote character, >>>> or to the first non-whitespace character, whichever occurs first. In >>>> this process, a tab character is treated as 8 space characters. >>>> >>>> As I recently found out, this kind of whitespace stripping is difficul= t to implement with some standard parser libraries because the parser has t= o be able to get the column of the opening double quote. And even if it is = possible, it slows down parsing. >>>> >>>> The existing practice shows such multi-line strings are only used in d= escriptions and references where whitespace stripping is not needed at all = - e.g., for translation to YIN format such strings have to be re-formatted = anyway. In all other cases it is IMO much better to use concatenation >>>> >>>> "..." >>>> + "..." >>>> >>>> So I=E2=80=99d suggest to remove whitespace stripping in YANG 1.1, for= the benefit of parsers and the spec itself. >>>> >>>> Lada >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 9 22:34:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8F1A6FFA for ; Fri, 9 Jan 2015 22:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JozVk_qhvVco for ; Fri, 9 Jan 2015 22:34:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07BC01A1EF1 for ; Fri, 9 Jan 2015 22:34:37 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 026611280056; Sat, 10 Jan 2015 07:34:36 +0100 (CET) Date: Sat, 10 Jan 2015 07:34:48 +0100 (CET) Message-Id: <20150110.073448.946284028415215453.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 06:34:38 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gQW5keSBCaWVybWFuIDxh bmR5QHl1bWF3b3Jrcy5jb20+IHdyaXRlczoNCj4gDQo+ID4gT24gRnJpLCBKYW4gOSwgMjAxNSBh dCA1OjQ3IEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+Pg0K PiA+Pj4gT24gMDkgSmFuIDIwMTUsIGF0IDExOjM0LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4g V2UgYXJlIHN1cHBvc2VkIHRvIGJlIGRvbmUgaW4gTWFyY2ggd2l0aCBZQU5HIDEuMS4gVGhpcyBp cyBub3QgdGhlDQo+ID4+PiB0aW1lIHRvIGFkZCBuZXcgaXNzdWVzIHVubGVzcyB0aGV5IGFyZSBi dWcgZml4ZXMuDQo+ID4+Pg0KPiA+Pj4gSSBkbyBub3QgdGhpbmsgdGhpcyBpcyBhIGJ1ZyBmaXgu DQo+ID4+DQo+ID4+IEd1ZXNzIHdoYXQ6IGV2ZW4gcHlhbmfigJlzIHBhcnNlciBkb2VzbuKAmXQg aW1wbGVtZW50IHRoaXMgQ0xSIGNvcnJlY3RseSwgYW5kIHRoYXQgdGVsbHMgeW91IHNvbWV0aGlu ZyAtIGl0IGRvZXNu4oCZdCB0YWtlIGludG8gYWNjb3VudCB0aGF0IGEgdGFiIGlzIGVxdWl2YWxl bnQgdG8gZWlnaHQgc3BhY2VzLg0KPiA+Pg0KPiA+PiBJZiBzb21lIGFwcGxpY2F0aW9ucyBuZWVk IHRoaXMga2luZCBvZiB0cmltbWluZywgdGhleSBzaG91bGQgZG8gaXQgdGhlbXNlbHZlcyBhbmQg bm90IGltcG9zZSBpdCBvbiB0aGUgcGFyc2VyLiBUaGlzIGZhbmN5IGZlYXR1cmUganVzdCBhZGRz IGV4dHJhIGNvbXBsZXhpdHkgdGhhdOKAmXMgbm90IG5lZWRlZCBhdCBhbGwuDQo+ID4NCj4gPg0K PiA+IEkgZG9uJ3Qgc2VlIGEgcmVhc29uIHRvIHJlbW92ZSB0aGUgdHJpbW1pbmcgcmVxdWlyZW1l bnRzLg0KPiA+IEl0IG1hdHRlcnMgZm9yIGEgbXVsdGktbGluZSBkZWZhdWx0LXN0bXQgdmFsdWUu DQo+IA0KPiBBY3R1YWxseSwgaXQgaXMgb3V0cmlnaHQgYnJva2VuOiBJIGd1ZXNzIHRoZSBtZWFu aW5nIG9mIGEgbW9kdWxlIHNob3VsZA0KPiBub3QgZGVwZW5kIG9uIHRoZSBpbmRlbnRhdGlvbiBv ZiBpdHMgc3RhdGVtZW50cw0KDQpSaWdodC4NCg0KPiBidXQgaXQgaXMgbm90IHRoZSBjYXNlDQo+ IGhlcmU6DQo+IA0KPiAgIGRlZmF1bHQgImZvb1xuXHRcdGJhciI7ICMgdHdvIHNwYWNlcyBvZiBp bmRlbnRhdGlvbg0KPiANCj4gZ2l2ZXMgYSBkaWZmZXJlbnQgZGVmYXVsdCB2YWx1ZSB0aGFuDQo+ IA0KPiAgICAgZGVmYXVsdCAiZm9vXG5cdFx0YmFyIjsgIyBmb3VyIHNwYWNlcyBvZiBpbmRlbnRh dGlvbg0KPiANCj4gSXNuJ3QgdGhpcyBhIGNsZWFyIGJ1Zz8NCg0KTm8gaXQgaXMgbm90IGNvcnJl Y3QgLSB3aGl0ZXNwYWNlIHRyaW1taW5nIG9ubHkgYXBwbGllcyB0byBsZWFkaW5nDQp3aGl0ZXNw YWNlIHdpdGhpbiB0aGUgc3RyaW5nLCBzbyBpbiB0aGUgY2FzZSBhYm92ZSB0aGVyZSBpcyBubyBz dWNoDQp3aGl0ZXNwYWNlLCBhbmQgdGhlIHR3byBzdHJpbmdzIGFyZSB0aGUgc2FtZS4gIE5vdGUg dGhhdCB3aXRoIHRoZQ0Kd2hpdGVzcGFjZSBydWxlcyB3ZSBoYXZlLCB0aGUgZm9sbG93aW5nIGV4 YW1wbGVzOg0KDQogIGRlZmF1bHQgImZvbw0KICAgICAgICAgICBiYXIiOw0KDQphbmQNCg0KICAg ICAgIGRlZmF1bHQgImZvbw0KICAgICAgICAgICAgICAgIGJhciI7DQoNCmdpdmVzICp0aGUgc2Ft ZSogZGVmYXVsdCB2YWx1ZSwgd2hlcmVhcyB3aXRob3V0IHdoaXRlc3BhY2UgdHJpbW1pbmcNCnRo ZXkgd291bGQgYmUgZGlmZmVyZW50IC0gd2hpY2ggd2UgYWdyZWVkIHdvdWxkIGJlIGJhZC4NCg0K QWxzbyBub3RlIHRoYXQgaWYgeW91IGRvbid0IGxpa2UgdGhlc2UgcnVsZXMsIHlvdSBjYW4gdXNl IHNpbmdsZQ0KcXVvdGVzLg0KDQoNCg0KL21hcnRpbg0K From nobody Fri Jan 9 23:17:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D9D1A802E for ; Fri, 9 Jan 2015 23:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzPHfjmLznZr for ; Fri, 9 Jan 2015 23:17:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F931A7015 for ; Fri, 9 Jan 2015 23:17:07 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:2933:ef57:a80d:c55d] (unknown [IPv6:2a01:5e0:29:ffff:2933:ef57:a80d:c55d]) by mail.nic.cz (Postfix) with ESMTPSA id EB57413FD88; Sat, 10 Jan 2015 08:17:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420874226; bh=8M59ZZi+kFVWWTbhgOYwwAy4Gq91k5P3Ho7b67kG/EA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oV5wcMpA7qWvO7xDDqNHTI/X9OiJnirVJi+R0fJTw9JGOyd6uwScuCe2TAisUknst UVUgS6SCiIisGQnn5+Ia4w0RtfhfVC/ttbDaTEAWmt0UDXwVXEARVI7VPX7RRijI0k 62Lh+P+gUfDNmap/wyCp4BNrivHhmpdih0RVCqxk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150110.073448.946284028415215453.mbj@tail-f.com> Date: Sat, 10 Jan 2015 08:17:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A5C0FC7-48D5-4496-9DEE-1877E96FEBBF@nic.cz> References: <1890907D-CDC9-49C1-A56F-8748A06B59FB@nic.cz> <20150110.073448.946284028415215453.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] whitespace stripping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 07:17:11 -0000 > On 10 Jan 2015, at 07:34, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> On Fri, Jan 9, 2015 at 5:47 AM, Ladislav Lhotka = wrote: >>>>=20 >>>>> On 09 Jan 2015, at 11:34, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>> We are supposed to be done in March with YANG 1.1. This is not the >>>>> time to add new issues unless they are bug fixes. >>>>>=20 >>>>> I do not think this is a bug fix. >>>>=20 >>>> Guess what: even pyang=E2=80=99s parser doesn=E2=80=99t implement = this CLR correctly, and that tells you something - it doesn=E2=80=99t = take into account that a tab is equivalent to eight spaces. >>>>=20 >>>> If some applications need this kind of trimming, they should do it = themselves and not impose it on the parser. This fancy feature just adds = extra complexity that=E2=80=99s not needed at all. >>>=20 >>>=20 >>> I don't see a reason to remove the trimming requirements. >>> It matters for a multi-line default-stmt value. >>=20 >> Actually, it is outright broken: I guess the meaning of a module = should >> not depend on the indentation of its statements >=20 > Right. >=20 >> but it is not the case >> here: >>=20 >> default "foo\n\t\tbar"; # two spaces of indentation >>=20 >> gives a different default value than >>=20 >> default "foo\n\t\tbar"; # four spaces of indentation >>=20 >> Isn't this a clear bug? >=20 > No it is not correct - whitespace trimming only applies to leading > whitespace within the string, so in the case above there is no such Well, this really surprises me. One of the examples in sec. 6.1.3.1 says = the following strings are equivalent: "first line second line" "first line\n" + " second line" This means that =E2=80=9C\n=E2=80=9D is the same as the literal newline. = Why then isn=E2=80=99t =E2=80=9C\t=E2=80=9D the same as the literal tab? What about default =E2=80=9Cfoo\n bar=E2=80=9D; ? > whitespace, and the two strings are the same. Note that with the > whitespace rules we have, the following examples: >=20 > default "foo > bar"; >=20 > and >=20 > default "foo > bar"; >=20 > gives *the same* default value, whereas without whitespace trimming > they would be different - which we agreed would be bad. I am not sure what=E2=80=99s worse. In any case, such things should be = avoided like plague. >=20 > Also note that if you don't like these rules, you can use single > quotes. That=E2=80=99s not the point. The trimming rules are relatively complex = and still it is doubtful whether they really improve on anything. Parser = writers may not get them right and this can lead to inconsistencies. A = clear indication is that we actually have *two* bugs in pyang related to = this: one is in the parsing code that you wrote and another is in the = DSDL plugin that I wrote. Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Jan 10 10:34:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565531A6F07 for ; Sat, 10 Jan 2015 10:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jckJzDPo-bXz for ; Sat, 10 Jan 2015 10:34:37 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64091A00F8 for ; Sat, 10 Jan 2015 10:34:36 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id hs14so19558696lab.11 for ; Sat, 10 Jan 2015 10:34:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5Dju6Sytp9haxvL9ztM5MSrpBckHbGmAxJsJvl8LYBI=; b=cVo/Hu+HdVoFHB3p4pdMeU3eVxH3eCnKHagFaSoft2bcRw8F+zHng2VA+t7nSFHXaL C19dhXutjA0d8gtzwNxPet3qkHjYdOtl+i4vv760sEOkMqLFKXkRik0bAuSIOGXzf/iT VLeo226hcDVsEdS4R7DHxzjYqMt2Ujr/zh5Vf45/YB/4f4vLyOEuvTrJOlGdwOLhMH9Q bXEzXzrlaetpnwTa2sNnGil8j4Upo6mVATT755CN8ciWt1euC9T0CeiLCxRoMhWV4py0 P+frBxF7/4aMEa6FaGrVEYEvz6IeVby+oqeBlixe/ltPjk9prS7PH5IUQZSgygMCpGPX Bc9Q== X-Gm-Message-State: ALoCoQlC7KJxPThfVuiFvNWRKidJKZa04+A4QBWKCMD34IbNYZSoMDm05Gw+7RFrwnwi+KBiGTQ6 MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr27939241lbv.21.1420914875080; Sat, 10 Jan 2015 10:34:35 -0800 (PST) Received: by 10.112.160.41 with HTTP; Sat, 10 Jan 2015 10:34:34 -0800 (PST) In-Reply-To: References: <20150108.110554.937715174693668373.mbj@tail-f.com> <295BFBE7-CA6E-4CF4-B6C3-95FD874A1B80@nic.cz> <20150108.125336.1998913946492695859.mbj@tail-f.com> Date: Sat, 10 Jan 2015 10:34:34 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 18:34:39 -0000 Hi, This discussion got sidetracked. Clearly the definition of individual standard attributes like "enabled" is outside the scope of this document. For this attribute, the nodes have to be removed from normal retrieval. The client needs to ask to include disabled nodes. The "annotation" extension is not a good way to define an entire attribute like "enabled". We just need some way to bind the attribute local-name to a namespace (represented by a URI in XML and a module name in JSON). attr:attribute-binding "with-defaults" { namespace "urn:ietf:params:netconf:capability:with-defaults:1.0"; attr:module-name "ietf-netconf-with-defaults"; } attr:attribute-binding "operation" { namespace "urn:ietf:params:xml:ns:netconf:base:1.0"; attr:module-name "ietf-netconf"; } For attributes without YANG modules, a module name needs to be assigned; The JSON encoding of "YANG attributes" in sec. 4 also needs to be standardi= zed. Andy On Thu, Jan 8, 2015 at 4:07 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > >> Ladislav Lhotka wrote: >>> >>> > On 08 Jan 2015, at 11:05, Martin Bjorklund wrote: >>> > >>> > Kent Watsen wrote: >>> >> >>> >> >>> >>> - who believes a mechanism to define metadata annotations >>> >>> should be standardized >>> >> >>> >> >>> >> Not yet. >>> >> >>> >> First I think we need to clear the way for attributes to be used >>> >> safely. >>> >> We used attributes in and also with-defaults, but in >>> >> both >>> >> cases the client either accepted the contract of the protocol >>> >> (base:1.1) >>> >> or explicitly opted into receiving the attributes (report-all-tagged= ). >>> >> Specifically, what happens to a legacy client if the attribute MUST = be >>> >> semantically understood (e.g., the enabled/inactive) in order to >>> >> correctly >>> >> process the data? >>> > >>> > Note that the draft just defines the mechanism to specify the *syntax= * >>> > of meta data, not the semantics. In the specific case of inactive, >>> > lots of works on the semantics is needed, but that needs to happen in >>> > a separate document. (I think that a client needs to send >>> > "with-inactive" in the get-config/get in order to signal to the serve= r >>> > that it wants to receive the inactive nodes). >>> >>> Hmm, but what happens if an old client creates data inside a subtree >>> that is tagged as inactive? >> >> An old client that doesn't send with-inactive will not receive >> inactive data, so it won't know that it is there. > > Right, so it may think it can create its own (active) data there. > >> >> Also, with-inactive is needed in edit-config/copy-config. > > An old client that doesn't know about with-inactive can't put it there. > > Lada > >> >>> For some annotations including this one the semantics will have to be >>> =E2=80=9Ceither you support it, or go away." >> >> Not for this one, but *maybe* for some other ;) >> >> >> /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Jan 11 05:25:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1B61A1EF2 for ; Sun, 11 Jan 2015 05:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xNNK195KF8l for ; Sun, 11 Jan 2015 05:25:53 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A896C1A1EEF for ; Sun, 11 Jan 2015 05:25:53 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so8139956igj.4 for ; Sun, 11 Jan 2015 05:25:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=1DKvC8n9m9XcSBq1gK0zh8Dvt7XJ0fK/i2dc7nynNOE=; b=LKkF6lxO7IN0cbc3JDxVvFOr/vC/dlnbfef98HwmjAW8twL25pWrlaZ2y7GnmLvBb0 9eebYwiFCgqnt4+WQTNOG+C30ausI39z7sPUcmDhdrYLcZvbwybbDfksGqM/LXhjZHKe W1uBhzVbOOsU4qx43rR/oy3pWAc9w3esz3Kx00vBpPML6nS9MB0c5NxsYeNr7khw/+1e eMgaK45s1lFwi0TYlAgxRDCAlpkkRTQy3sjvU07QrqUYosNKxSn25SIa4plFEyuaRghq qSgut7c2GDOqxZlyPTmzSzLPraY6JzM5yNBTW0tihylCLPoGm8O4sfrUDRWSni/WFmb3 yKDA== X-Gm-Message-State: ALoCoQnosP+g7vslRlzoTBgAQzCBZSmRrUl6CWzb1Ma2fBrzgrHmpctDRAG7V5udltgc1pZPXtjr X-Received: by 10.50.142.38 with SMTP id rt6mr10875868igb.17.1420982753093; Sun, 11 Jan 2015 05:25:53 -0800 (PST) Received: from dex.chopps.org (c-68-61-203-90.hsd1.mi.comcast.net. [68.61.203.90]) by mx.google.com with ESMTPSA id qs2sm2561560igb.1.2015.01.11.05.25.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Jan 2015 05:25:52 -0800 (PST) From: Christian Hopps X-Pgp-Agent: GPGMail 2.5b4 Content-Type: multipart/signed; boundary="Apple-Mail=_9EBA3841-7DBC-4854-A6EB-F1651B6A7CD7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sun, 11 Jan 2015 08:25:51 -0500 Message-Id: To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [netmod] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 13:25:55 -0000 --Apple-Mail=_9EBA3841-7DBC-4854-A6EB-F1651B6A7CD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Is this the appropriate list for questions on how to write something in = yang? [assuming yes for now.] I have a list (of routers) that I want as a part of a site definition, I = want to require this list be non-empty when the site is of a particular = type and also require that it not be present for a site of a different = type. I used the following syntax to try and do this: list site { leaf site-type { mandatory true; type site-type; } leaf-list router { min-elements 1; when "../site-type =3D =E2=80=98foo'"; type leafref ... } } Now the when statement appears to work when I put a router in a non = =E2=80=9Cfoo=E2=80=9D site (i.e., it asserts); however, what doesn=E2=80=99= t work is that it doesn=E2=80=99t require a minimum of 1 router in = =E2=80=9Cfoo=E2=80=9D sites. That is it doesn=E2=80=99t appear to = enforce min-elements 1. Am I coding this wrong? Thanks, Chris. --Apple-Mail=_9EBA3841-7DBC-4854-A6EB-F1651B6A7CD7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUsnnfAAoJEC4dgw7XuDAlCO4QAIOmSBdTdjeXGRzeHceuQNKV 7b9D4/M6vS9MypehL5ASv2cZnDSdDu/CHXu7pwM7Is2j3NfMk0AtroNADNJRXKur 9h6kGjP/TFb3dMxEQK3Jy9+RVwA2OQhIUWvGjhG5ewhgzC1LuaOnyQagL5WWyiin Du3hzEEA+fQ71N58MeGijw5JxUpodXndkXfDMklKz7skVPRTKYAqgqfiCVGrqniC E95K6uPaXWyb+zqrlp9M7HfhNwK/WwVBiItUaUQ1iSWU6j9w7IE+DgVx6RwUrZsN Yjv5DLjihh9Sggln7IMXzW7kA9H0jvp9/qfz8upQDIZXZ/VckS0HKE2aeGnhyt1f 2xLlZYudOYb+T30dzQndjhROhUqTeF+iypChBMY0q/Oswvc108aFixDGUx3nOVcE M1dqlQMoCFfHDitmYuYwgYeawzYDUjmwHkIe9mjHxRN6rpn//VTGn+AX2hI+4PLe Wao0yiaIPTSWtsfKO0ZI0/b6AYwrK0OEO19SLu9RV+rEirZSeIiDvMmI0F1Fu12b i+ExB6e6C8GM6PXqXapQzDmWMjDq1hJ0sCHFUan2MfS12ghaPtBgo9RfmMkJx77d vWhlPAdedSf/IZrRi0mthyAe7j2T+wFRIV0itvxCBPuZVwWUbdB8FB08WibT6nNO V0Lxalsx3DOmoUytP1Rr =6OFN -----END PGP SIGNATURE----- --Apple-Mail=_9EBA3841-7DBC-4854-A6EB-F1651B6A7CD7-- From nobody Sun Jan 11 05:27:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AEA1A1EF8; Sun, 11 Jan 2015 05:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uPRXX0eibAY; Sun, 11 Jan 2015 05:27:54 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2AE1A1EF4; Sun, 11 Jan 2015 05:27:54 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 8DAE62C123EF; Sun, 11 Jan 2015 08:27:53 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Sun, 11 Jan 2015 08:27:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christian Hopps X-Mailer: Apple Mail (2.1993) Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 13:27:55 -0000 > On Jan 11, 2015:8:25 AM, at 8:25 AM, Christian Hopps = wrote: >=20 > Hi, >=20 > Is this the appropriate list for questions on how to write something = in yang? You have come to the right place. 8) The other place you can = ask for suggestions is the yang-doctors list (CC:ed) but most of those = folks if not all, are subscribed here too...=20 > [assuming yes for now.] >=20 > I have a list (of routers) that I want as a part of a site definition, = I want to require this list be non-empty when the site is of a = particular type and also require that it not be present for a site of a = different type. I used the following syntax to try and do this: >=20 > list site { > leaf site-type { > mandatory true; > type site-type; > } > leaf-list router { > min-elements 1; > when "../site-type =3D =E2=80=98foo'"; > type leafref ... > } > } >=20 > Now the when statement appears to work when I put a router in a non = =E2=80=9Cfoo=E2=80=9D site (i.e., it asserts); however, what doesn=E2=80=99= t work is that it doesn=E2=80=99t require a minimum of 1 router in = =E2=80=9Cfoo=E2=80=9D sites. That is it doesn=E2=80=99t appear to = enforce min-elements 1. >=20 > Am I coding this wrong? >=20 > Thanks, > Chris. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Jan 11 09:27:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD831A82E2 for ; Sun, 11 Jan 2015 09:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9vAcvzhVGi1 for ; Sun, 11 Jan 2015 09:27:51 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCF71A7034 for ; Sun, 11 Jan 2015 09:27:50 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so14586903lbv.11 for ; Sun, 11 Jan 2015 09:27:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=94VPUBjSi3YiDwNXdz6rugzRKUYQW3XhHzaQlivORl0=; b=XhhFOGky3drz/ZLEd4mWubS3G9UT/OzOq88yNEjEAI7O06e6Jk10Z1n6bQUBBxqjhW 9GevvBxUtLxspi2LtZq3+6uQmyV9zoYU432mUZ0KX20IBhlpHsZQ2z/JPpzPqQ7iFO0C LkKfVo1GtAy93Mh3gZiBcBUu5fdXHKpCB4Z7wawYIBqZLizNYhvu/ikIpKG7emytkNxC BOYgb+BBBItG684FXUYuBK4tIqWQIxxekoiKLp3+2jcyztedQ8zHvPmN48rN37mNqS5F Y/48fujyDtOhab8jKi7jJPNe//NK3mm41f7XFnJJ1EWgU9wLRuq9mCgQY956HsaNnyeW tokg== X-Gm-Message-State: ALoCoQndBIrV0qHxf44vZ9C0tPNXIReHtGrHkOWwiG2w0/P2V7p6bQCjbmWRPAW9OZFzOxcetxgO MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr32101046lam.15.1420997269363; Sun, 11 Jan 2015 09:27:49 -0800 (PST) Received: by 10.112.160.41 with HTTP; Sun, 11 Jan 2015 09:27:49 -0800 (PST) In-Reply-To: References: Date: Sun, 11 Jan 2015 09:27:49 -0800 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 17:27:53 -0000 On Sun, Jan 11, 2015 at 5:27 AM, Thomas D. Nadeau wrote: > >> On Jan 11, 2015:8:25 AM, at 8:25 AM, Christian Hopps wrote: >> >> Hi, >> >> Is this the appropriate list for questions on how to write something in = yang? > > You have come to the right place. 8) The other place you can as= k for suggestions is the yang-doctors list (CC:ed) but most of those folks = if not all, are subscribed here too... > >> [assuming yes for now.] >> >> I have a list (of routers) that I want as a part of a site definition, I= want to require this list be non-empty when the site is of a particular ty= pe and also require that it not be present for a site of a different type. = I used the following syntax to try and do this: >> >> list site { >> leaf site-type { >> mandatory true; >> type site-type; >> } >> leaf-list router { >> min-elements 1; >> when "../site-type =3D =E2=80=98foo'"; >> type leafref ... >> } >> } >> >> Now the when statement appears to work when I put a router in a non =E2= =80=9Cfoo=E2=80=9D site (i.e., it asserts); however, what doesn=E2=80=99t w= ork is that it doesn=E2=80=99t require a minimum of 1 router in =E2=80=9Cfo= o=E2=80=9D sites. That is it doesn=E2=80=99t appear to enforce min-elements= 1. >> >> Am I coding this wrong? >> The YANG above must be for config=3Dfalse nodes, because there is no key defined. Servers do no run YANG validation checks on their own output. If there was a key, and if it was config validated by a server, then the when-stmt check to make sure site-type=3Dfoo is done before the check on min-elements=3D1. >> Thanks, >> Chris. Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Mon Jan 12 03:03:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E01A8AD4 for ; Mon, 12 Jan 2015 03:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ6-M-mt1bEB for ; Mon, 12 Jan 2015 03:03:14 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B241A8AD2 for ; Mon, 12 Jan 2015 03:03:14 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id x19so24504807ier.13 for ; Mon, 12 Jan 2015 03:03:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=XZo7M4KAQfg1t1bSBXpueOjrTU/jbEtDwY6ASwgCXUQ=; b=VJj0VYlTd7Tk/QrbY4EcUDzXHI0VuldCS615PhgQQo3mDRMIiYC4MwhE0WFWvALSLU x+FNc0jXOwkQweI3WeCtAtvxSCmQap3NPGXpqTResiGnTmJ9SxQE1zLt0ORRxJBsTCDf HyqGsP8fhlv5kyGBxHB4c82vZWtDhAICtH19PzjUZjHJ6c0ah2v7h61/xFT+mjeOFW8g Y7XE+CTL6PWgFHS8Zu6eqAse2ZaqPmEce6XTPkzJUUNZhRG7sT0w2b8fxdmq13oLGc6S 18AA97zwm0ZcfSWzuMPkDR4Dl59aAQAOuWZNUkAo8/54IC/QzH/wIuyDSvmU+HicUdoE QEVw== X-Gm-Message-State: ALoCoQm5Lz5dac0JpWdZm/50tUmM6ZHAgXp6hMZ6I1AtP/OQar2jifm9z+euTxNzTpzIkH9u+70N X-Received: by 10.50.137.101 with SMTP id qh5mr9653301igb.11.1421060593534; Mon, 12 Jan 2015 03:03:13 -0800 (PST) Received: from ?IPv6:2601:4:a00:881:8cbb:c3a7:ab9:3290? ([2601:4:a00:881:8cbb:c3a7:ab9:3290]) by mx.google.com with ESMTPSA id mv6sm4081636igb.10.2015.01.12.03.03.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 03:03:12 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9CE2E248-C870-46F4-A808-10FAFACE9B0B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b4 From: Christian Hopps In-Reply-To: Date: Mon, 12 Jan 2015 06:03:10 -0500 Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) Archived-At: Cc: NETMOD Working Group , YANG Doctors Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 11:03:16 -0000 --Apple-Mail=_9CE2E248-C870-46F4-A808-10FAFACE9B0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 11, 2015, at 12:27 PM, Andy Bierman wrote: >=20 >>=20 >>> [assuming yes for now.] >>>=20 >>> I have a list (of routers) that I want as a part of a site = definition, I want to require this list be non-empty when the site is of = a particular type and also require that it not be present for a site of = a different type. I used the following syntax to try and do this: >>>=20 >>> list site { >>> leaf site-type { >>> mandatory true; >>> type site-type; >>> } >>> leaf-list router { >>> min-elements 1; >>> when "../site-type =3D =E2=80=98foo'"; >>> type leafref ... >>> } >>> } >>>=20 >>> Now the when statement appears to work when I put a router in a non = =E2=80=9Cfoo=E2=80=9D site (i.e., it asserts); however, what doesn=E2=80=99= t work is that it doesn=E2=80=99t require a minimum of 1 router in = =E2=80=9Cfoo=E2=80=9D sites. That is it doesn=E2=80=99t appear to = enforce min-elements 1. >>>=20 >>> Am I coding this wrong? >>>=20 >=20 >=20 > The YANG above must be for config=3Dfalse nodes, because there is > no key defined. Servers do no run YANG validation checks on > their own output. >=20 > If there was a key, and if it was config validated by a server, then = the > when-stmt check to make sure site-type=3Dfoo is done before the > check on min-elements=3D1. Sorry I trimmed it down as the site def is much larger, the list = contains a key: list site { key "site-id"; leaf site-id { type site-id; } leaf site-type { mandatory true; type site-type; } // [..cut..] leaf-list router { // The combination of when and min-elms appears to allow 0 = elements // for the when matching site types min-elements 1; when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; type leafref { path "../../../router/router-id"; } } I=E2=80=99m using yang2dsdl with (both -t data and -t config) to = validate. Both ways (config or data) accept XML with no routers = specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. Both = ways correctly reject a router specified in a non-ots/odws site. Thanks, Chris. --Apple-Mail=_9CE2E248-C870-46F4-A808-10FAFACE9B0B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUs6nuAAoJEC4dgw7XuDAlCSMP/Ap5pEpjshMhlhkokxGFn7y/ +qBDgNS2kb3NmkAfDu1asqy8TgkP/OVcKEbOGolLI38vKwmIjmWW9Mr7ygja4fML Z7wpbHLafpkjWPnX3ddTMFwEvHiAv7AY01FN99CPNSiNdIz6oSi9LCVPm3HJHQFc Z6pp1jNAnqFAfCPGGu6vjpCv3bKWrgO7HIidVo6YESwT4RJeCbC4dzJAZ60bqMAb iJ1OSoKVwk8VWPEBnJVfo5AkgqKVOMw1p+0U8wfgVwGftFKMEHr+zwbN0h+DFuLC V0XKZr1uOUqaKkkwwyhDVYPwBdqc53ZP5ynBztMUbTYQwaecnNPBuZk8co1gbZc5 o0eMDfRYIJhgFJKWV6FTZaxTm3I9qtdDnDTL/zHHuMclIL6PQIW4wiGCd4IrGiYP ZWC+kJQ/ypfWuGeSvXa5VEI27oNJ07/AzlzWGvfoZ6ddo3+8yNmqP536NqeF/Mz8 XZVm6XpQCJ+cxJTBYX2YTLnn9/OdD5KpADyZ/KspHJaQZrzdGPdntTMcjo/BRrla 8/ziccNnqcMGr8Z/xa4UTFf11qWekPVG4SZSs9UzCa+wLM5j/TtBau8Tj0Wt7s/G Qm44EZDbXF5BMMFWMhohX73gkzigm2VJtjRkAQZm93+SUwYcPcrCxK8nsYw/HFr0 y2hgTH5KXCGOWnVX4Dva =ngr3 -----END PGP SIGNATURE----- --Apple-Mail=_9CE2E248-C870-46F4-A808-10FAFACE9B0B-- From nobody Mon Jan 12 03:59:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29E91A8BB7; Mon, 12 Jan 2015 03:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NRSbApBejeB; Mon, 12 Jan 2015 03:59:36 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 954261A8AFE; Mon, 12 Jan 2015 03:59:35 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 53DE21CC002E; Mon, 12 Jan 2015 12:59:44 +0100 (CET) From: Ladislav Lhotka To: Christian Hopps , Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 12 Jan 2015 12:59:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 11:59:39 -0000 Hi Christian, Christian Hopps writes: > > Sorry I trimmed it down as the site def is much larger, the list contains= a key: > > list site { > key "site-id"; > leaf site-id { > type site-id; > } > leaf site-type { > mandatory true; > type site-type; > } > // [..cut..] > leaf-list router { > // The combination of when and min-elms appears to allow 0 elemen= ts > // for the when matching site types > min-elements 1; > when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; > type leafref { > path "../../../router/router-id"; > } > } > > I=E2=80=99m using yang2dsdl with (both -t data and -t config) to > validate. Both ways (config or data) accept XML with no routers > specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. Both = ways correctly reject a > router specified in a non-ots/odws site. This has to do with YANG 1.1 ussue Y18: https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 If there is no "router" element, the XPath expression in "when" cannot be evaluated because there is no context node for such an evaluation. So the validation procedure assumes the XPath expression *might* be true and doesn't flag missing "router" as an error. The other option would be to flag missing "router" always as an error, even if "site-type" is neither "ots" nor "odws", but I thought it was better to have occassional false negatives than false positives. Lada > > > Thanks, > Chris. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 12 04:24:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCCF1A8F4A for ; Mon, 12 Jan 2015 04:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqnPMC0dDVUJ for ; Mon, 12 Jan 2015 04:24:46 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4F51A8BB0 for ; Mon, 12 Jan 2015 04:24:46 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so24853801iec.11 for ; Mon, 12 Jan 2015 04:24:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=z089sbzXZHiHUfLwapn6t3VR0BZ4gOJRzXVhgDam0lU=; b=EoRDh6Z7z3uURxYuhpZl+07XKuiBdKoSdrWWwwotsJ1x5+MLWMsAnWBoXJgSJodlUg OD09DpgZB4LdIbOTNuVwjtwzyZ0SffLPUeXt+D0CQdxSQFALduPg2XKgm+965WMTEvGd 2T4uPj1iQ35fPYrphThU86ZX9GdsSYtiXYwlXIE5+Xl9Pn3N0ejQfke20BibnWA1yxcs OfaC7sS+IrLQ9HIvJ8/gRg3hUYBPieZxNNdYPdR2Nyz7h1QX8/p8bQUjBJUh+Xk+oLSS NUHa2QipF9GVTu9s2p0Iger0zpUISw9LMR3IEausCYQIpEW3KowCimq9AhPjN7uROBYV 7UNA== X-Gm-Message-State: ALoCoQnvOgvycB93cKmJilJZgvjoPLnD9yoEhrjDDtflu+eTWAuJA9CnBkZxNqkZt/jkIif7Bq6Z X-Received: by 10.42.253.195 with SMTP id nb3mr23449224icb.34.1421065485596; Mon, 12 Jan 2015 04:24:45 -0800 (PST) Received: from ?IPv6:2601:4:a00:881:8cbb:c3a7:ab9:3290? ([2601:4:a00:881:8cbb:c3a7:ab9:3290]) by mx.google.com with ESMTPSA id f1sm4090882iga.1.2015.01.12.04.24.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Jan 2015 04:24:44 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AC0EB495-F779-470B-A58C-FBF64CFB7DBC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b4 From: Christian Hopps In-Reply-To: Date: Mon, 12 Jan 2015 07:24:41 -0500 Message-Id: <90D014B6-7538-4F8C-A515-39D46B94D5D2@rawdofmt.org> References: To: Ladislav Lhotka X-Mailer: Apple Mail (2.1993) Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 12:24:49 -0000 --Apple-Mail=_AC0EB495-F779-470B-A58C-FBF64CFB7DBC Content-Type: multipart/alternative; boundary="Apple-Mail=_FBAC4CB7-CE4B-4094-A896-97387D5C863B" --Apple-Mail=_FBAC4CB7-CE4B-4094-A896-97387D5C863B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 12, 2015, at 6:59 AM, Ladislav Lhotka wrote: >=20 > Hi Christian, >=20 > Christian Hopps > = writes: >=20 >>=20 >> Sorry I trimmed it down as the site def is much larger, the list = contains a key: >>=20 >> list site { >> key "site-id"; >> leaf site-id { >> type site-id; >> } >> leaf site-type { >> mandatory true; >> type site-type; >> } >> // [..cut..] >> leaf-list router { >> // The combination of when and min-elms appears to allow 0 = elements >> // for the when matching site types >> min-elements 1; >> when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; >> type leafref { >> path "../../../router/router-id"; >> } >> } >>=20 >> I=E2=80=99m using yang2dsdl with (both -t data and -t config) to >> validate. Both ways (config or data) accept XML with no routers >> specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. = Both ways correctly reject a >> router specified in a non-ots/odws site. >=20 > This has to do with YANG 1.1 ussue Y18: >=20 > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 = >=20 > If there is no "router" element, the XPath expression in "when" cannot > be evaluated because there is no context node for such an evaluation. >=20 > So the validation procedure assumes the XPath expression *might* be = true > and doesn't flag missing "router" as an error. >=20 > The other option would be to flag missing "router" always as an error, > even if "site-type" is neither "ots" nor "odws", but I thought it was > better to have occassional false negatives than false positives. I don=E2=80=99t think there is an issue with the xpath expression, as it = properly flags when a router is in a non-ots/odws site. The problem is = that the "min-elements 1;=E2=80=9D is ignored. Thanks, Chris. >=20 > Lada >=20 >>=20 >>=20 >> Thanks, >> Chris. >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C --Apple-Mail=_FBAC4CB7-CE4B-4094-A896-97387D5C863B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 12, 2015, at 6:59 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote:

Hi Christian,

Christian Hopps <chopps@rawdofmt.org> writes:


Sorry I trimmed it down as the site def is much larger, the = list contains a key:

   list = site {
     key "site-id";
     leaf site-id {
       type site-id;
     }
     leaf site-type {
       mandatory true;
       type site-type;
     }
     // [..cut..]
     leaf-list router {
       // The combination = of when and min-elms appears to allow 0 elements
       // for the when = matching site types
       min-elements 1;
       when "../site-type = =3D 'ots' or ../site-type =3D 'odws'";
       type leafref {
         path = "../../../router/router-id";
       }
     }

I=E2=80=99m using yang2dsdl with (both -t data and -t config) = to
validate. Both ways (config or data) accept XML with no = routers
specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2= =80=99 sites. Both ways correctly reject a
router = specified in a non-ots/odws site.

This has to do with YANG 1.1 = ussue Y18:

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#s= ec-19

If there is no "router" = element, the XPath expression in "when" cannot
be evaluated because there is no = context node for such an evaluation.

So the validation procedure = assumes the XPath expression *might* be true
and doesn't flag missing = "router" as an error.

The other option would be = to flag missing "router" always as an error,
even if "site-type" is neither = "ots" nor "odws", but I thought it was
better to have occassional false = negatives than false positives.

I don=E2=80=99= t think there is an issue with the xpath expression, as it properly = flags when a router is in a non-ots/odws site. The problem is that the = "min-elements 1;=E2=80=9D is ignored.

Thanks,
Chris.


Lada



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

-- 
Ladislav Lhotka, CZ.NIC = Labs
PGP Key ID: = E74E8C0C

= --Apple-Mail=_FBAC4CB7-CE4B-4094-A896-97387D5C863B-- --Apple-Mail=_AC0EB495-F779-470B-A58C-FBF64CFB7DBC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUs70KAAoJEC4dgw7XuDAl8FgP/RoAv+4qPonWTrZMl4E8Ohz5 3O45dV3llaFQg0meT8CS7hzDSa0wyw/lZpFNYrzsLOaFRXxhjTQOzOtOAwKHIsgd Xwa/QJtcfraHtiN8lC2Hn53ERTBIF1jDLebVVVr6Y+NsL98QLGh41oue7bvXTAID yV7lnJQufnKluQiwIoqqgscaTYIP6xESFSuNxl8tRdiwYgluQ8xAy8wddZyRfh6A evjgLxULIF1un2jGzUco7QeDdLAJ6gtN46tcKk6ojHAcqMrmQq1Ohoj8kM53Pbds IDioYL4Q5JzcYUX5dAgmKTELf1msymL+aP3lR+uuNXN5Cp9xeb7WbEIzaLF9IU+O ZKGile5SwIztYsEzm6FnSuYnSYAfofv2Lvw9rT+97urDoMwze9eJCca+nProUntL 58HMbZVmssi6ktLU982ocoixyv5lXAmUKSJTvXStwnIJ/u11wDq7/90s/xP0kKhp NaWOxJC0VUP8oJ1LZpgxvCcniZO/N6scltvDa0b4Oc4CoJ8laoygqpE1LGS6Ttcf P8Ni+nhAN1tiUIGoKZbBZYwWZwZCu35zvO77kMbcNh5yf0wVI8NFR3eWYMz4QOCz f1Qk6JZXKh4fUT2a83g0muw1WSFMmRk8abs2HqKVafUNQMpdxKBLwBQr5L5JiXGP lfYg1mIYswfgeGDgGIxg =FjzG -----END PGP SIGNATURE----- --Apple-Mail=_AC0EB495-F779-470B-A58C-FBF64CFB7DBC-- From nobody Mon Jan 12 04:43:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BCD1A8F4F for ; Mon, 12 Jan 2015 04:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfGS_iDoVL2x for ; Mon, 12 Jan 2015 04:43:53 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24501A8FD6 for ; Mon, 12 Jan 2015 04:42:19 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so17650911lbi.2 for ; Mon, 12 Jan 2015 04:42:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TiyPBhNTMqVUutHZ72+xVtLGpYbw0G//Y8gXkxdT1ps=; b=XfJ7PFIr6SOLIVxTnRpUSFt4Z6drZFPa46I9AtorYNBHdCnj1pj34+Xvkd4Xaa6orX dwNC8bAGCjgBluF1+AicqPSGMrs8DX5pZulfRiKpRb1d0en6Z+VYKVEWd1rLd8W9+EDD Y69nTvcw0MZfaRbynZ2ZA4qfr/7UmhSfdawGa1mYnhUuR3SuGzlQi8Th4u99uN53QvtT 6Kde6OI88WNwy/97k0nEW3mXY6wHJppbWy3T8ltyf9kHVr8KojIC3TULBjju6cImiWdP f81RsuNumfj9afuBTH7GGn56FOu6YZB1TnnMwoCTKdl2SFgTfswVWNOemlsP1PxooIdH uxMw== X-Gm-Message-State: ALoCoQnrMDnv2Pk2yvMrc+ECk8Eq2KM20R80D1j0D1zDAtgzpTewRuZ4Pl0LTutw9SjE2M2eoi64 MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr35887898lam.15.1421066538209; Mon, 12 Jan 2015 04:42:18 -0800 (PST) Received: by 10.112.160.41 with HTTP; Mon, 12 Jan 2015 04:42:18 -0800 (PST) In-Reply-To: References: Date: Mon, 12 Jan 2015 04:42:18 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 12:43:55 -0000 On Mon, Jan 12, 2015 at 3:59 AM, Ladislav Lhotka wrote: > Hi Christian, > > Christian Hopps writes: > >> >> Sorry I trimmed it down as the site def is much larger, the list contain= s a key: >> >> list site { >> key "site-id"; >> leaf site-id { >> type site-id; >> } >> leaf site-type { >> mandatory true; >> type site-type; >> } >> // [..cut..] >> leaf-list router { >> // The combination of when and min-elms appears to allow 0 eleme= nts >> // for the when matching site types >> min-elements 1; >> when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; >> type leafref { >> path "../../../router/router-id"; >> } >> } >> >> I=E2=80=99m using yang2dsdl with (both -t data and -t config) to >> validate. Both ways (config or data) accept XML with no routers >> specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. Both= ways correctly reject a >> router specified in a non-ots/odws site. > > This has to do with YANG 1.1 ussue Y18: > > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 > This does not appear to be related to Y18. The problem here is that the "when" expression applies to the running datastore in the server, not to the request message. You cannot use an off-line tool to validate any NETCONF message as if it were processed by a server. None of the constraints that apply to a valid configuration datastore can be evaluated without all the datastore contents. Andy > If there is no "router" element, the XPath expression in "when" cannot > be evaluated because there is no context node for such an evaluation. > > So the validation procedure assumes the XPath expression *might* be true > and doesn't flag missing "router" as an error. > > The other option would be to flag missing "router" always as an error, > even if "site-type" is neither "ots" nor "odws", but I thought it was > better to have occassional false negatives than false positives. > > Lada > >> >> >> Thanks, >> Chris. >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Mon Jan 12 04:45:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E38F1A8FD3 for ; Mon, 12 Jan 2015 04:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjVDdJqJgfqG for ; Mon, 12 Jan 2015 04:45:46 -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 BBB7D1A8AF8 for ; Mon, 12 Jan 2015 04:45:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 87B128FA; Mon, 12 Jan 2015 13:45:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nLZzRJD3bwlB; Mon, 12 Jan 2015 13:45:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Jan 2015 13:45:45 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C616B2002C; Mon, 12 Jan 2015 13:45:44 +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 HFAar4AnKIia; Mon, 12 Jan 2015 13:37:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D93FF20017; Mon, 12 Jan 2015 13:45:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C682E30B8D46; Mon, 12 Jan 2015 13:45:43 +0100 (CET) Date: Mon, 12 Jan 2015 13:45:43 +0100 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20150112124543.GA77455@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , "netmod@ietf.org" References: <20150107143343.GB13482@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y16: module advertisement optimization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 12:45:53 -0000 On Fri, Jan 09, 2015 at 09:01:36PM +0000, Sterne, Jason (Jason) wrote: > Is there a potential race condition between receiving the and the results of the ? > > I suppose this is pretty unlikely in most servers but if any future servers have capabilities that can change somewhat dynamically then we may want to include the in the response to the request (to bind the capabilities to a signature) so the client can do a double check that they are still working with the same . > > The hello should still include the . This makes sense to me. > On another note -> is there any need out there to allow a server to advertise (async) to a client that it's capabilities have changed ? I could imagine, for example, a system that supports in service upgrades (and manages to keep the NETCONF session going during the upgrade) could suddenly have some different capabilities. > There is netconf-capability-change defined in RFC 6470. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 12 05:10:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16631A8F40; Mon, 12 Jan 2015 05:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6B1fYT7wPiD; Mon, 12 Jan 2015 05:10:23 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611C91A1B9B; Mon, 12 Jan 2015 05:10:23 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id B07BA13FA1F; Mon, 12 Jan 2015 14:10:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421068221; bh=qYmA1Em1zUCMMsk2TWgh/CLkUDpYCFgyWiSiRXutIYE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rdt7WLXSs5816uokW37S+9Gy7qrRSEjCUQ2jqJdqd4q4lPx0ILbcfqUlRUfNGMZF1 ZPXgl54uvuuS5bXwsMtlSbJ2I+k7d3y0v4pzPTRXJ/IDHqGXqcrRPIPAh5muK8oqyM VqV9liS2WXTUG4+H9n7LZ2nc4Z79t7P1iZ14Lu40= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <90D014B6-7538-4F8C-A515-39D46B94D5D2@rawdofmt.org> Date: Mon, 12 Jan 2015 14:10:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F5F2766-99F1-4571-9A2C-9DB207384C60@nic.cz> References: <90D014B6-7538-4F8C-A515-39D46B94D5D2@rawdofmt.org> To: Christian Hopps X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 13:10:26 -0000 > On 12 Jan 2015, at 13:24, Christian Hopps wrote: >=20 >>=20 >> On Jan 12, 2015, at 6:59 AM, Ladislav Lhotka wrote: >>=20 >> Hi Christian, >>=20 >> Christian Hopps writes: >>=20 >>>=20 >>> Sorry I trimmed it down as the site def is much larger, the list = contains a key: >>>=20 >>> list site { >>> key "site-id"; >>> leaf site-id { >>> type site-id; >>> } >>> leaf site-type { >>> mandatory true; >>> type site-type; >>> } >>> // [..cut..] >>> leaf-list router { >>> // The combination of when and min-elms appears to allow 0 = elements >>> // for the when matching site types >>> min-elements 1; >>> when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; >>> type leafref { >>> path "../../../router/router-id"; >>> } >>> } >>>=20 >>> I=E2=80=99m using yang2dsdl with (both -t data and -t config) to >>> validate. Both ways (config or data) accept XML with no routers >>> specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. = Both ways correctly reject a >>> router specified in a non-ots/odws site. >>=20 >> This has to do with YANG 1.1 ussue Y18: >>=20 >> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 >>=20 >> If there is no "router" element, the XPath expression in "when" = cannot >> be evaluated because there is no context node for such an evaluation. >>=20 >> So the validation procedure assumes the XPath expression *might* be = true >> and doesn't flag missing "router" as an error. >>=20 >> The other option would be to flag missing "router" always as an = error, >> even if "site-type" is neither "ots" nor "odws", but I thought it was >> better to have occassional false negatives than false positives. >=20 > I don=E2=80=99t think there is an issue with the xpath expression, as = it properly flags when a router is in a non-ots/odws site. The problem = is that the "min-elements 1;=E2=80=9D is ignored. If at least one =E2=80=9Crouter=E2=80=9D element exists in an instance, = then it can be used as the context node and Schematron then evaluates = the XPath expression and complains if it is false. In an older pyang version, the RELAX NG validation would *always* = enforce the schema constraint =E2=80=9Cmin-elements 1;=E2=80=9D, even if = the =E2=80=9Cwhen=E2=80=9D expression was false. Then somebody = complained about this behaviour so I changed it. Unfortunately, nothing else can be done unless we do the trickery that = is proposed in the solution Y18-01. However, the latter would be IMO = impossible to implement in DSDL - RELAX NG needs a fixed grammar/schema = and not one that is dependent on the instance document being validated, = which is exactly what =E2=80=9Cwhen=E2=80=9D does. Lada >=20 > Thanks, > Chris. >=20 >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> Thanks, >>> Chris. >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 12 05:34:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670C01A909E; Mon, 12 Jan 2015 05:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNX62yOQQbAd; Mon, 12 Jan 2015 05:34:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2601A8A90; Mon, 12 Jan 2015 05:34:13 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:c1d1:b57d:1bb7:8ff9] (unknown [IPv6:2001:718:1a02:1:c1d1:b57d:1bb7:8ff9]) by mail.nic.cz (Postfix) with ESMTPSA id 0925013F871; Mon, 12 Jan 2015 14:34:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421069652; bh=tpveA1WtByS4T9CxS92PNgYz6UySqwfwz4erwrwa4a4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X6M9UTVhop3Vhd2DeHAVoBedGJkG2xf2GNEzJ/m8QNDLcCtNpbLS351B2+4zG1rPA CoHxgsDnQKdn8Q3Qxu2545fgdLmB00F4+bLfGKp1/UkIUSBLiIYf/HNlMpraDu7fm2 DrutUkRF6pg5zIsLKKGuqGpHxb140pbe79AYPPHk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 12 Jan 2015 14:34:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 13:34:15 -0000 > On 12 Jan 2015, at 13:42, Andy Bierman wrote: >=20 > On Mon, Jan 12, 2015 at 3:59 AM, Ladislav Lhotka = wrote: >> Hi Christian, >>=20 >> Christian Hopps writes: >>=20 >>>=20 >>> Sorry I trimmed it down as the site def is much larger, the list = contains a key: >>>=20 >>> list site { >>> key "site-id"; >>> leaf site-id { >>> type site-id; >>> } >>> leaf site-type { >>> mandatory true; >>> type site-type; >>> } >>> // [..cut..] >>> leaf-list router { >>> // The combination of when and min-elms appears to allow 0 = elements >>> // for the when matching site types >>> min-elements 1; >>> when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; >>> type leafref { >>> path "../../../router/router-id"; >>> } >>> } >>>=20 >>> I=E2=80=99m using yang2dsdl with (both -t data and -t config) to >>> validate. Both ways (config or data) accept XML with no routers >>> specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. = Both ways correctly reject a >>> router specified in a non-ots/odws site. >>=20 >> This has to do with YANG 1.1 ussue Y18: >>=20 >> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 >>=20 >=20 > This does not appear to be related to Y18. It is exactly the substance of Y18: If no element is present in = the instance document, the XPath expression cannot be evaluated (if we = abide by XPath rules) to decide whether the =E2=80=9Crouter=E2=80=9D = node is in the schema or not. That=E2=80=99s where Y18-01 proposes to = insert a tentative element and use it as the context node. >=20 > The problem here is that the "when" expression applies > to the running datastore in the server, not to the request message. This is true only for the =E2=80=9Cconfig=E2=80=9D target that validates = an request. However, Chris also said he'd tried yang2dsdl = with the =E2=80=9Cdata=E2=80=9D target (-t config), which is essentially = the content of a datastore. I verified the result is indeed as Chris = wrote. If the =E2=80=9Cwhen=E2=80=9D statement is removed, then missing = is flagged as an error in RELAX NG validation. Lada >=20 > You cannot use an off-line tool to validate any NETCONF > message as if it were processed by a server. None of the constraints > that apply to a valid configuration datastore can be > evaluated without all the datastore contents. >=20 >=20 >=20 > Andy >=20 >> If there is no "router" element, the XPath expression in "when" = cannot >> be evaluated because there is no context node for such an evaluation. >>=20 >> So the validation procedure assumes the XPath expression *might* be = true >> and doesn't flag missing "router" as an error. >>=20 >> The other option would be to flag missing "router" always as an = error, >> even if "site-type" is neither "ots" nor "odws", but I thought it was >> better to have occassional false negatives than false positives. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> Thanks, >>> Chris. >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 12 06:05:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAFD1A9135 for ; Mon, 12 Jan 2015 06:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4BRTugOZv9y for ; Mon, 12 Jan 2015 06:05:18 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF831A9132 for ; Mon, 12 Jan 2015 06:05:12 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so18318090lbg.5 for ; Mon, 12 Jan 2015 06:05:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2r5uX6MpIAu8ELAoCoVujJM4NbNuRNDPiKEzqYGYxSw=; b=S5yXV7mejER1DVbh5lXMrLvQMLFIUiKq1pkykdJ27tg1SViNzO3KAQXAo7gS1MrzJS ujJMka31YFhIg4y1/uRitzABFq9XvOwHTs6xh6oap8V5jCN7dolMd8kNWHub3gax9+jd Q3wOYfU4puauGWu324USM6t4cs+P4aK+VaGEiJVtCJxl6Is2+n7DqbU6+2KCsLgXpe3f JxnEiLCJ8yC3w9xy6zEl4ef/zn+WXXGOTDvRcJAfxW+TnfF1pNm0PcsdJIf/qxb0vNbi wAT0nr6gJKLnCFsWZFHl6r9Vgs0D13YY6BxWhiLeba7VBCogELublv//7dmy7kngC8Iu VymQ== X-Gm-Message-State: ALoCoQmQmYgFAt8TZOdA5CRMMTVMCWC92SyFEUBABl+lQkJCp9BvlBo1ia6FwAge1VDNSvs4CQI8 MIME-Version: 1.0 X-Received: by 10.152.27.130 with SMTP id t2mr36078402lag.28.1421071510930; Mon, 12 Jan 2015 06:05:10 -0800 (PST) Received: by 10.112.160.41 with HTTP; Mon, 12 Jan 2015 06:05:10 -0800 (PST) In-Reply-To: References: Date: Mon, 12 Jan 2015 06:05:10 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:05:20 -0000 On Mon, Jan 12, 2015 at 5:34 AM, Ladislav Lhotka wrote: > >> On 12 Jan 2015, at 13:42, Andy Bierman wrote: >> >> On Mon, Jan 12, 2015 at 3:59 AM, Ladislav Lhotka wrote: >>> Hi Christian, >>> >>> Christian Hopps writes: >>> >>>> >>>> Sorry I trimmed it down as the site def is much larger, the list conta= ins a key: >>>> >>>> list site { >>>> key "site-id"; >>>> leaf site-id { >>>> type site-id; >>>> } >>>> leaf site-type { >>>> mandatory true; >>>> type site-type; >>>> } >>>> // [..cut..] >>>> leaf-list router { >>>> // The combination of when and min-elms appears to allow 0 elem= ents >>>> // for the when matching site types >>>> min-elements 1; >>>> when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; >>>> type leafref { >>>> path "../../../router/router-id"; >>>> } >>>> } >>>> >>>> I=E2=80=99m using yang2dsdl with (both -t data and -t config) to >>>> validate. Both ways (config or data) accept XML with no routers >>>> specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. Bo= th ways correctly reject a >>>> router specified in a non-ots/odws site. >>> >>> This has to do with YANG 1.1 ussue Y18: >>> >>> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 >>> >> >> This does not appear to be related to Y18. > > It is exactly the substance of Y18: If no element is present in = the instance document, the XPath expression cannot be evaluated (if we abid= e by XPath rules) to decide whether the =E2=80=9Crouter=E2=80=9D node is in= the schema or not. That=E2=80=99s where Y18-01 proposes to insert a tentat= ive element and use it as the context node. > OK - you are right -- this is Y18. Our code creates a dummy context node in this case. If the when-stmt is true, the min-elements violation would be generated. Andy >> >> The problem here is that the "when" expression applies >> to the running datastore in the server, not to the request message. > > This is true only for the =E2=80=9Cconfig=E2=80=9D target that validates = an request. However, Chris also said he'd tried yang2dsdl wit= h the =E2=80=9Cdata=E2=80=9D target (-t config), which is essentially the c= ontent of a datastore. I verified the result is indeed as Chris wrote. > > If the =E2=80=9Cwhen=E2=80=9D statement is removed, then missing = is flagged as an error in RELAX NG validation. > > Lada > >> >> You cannot use an off-line tool to validate any NETCONF >> message as if it were processed by a server. None of the constraints >> that apply to a valid configuration datastore can be >> evaluated without all the datastore contents. >> >> >> >> Andy >> >>> If there is no "router" element, the XPath expression in "when" cannot >>> be evaluated because there is no context node for such an evaluation. >>> >>> So the validation procedure assumes the XPath expression *might* be tru= e >>> and doesn't flag missing "router" as an error. >>> >>> The other option would be to flag missing "router" always as an error, >>> even if "site-type" is neither "ots" nor "odws", but I thought it was >>> better to have occassional false negatives than false positives. >>> >>> Lada >>> >>>> >>>> >>>> Thanks, >>>> Chris. >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Mon Jan 12 06:22:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423E91A9151; Mon, 12 Jan 2015 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoxOJ6mRj5CX; Mon, 12 Jan 2015 06:22:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954441A1EEF; Mon, 12 Jan 2015 06:22:39 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 28DA013FACA; Mon, 12 Jan 2015 15:22:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421072558; bh=1gGm/4INHy/skDkxyPG8UVi2xzg+xw6j+bwGi/4mxZE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lpNkOsBdQB3HO88AcdStT7K66ykOXSPHIebA+5m0xw2qGoUM9kQDQaL7f4yWKTHT4 5U8MkJAVFYW2xesNPVIo4hY3sgQKmsKwq6nEv0lBLVCURsSx2xZyosaemz3txgQfs3 mZzUMwkXtMFZDTiP7KJpcbMnYMwFYNxoWqTgghBs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 12 Jan 2015 15:22:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:22:42 -0000 > On 12 Jan 2015, at 15:05, Andy Bierman wrote: >=20 > On Mon, Jan 12, 2015 at 5:34 AM, Ladislav Lhotka = wrote: >>=20 >>> On 12 Jan 2015, at 13:42, Andy Bierman wrote: >>>=20 >>> On Mon, Jan 12, 2015 at 3:59 AM, Ladislav Lhotka = wrote: >>>> Hi Christian, >>>>=20 >>>> Christian Hopps writes: >>>>=20 >>>>>=20 >>>>> Sorry I trimmed it down as the site def is much larger, the list = contains a key: >>>>>=20 >>>>> list site { >>>>> key "site-id"; >>>>> leaf site-id { >>>>> type site-id; >>>>> } >>>>> leaf site-type { >>>>> mandatory true; >>>>> type site-type; >>>>> } >>>>> // [..cut..] >>>>> leaf-list router { >>>>> // The combination of when and min-elms appears to allow 0 = elements >>>>> // for the when matching site types >>>>> min-elements 1; >>>>> when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; >>>>> type leafref { >>>>> path "../../../router/router-id"; >>>>> } >>>>> } >>>>>=20 >>>>> I=E2=80=99m using yang2dsdl with (both -t data and -t config) to >>>>> validate. Both ways (config or data) accept XML with no routers >>>>> specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 = sites. Both ways correctly reject a >>>>> router specified in a non-ots/odws site. >>>>=20 >>>> This has to do with YANG 1.1 ussue Y18: >>>>=20 >>>> = https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 >>>>=20 >>>=20 >>> This does not appear to be related to Y18. >>=20 >> It is exactly the substance of Y18: If no element is present = in the instance document, the XPath expression cannot be evaluated (if = we abide by XPath rules) to decide whether the =E2=80=9Crouter=E2=80=9D = node is in the schema or not. That=E2=80=99s where Y18-01 proposes to = insert a tentative element and use it as the context node. >>=20 >=20 >=20 > OK - you are right -- this is Y18. > Our code creates a dummy context node in this case. > If the when-stmt is true, the min-elements violation > would be generated. Right, but this is really difficult to do via DSDL mapping because the = RELAX NG schema generated from the YANG data model doesn=E2=80=99t = depend on a particular instance document, and RELAX NG doesn=E2=80=99t = do XPath evaluation. Lada >=20 > Andy >=20 >=20 >>>=20 >>> The problem here is that the "when" expression applies >>> to the running datastore in the server, not to the request message. >>=20 >> This is true only for the =E2=80=9Cconfig=E2=80=9D target that = validates an request. However, Chris also said he'd tried = yang2dsdl with the =E2=80=9Cdata=E2=80=9D target (-t config), which is = essentially the content of a datastore. I verified the result is indeed = as Chris wrote. >>=20 >> If the =E2=80=9Cwhen=E2=80=9D statement is removed, then missing = is flagged as an error in RELAX NG validation. >>=20 >> Lada >>=20 >>>=20 >>> You cannot use an off-line tool to validate any NETCONF >>> message as if it were processed by a server. None of the = constraints >>> that apply to a valid configuration datastore can be >>> evaluated without all the datastore contents. >>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>> If there is no "router" element, the XPath expression in "when" = cannot >>>> be evaluated because there is no context node for such an = evaluation. >>>>=20 >>>> So the validation procedure assumes the XPath expression *might* be = true >>>> and doesn't flag missing "router" as an error. >>>>=20 >>>> The other option would be to flag missing "router" always as an = error, >>>> even if "site-type" is neither "ots" nor "odws", but I thought it = was >>>> better to have occassional false negatives than false positives. >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Chris. >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 12 06:40:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7CD1A9252 for ; Mon, 12 Jan 2015 06:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwZJpjGlXTIR for ; Mon, 12 Jan 2015 06:40:52 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212F91A9241 for ; Mon, 12 Jan 2015 06:40:51 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 326A2B7AB63BB; Mon, 12 Jan 2015 14:40:46 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t0CEcved003425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 09:40:48 -0500 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 09:40:01 -0500 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder Thread-Topic: [netmod] VRFY :Y16: module advertisement optimization Thread-Index: AQHQKob0JUmYGFy4rUOnAxO4aFq6Npy4R0MQgASC24D//8tkUA== Date: Mon, 12 Jan 2015 14:40:01 +0000 Message-ID: References: <20150107143343.GB13482@elstar.local> <20150112124543.GA77455@elstar.local> In-Reply-To: <20150112124543.GA77455@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y16: module advertisement optimization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 14:40:55 -0000 Thanks. =20 We could consider referencing that RFC 6470 netconf-capability-change in wh= atever text we use for this id-of-module-set concept and discussing interac= tions with it. =20 I suppose we don't really want to go back and change the netconf-capability= -change in RFC6470 to include the id-of-module-set so maybe we recommend th= at the client do a request if a server sends = a netconf-capability-change notification ? Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, January 12, 2015 7:46 AM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y16: module advertisement optimization On Fri, Jan 09, 2015 at 09:01:36PM +0000, Sterne, Jason (Jason) wrote: > Is there a potential race condition between receiving the and the results of the ? >=20 > I suppose this is pretty unlikely in most servers but if any future serve= rs have capabilities that can change somewhat dynamically then we may want = to include the in the response to the request (to bind the capabilities to a signature) so the client= can do a double check that they are still working with the same . >=20 > The hello should still include the . This makes sense to me. =20 > On another note -> is there any need out there to allow a server to adver= tise (async) to a client that it's capabilities have changed ? I could im= agine, for example, a system that supports in service upgrades (and manages= to keep the NETCONF session going during the upgrade) could suddenly have = some different capabilities. > There is netconf-capability-change defined in RFC 6470. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 12 07:15:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B03D1AC3AD for ; Mon, 12 Jan 2015 07:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O6ugIM5TM0n for ; Mon, 12 Jan 2015 07:15:50 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2D31AC3B1 for ; Mon, 12 Jan 2015 07:15:49 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id s18so24534876lam.2 for ; Mon, 12 Jan 2015 07:15:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6mR0TyZR3HRAcIEDGGHZuf3knubAYaf0YcI8TML7pjM=; b=V2uCVwYeKWWmTIdF7T+so9PtY4trVRodwk8zmoM6k2agA9ziRYZBAjujEvZC0A98oZ HmIuu3uOJbtr78x+wIUL+BfJ8VOE/0i6r9OPSfevl1JSB4rFynfJrBakCyuqaVB7lVmj Ren9FE8GEb8BbTwt1JZGSAYZiTv26gjU73miU97rOKj6xlP1PHIWyTdXete05ufbgpGA 43jsA0oexCqD+meHOeDHDQNEdSuA+J60HKSqcZ1ocuJ8qavg0Os018v0D6enq0yJY61S 6p435/yNuWXw/lMPAcvbDlnWLE21JTR5KMfeUBU9zpC9yYWzySkeflixJJ5nJKydiZAf m13w== X-Gm-Message-State: ALoCoQle7+aT7k/nGnuiL6GaEE9glmY/OpnAZ4xpQZnei7XpWQq6uE1D2dUuvR5jodHnSAAyZBvW MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr37113345lbz.100.1421075748071; Mon, 12 Jan 2015 07:15:48 -0800 (PST) Received: by 10.112.160.41 with HTTP; Mon, 12 Jan 2015 07:15:47 -0800 (PST) In-Reply-To: References: <20150107143343.GB13482@elstar.local> <20150112124543.GA77455@elstar.local> Date: Mon, 12 Jan 2015 07:15:47 -0800 Message-ID: From: Andy Bierman To: "Sterne, Jason (Jason)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y16: module advertisement optimization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 15:15:52 -0000 On Mon, Jan 12, 2015 at 6:40 AM, Sterne, Jason (Jason) wrote: > Thanks. > > We could consider referencing that RFC 6470 netconf-capability-change in = whatever text we use for this id-of-module-set concept and discussing inter= actions with it. > > I suppose we don't really want to go back and change the netconf-capabili= ty-change in RFC6470 to include the id-of-module-set so maybe we recommend = that the client do a request if a server send= s a netconf-capability-change notification ? > I have some concerns with Y19. The netconf-capability-change notification is for a change to any NETCONF capability, not just YANG module capabilities. The module-set-id could augment the existing notification if needed. Seems like there are 2 options: 1) define a new notification just for YANG module-set-id changes The netconf-capability-change will also be generated because it is a NETCONF capability change 2) augment netconf-capability-change with the module-set-id and the client needs to check (maybe a NETCONF capability like :candidate changed so the module-set-id will not change) > Jason Andy > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, January 12, 2015 7:46 AM > To: Sterne, Jason (Jason) > Cc: netmod@ietf.org > Subject: Re: [netmod] VRFY :Y16: module advertisement optimization > > On Fri, Jan 09, 2015 at 09:01:36PM +0000, Sterne, Jason (Jason) wrote: >> Is there a potential race condition between receiving the and the results of the ? >> >> I suppose this is pretty unlikely in most servers but if any future serv= ers have capabilities that can change somewhat dynamically then we may want= to include the in the response to the request (to bind the capabilities to a signature) so the clien= t can do a double check that they are still working with the same . >> >> The hello should still include the . > > This makes sense to me. > >> On another note -> is there any need out there to allow a server to adve= rtise (async) to a client that it's capabilities have changed ? I could i= magine, for example, a system that supports in service upgrades (and manage= s to keep the NETCONF session going during the upgrade) could suddenly have= some different capabilities. >> > > There is netconf-capability-change defined in RFC 6470. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jan 12 08:10:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2191AC3BA for ; Mon, 12 Jan 2015 08:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9HOhrMLTX0T for ; Mon, 12 Jan 2015 08:10:54 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECDC1AC3B1 for ; Mon, 12 Jan 2015 08:10:54 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id l4so18440509lbv.12 for ; Mon, 12 Jan 2015 08:10:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y9C5jPFyyV+fXh5FBQhQwyah6eGX0aZ010JdJlQedyc=; b=JUYuru8geFFJ/rKhoY/uFT4TKrzD6pYjWoxa9ARg0p6cI8gDweXG7n1jQXijp2SMk3 hiIze3ZolEcUniKcVh6cRd1vvh2slIlKLDqBaUq7dRSNEHFF8s0kmyf+t+/x/D1ERsDb qiYaNa/kdERU+aKoYIzxBZz66C1XKgWpDFF1VP+MKLt9/oaP4EHrGHZKrJgMCeOGfCrG aZyZtwm5YSQ0BRKyeYk2GXpqr+akEMQoXq5lhScx2Iu19fwxh66PAymqyJjjHODMVhSw mfYUVkflD8VFjlgxYuL4yLKDR2bX1hH7275EMW0ILUck3d6fvvVHBlsKMIPtuXHwVid+ vI8w== X-Gm-Message-State: ALoCoQn3eHbjU7MgRPT3KGMlm/zKs+SoE+yZzSUKQ3/+5qynwFf+/PlI4KvhKgVQMRUmKdYfLRkN MIME-Version: 1.0 X-Received: by 10.112.25.7 with SMTP id y7mr37170122lbf.94.1421079052760; Mon, 12 Jan 2015 08:10:52 -0800 (PST) Received: by 10.112.160.41 with HTTP; Mon, 12 Jan 2015 08:10:52 -0800 (PST) In-Reply-To: References: Date: Mon, 12 Jan 2015 08:10:52 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: YANG Doctors , NETMOD Working Group Subject: Re: [netmod] [yang-doctors] Question on yang? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 16:10:56 -0000 On Mon, Jan 12, 2015 at 6:22 AM, Ladislav Lhotka wrote: > >> On 12 Jan 2015, at 15:05, Andy Bierman wrote: >> >> On Mon, Jan 12, 2015 at 5:34 AM, Ladislav Lhotka wrote: >>> >>>> On 12 Jan 2015, at 13:42, Andy Bierman wrote: >>>> >>>> On Mon, Jan 12, 2015 at 3:59 AM, Ladislav Lhotka wrote= : >>>>> Hi Christian, >>>>> >>>>> Christian Hopps writes: >>>>> >>>>>> >>>>>> Sorry I trimmed it down as the site def is much larger, the list con= tains a key: >>>>>> >>>>>> list site { >>>>>> key "site-id"; >>>>>> leaf site-id { >>>>>> type site-id; >>>>>> } >>>>>> leaf site-type { >>>>>> mandatory true; >>>>>> type site-type; >>>>>> } >>>>>> // [..cut..] >>>>>> leaf-list router { >>>>>> // The combination of when and min-elms appears to allow 0 ele= ments >>>>>> // for the when matching site types >>>>>> min-elements 1; >>>>>> when "../site-type =3D 'ots' or ../site-type =3D 'odws'"; >>>>>> type leafref { >>>>>> path "../../../router/router-id"; >>>>>> } >>>>>> } >>>>>> >>>>>> I=E2=80=99m using yang2dsdl with (both -t data and -t config) to >>>>>> validate. Both ways (config or data) accept XML with no routers >>>>>> specified in =E2=80=98ots=E2=80=99 or =E2=80=98odws=E2=80=99 sites. = Both ways correctly reject a >>>>>> router specified in a non-ots/odws site. >>>>> >>>>> This has to do with YANG 1.1 ussue Y18: >>>>> >>>>> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-19 >>>>> >>>> >>>> This does not appear to be related to Y18. >>> >>> It is exactly the substance of Y18: If no element is present i= n the instance document, the XPath expression cannot be evaluated (if we ab= ide by XPath rules) to decide whether the =E2=80=9Crouter=E2=80=9D node is = in the schema or not. That=E2=80=99s where Y18-01 proposes to insert a tent= ative element and use it as the context node. >>> >> >> >> OK - you are right -- this is Y18. >> Our code creates a dummy context node in this case. >> If the when-stmt is true, the min-elements violation >> would be generated. > > Right, but this is really difficult to do via DSDL mapping because the RE= LAX NG schema generated from the YANG data model doesn=E2=80=99t depend on = a particular instance document, and RELAX NG doesn=E2=80=99t do XPath evalu= ation. > You would have to generate a new config document with the context node in i= t. This is actually one of the easier aspects of implementing when-stmt correctly within a real server. (For some definition of "correct", dependi= ng on the evaluation order and other details). > Lada > >> >> Andy > Andy From nobody Mon Jan 12 20:29:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90FA1A8855 for ; Mon, 12 Jan 2015 20:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btGeORemsnAJ for ; Mon, 12 Jan 2015 20:29:29 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF661A1AB9 for ; Mon, 12 Jan 2015 20:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3505; q=dns/txt; s=iport; t=1421123369; x=1422332969; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=aCjKfGMSBjtOdggaTAHSVKuT6GvqSqbV4gmo0KnuY8I=; b=FOY5ITJKQ82tTxCBRm0hkCP6UoAUGPqPl2/Ey5Y1UlFIHzoKaJVInFvh 4vx6LfgaAVfDH+VUOSd7mCYRBE9izgzQUBPM1M9U44p/HgVIVi9I3yIYA 0lnpe2gmJz77AWzins0c2LKRDE7es1N5wmOSCB2+2b/lcMhmgLv4Yvv4t Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAOqdtFStJA2M/2dsb2JhbABbgwZSWATFfwqFJ0oCgQ9DAQEBAQF9hA0BAQQBAQE3NB0BCDY3CyUCBAESiCwNzTkBAQEBAQEEAQEBAQEBAQEajyJehCkFjGKBW4NFhUiBDzCCQo13IoNub4EEQX4BAQE X-IronPort-AV: E=Sophos;i="5.07,747,1413244800"; d="scan'208";a="112706242" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 13 Jan 2015 04:29:28 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0D4TSuj016966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 04:29:28 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.2]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 22:29:28 -0600 From: "Dana Blair (dblair)" To: "Sachin Jain (EABU)" , "netmod@ietf.org" Thread-Topic: [netmod] Comments - I-D Action: draft-ietf-netmod-acl-model-00.txt Thread-Index: AQHQF1aC1L+Dn1SJtkOBfG/j4YzGAJy9tRyA Date: Tue, 13 Jan 2015 04:29:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.51.46] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D7544E8C906004882D9771EEFD8092F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Comments - I-D Action: draft-ietf-netmod-acl-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 04:29:35 -0000 Hi Sachin, Comments below. On 12/13/14, 11:29 PM, "Sachin Jain (EABU)" wrote: >Dear Authors > >Couple of initial comments on the draft are: > >1. We to include a few more modules (or submodules) in the base draft. >IMO, these should be applicable to most of the ACL implementations thats >why I think they should be part of base ACL definition. > > At a high level, following represents what could be new sub-modules >under ietf-acl. > >module: ietf-acl > +-- access-lists > | > +-- policers > | > +-- bind-points > | > +-- company-proprietary-objects > >container policers { > Description > "Defines a list of policers. Each policer defines a set of policing >parameters to rate limit or meter the traffic. One or more ACE can refer >to a particular policer. This could be above the current way of defining >policing parameters in the draft." >} > >container bind-points { > description > "Defines list of bind points in the data path where the access-list is >applied to take affect. Each bind point in uniquely defined by the ACL, >the forwarding element that its applied to and along with its direction. >For eg. an ACL could be bound to interface or a FIB in input or output >direction. This should be extendible to include other company proprietary >forwarding elements." >} The ideas above are interesting but should be published in a seperate draft that augments the ACL model. You can see examples in the existing draft. > >2. > >Section 3.1 - Can we add a field 'operand' at ACE/ACL/match level? That >will make the model very generic in terms of match expression. > >In the current form, its hardcoded to AND among matches for a ACE and OR >among ACE for a ACL. We will consider adding this to the existing model but need to see an example augmentation. thanks, Dana > >Regards >Sachin > > > >On 11/12/14 1:06 AM, "internet-drafts@ietf.org" >wrote: > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the NETCONF Data Modeling Language Working >>Group of the IETF. >> >> Title : Network Access Control List (ACL) YANG Data >>Model >> Authors : Dean Bogdanovic >> Kiran Agrahara Sreenivasa >> Lisa Huang >> Dana Blair >> Filename : draft-ietf-netmod-acl-model-00.txt >> Pages : 23 >> Date : 2014-11-10 >> >>Abstract: >> This document describes a data model of Access Control List (ACL) >> basic building blocks. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-netmod-acl-model-00 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jan 13 08:20:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A2F1A8AF8 for ; Tue, 13 Jan 2015 08:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNbyGD-DqO-o for ; Tue, 13 Jan 2015 08:20:38 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02541A8AAC for ; Tue, 13 Jan 2015 08:20:38 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 13 Jan 2015 16:20:35 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.224]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.224]) with mapi id 15.01.0049.002; Tue, 13 Jan 2015 16:20:35 +0000 From: Dean Bogdanovic To: Linda Dunbar Thread-Topic: Questions to draft-ietf-netmod-acl-model-00 Thread-Index: AdAsX9CwibQXa732QGuEkrDUKZcJngC7QoyA Date: Tue, 13 Jan 2015 16:20:35 +0000 Message-ID: <378B6DFC-AD6A-4C6D-BB21-D17765876ED7@juniper.net> References: <4A95BA014132FF49AE685FAB4B9F17F645E8E3DD@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645E8E3DD@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BN1PR05MB423; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(189002)(199003)(164054003)(97736003)(66066001)(16236675004)(77156002)(87936001)(83716003)(57306001)(106356001)(46102003)(99286002)(122556002)(64706001)(36756003)(68736005)(62966003)(230783001)(102836002)(40100003)(19580395003)(19580405001)(50986999)(101416001)(50226001)(2900100001)(82746002)(2950100001)(2656002)(33656002)(76176999)(110136001)(92566002)(105586002)(86362001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_378B6DFCAD6A4C6DBB21D17765876ED7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 16:20:35.1508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB423 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Questions to draft-ietf-netmod-acl-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 16:20:46 -0000 --_000_378B6DFCAD6A4C6DBB21D17765876ED7junipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Linda, please see inline On Jan 9, 2015, at 5:58 PM, Linda Dunbar > wrote: Dean, et al, On Page 15, the definition of =93metadata=94 missed potential matching crit= eria of =93packet length=94, which is described in the =93metadata=94 defin= ition. Is it possible to add more constraints, such as =93apply ACL when there is = congestion=94, etc? What is currently in the draft, is just an example how to extend the model,= so what you are proposing is allowed, but we, authors, believe that the c= urrent examples give the way to to add standard and proprietary extensions = to the model. We are trying to keep the basic ACL model as simple as possib= le, where extensions would go into other drafts. On Page 12, the =93acl-transport-header-fields=94 only allows port range. I= f the matching criteria is a specific port number, is it still necessary to= have both =93lower-port=94 and =93upper-port=94 specified? If it is just specific port number, you specify only lower-port (as this is= mandatory), upper port doesn't have to be specified. On Figure 2 (Page 18), the =93=94 below =93=94 should rea= lly be =93=94, isn=92t it? Thank you for the catch. It is a typo. Dean Thanks, Linda Dunbar --_000_378B6DFCAD6A4C6DBB21D17765876ED7junipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <771F78DFC222A140A34FF2A55E615851@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Linda, please see inline
On Jan 9, 2015, at 5:58 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

Dean, et al,
 
On Page 15, the definition of =93metadata=94 missed potential matching crit= eria of =93packet length=94, which is described in the =93metadata=94 defin= ition.
Is it possible to add more constraints, such as =93apply ACL when there is = congestion=94, etc?

What is currently in the draft, is just an example how to extend the model,= so what you are proposing is allowed, but we, authors, believe that  = the current examples give the way to to add standard and proprietary extens= ions to the model. We are trying to keep the basic ACL model as simple as possible, where extensions would go into = other drafts.
 
 
On Page 12, the =93acl-transport-header-fields=94 only allows port range. I= f the matching criteria is a specific port number, is it still necessary to= have both =93lower-port=94 and =93upper-port=94 specified?

If it is just specific port number, you specify only lower-port (as this is= mandatory), upper port doesn't have to be specified.
 
 
On Figure 2 (Page 18), the =93<actions/>=94  below =93<deny/&= gt;=94 should really be =93</action>=94, isn=92t it?
Thank you for the catch. It is a typo.

Dean

 
 
Thanks, Linda Dunbar

--_000_378B6DFCAD6A4C6DBB21D17765876ED7junipernet_-- From nobody Tue Jan 20 14:42:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA771A0063 for ; Tue, 20 Jan 2015 14:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB6Zm7PvcpgJ for ; Tue, 20 Jan 2015 14:42:23 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2341A005C for ; Tue, 20 Jan 2015 14:42:23 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so12659998lab.12 for ; Tue, 20 Jan 2015 14:42:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4A/XRveTQm1DzJ+jk72+8LBIkSIdprWaVAIFT4aanxs=; b=ZpTbWPhARnqqxeVJLDX1tEJe36QGIjXlu3KM65fLC40NGUFDk8MRcL4Z7LHM65bh/9 685JkkRIrJhTiFnwHzw69AvpGxE/shTK/eJYebPKxH5k83TeWe+uffIbd4ZpZItQZ9r2 PJWTp692tkoJY6A1O+VOAOxKkflwJF0kPB+gqTBzY2QcYMFMnWSIR8zNk33LVqMY1lr2 sJ5KK7nqMLeec6ub4TtMtSciaRr/FxJwXiwoCvJRrY22IFdqhYFsDVkBqOr5UfMjIQ3N DFUj/P356dAqI6mLY11ai5wZtz2ihaE3PmLHPIaAr9q+G9ccptzTx1g0p+JJhYBligty +8mQ== X-Gm-Message-State: ALoCoQkPqDCEL1nb41Twk01rc/Y9WYDN6xO3qgehdOVM92GuWOmIWbUvlT1eNkwhJ0SfN3VcfM5w MIME-Version: 1.0 X-Received: by 10.152.5.198 with SMTP id u6mr41744958lau.42.1421793741840; Tue, 20 Jan 2015 14:42:21 -0800 (PST) Received: by 10.112.160.41 with HTTP; Tue, 20 Jan 2015 14:42:21 -0800 (PST) Date: Tue, 20 Jan 2015 14:42:21 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [netmod] Virtual Interim Jan. 21 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 22:42:25 -0000 Hi, The IESG announcement 11/5/14 says there is an interim meeting tomorrow. Is there an agenda? Will all co-authors attend? thanks, Andy From nobody Tue Jan 20 15:02:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F021A0078 for ; Tue, 20 Jan 2015 15:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gPioRzQbUyf for ; Tue, 20 Jan 2015 15:02:06 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3741A0075 for ; Tue, 20 Jan 2015 15:02:05 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 59A012CB9C4F; Tue, 20 Jan 2015 18:02:05 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 20 Jan 2015 18:02:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5DA5E354-761B-4498-9E66-C6821CA1AB08@lucidvision.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Virtual Interim Jan. 21 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 23:02:07 -0000 For Yang 1.1. or modeling? If it is for the latter, it is not = happening. I need to go reboot the schedule/webex/etc... --Tom > On Jan 20, 2015:5:42 PM, at 5:42 PM, Andy Bierman = wrote: >=20 > Hi, >=20 > The IESG announcement 11/5/14 says there is an interim meeting > tomorrow. Is there an agenda? Will all co-authors attend? >=20 >=20 > thanks, > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Tue Jan 20 17:10:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F241A00F0 for ; Tue, 20 Jan 2015 17:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72__sK7QVPUP for ; Tue, 20 Jan 2015 17:10:17 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3B51A00E7 for ; Tue, 20 Jan 2015 17:10:17 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so36739490lbi.10 for ; Tue, 20 Jan 2015 17:10:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dYdJTPL7t2NanVekYdy5oVy1bqwxJ0djufaJXWf7dRE=; b=jqpgEWVjqhOXKRiUmJ1Qh7+Skpk1V1haQB0Ny2Gs3TVy3rTrqLF8p+Ldn3yQC+bCZa NvWC8UdV4M8vqk6ZJFqiDkVN//Fb69pTkzSLOGFKOFxcUU4dZg/RdxNrQHHVnAQHwI7K NZd3oGRpPGJq2kt9HRtsZQEaYyR5ibNwmqUVUP0B5D931asTmeeVdav9Gr/ygAMI3MNy 2pFS1YOSS6lTqOuf0JfsOsl1BsZye1H7Vxm/I3N18eWTvxX2CdveArQVDQhUrpsgbSV1 YaE+PvZ6EdmLuZNuRvPYcXQAA3E9TocanIHMsutTXt5bZkYB1U4k6pK/gJghDf5p19Xo 3+Tw== X-Gm-Message-State: ALoCoQkWlKgy5xRBLKIn0Tb9aqAt0COWTwRKiSctQHAPKOB8oK4L6R4jYNLJNxKAgSIk7DYnmjUj MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr5696941lab.1.1421802615862; Tue, 20 Jan 2015 17:10:15 -0800 (PST) Received: by 10.112.160.41 with HTTP; Tue, 20 Jan 2015 17:10:15 -0800 (PST) In-Reply-To: <5DA5E354-761B-4498-9E66-C6821CA1AB08@lucidvision.com> References: <5DA5E354-761B-4498-9E66-C6821CA1AB08@lucidvision.com> Date: Tue, 20 Jan 2015 17:10:15 -0800 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Virtual Interim Jan. 21 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 01:10:20 -0000 On Tue, Jan 20, 2015 at 3:02 PM, Thomas D. Nadeau wrote: > > For Yang 1.1. or modeling? If it is for the latter, it is not happening. I need to go reboot the schedule/webex/etc... > The IESG announcement does not indicate which NETMOD Dept. is meeting. The intent (NETCONF as well) was that many meetings would be scheduled (every 2 weeks) but meetings might be cancelled, depending on need. IMO if there is no specific agenda then there is no real need for a meeting. All of the open YANG 1.1 issues are either blocked because of no consensus or waiting on input from somebody. > --Tom > Andy > > >> On Jan 20, 2015:5:42 PM, at 5:42 PM, Andy Bierman wrote: >> >> Hi, >> >> The IESG announcement 11/5/14 says there is an interim meeting >> tomorrow. Is there an agenda? Will all co-authors attend? >> >> >> thanks, >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From nobody Tue Jan 20 23:30:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC11A0389 for ; Tue, 20 Jan 2015 23:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWZDnu-m7_JG for ; Tue, 20 Jan 2015 23:30:08 -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 EA0D31A038A for ; Tue, 20 Jan 2015 23:30:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6F387F8B; Wed, 21 Jan 2015 08:30:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 03-YmEZY0tm8; Wed, 21 Jan 2015 08:29:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Jan 2015 08:30:06 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D33C620034; Wed, 21 Jan 2015 08:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u6hnD6qFn37C; Wed, 21 Jan 2015 08:30:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCB1D2002F; Wed, 21 Jan 2015 08:30:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6030530DF313; Wed, 21 Jan 2015 08:30:03 +0100 (CET) Date: Wed, 21 Jan 2015 08:30:02 +0100 From: Juergen Schoenwaelder To: "Thomas D. Nadeau" Message-ID: <20150121073002.GA31780@elstar.local> Mail-Followup-To: "Thomas D. Nadeau" , Andy Bierman , NETMOD Working Group References: <5DA5E354-761B-4498-9E66-C6821CA1AB08@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5DA5E354-761B-4498-9E66-C6821CA1AB08@lucidvision.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Virtual Interim Jan. 21 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 07:30:10 -0000 On Tue, Jan 20, 2015 at 06:02:04PM -0500, Thomas D. Nadeau wrote: > > For Yang 1.1. or modeling? If it is for the latter, it is not happening. I need to go reboot the schedule/webex/etc... > Tom, I do not recall that you scheduled any data modeling meetings. This is the regular YANG 1.1 meeting. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 02:21:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615BB1A1A03 for ; Wed, 21 Jan 2015 02:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5PenrnnfQt0 for ; Wed, 21 Jan 2015 02:21:49 -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 4D1711A1A02 for ; Wed, 21 Jan 2015 02:21:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 206B2E57; Wed, 21 Jan 2015 11:21:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id p9VbIQWKjx5y; Wed, 21 Jan 2015 11:21: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, 21 Jan 2015 11:21:47 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0255C20034; Wed, 21 Jan 2015 11:21:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FkTLvndA4wbG; Wed, 21 Jan 2015 11:21:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 547C22002F; Wed, 21 Jan 2015 11:21:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3A49F30DF6B3; Wed, 21 Jan 2015 11:21:44 +0100 (CET) Date: Wed, 21 Jan 2015 11:21:44 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150121102144.GE32055@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150108.103728.1499085884469962335.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:21:50 -0000 On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. > > I don't think Y34-04 is sufficient. If I understand Y34-04 (add > 'root) correctly, the difference between it and Y34-02 (add 'anydata') > is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as > 'anydata' with the constraint that it only can hande top-level nodes. > > As an example of why this is not sufficient, YANG PATCH uses anyxml > with non-top-level nodes. It would not be possible to use 'root' in > this case. 'anydata' would be a better match. > Andy, can you please respond to this since you created Y34-04? I now hear two people in favour of Y34-02 and we had this back in July 2014: 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out a concrete proposal. So is the main delta of Y34-04 compared to Y34-02 (i) the additional text (the three list items) or (ii) additional restrictions of "root" to top-level nodes. (The Y34-04 referes to ncx:root which is not known to everybody.) Would adoption of Y34-02 with the additional text (the three list items) of Y34-04 be a workable solution? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 02:32:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB741A1A07 for ; Wed, 21 Jan 2015 02:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_esvhoH4w0g for ; Wed, 21 Jan 2015 02:31:58 -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 74A801A19EF for ; Wed, 21 Jan 2015 02:31:58 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 47D99A8E; Wed, 21 Jan 2015 11:31:57 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sND7gKp23G2T; Wed, 21 Jan 2015 11:31:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Jan 2015 11:31:56 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0561020034; Wed, 21 Jan 2015 11:31:56 +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 jE8atsHAju8B; Wed, 21 Jan 2015 11:24:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2CF12002F; Wed, 21 Jan 2015 11:31:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF18D30DF745; Wed, 21 Jan 2015 11:31:54 +0100 (CET) Date: Wed, 21 Jan 2015 11:31:54 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150121103154.GA32345@elstar.local> Mail-Followup-To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" References: <20150106212118.GB11692@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:32:01 -0000 On Thu, Jan 08, 2015 at 09:38:57AM +0100, Ladislav Lhotka wrote: > Kent Watsen writes: > > >> - who believes a mechanism to define metadata annotations > >> should be standardized > > > > > > Not yet. > > > > First I think we need to clear the way for attributes to be used safely. > > We used attributes in and also with-defaults, but in both > > cases the client either accepted the contract of the protocol (base:1.1) > > or explicitly opted into receiving the attributes (report-all-tagged). > > Specifically, what happens to a legacy client if the attribute MUST be > > semantically understood (e.g., the enabled/inactive) in order to correctly > > process the data? Even if we don't care about the client, we might > > want > > You are right but I think we have two separate issues here: > > 1. Annotations are defined via an extension, and that by definition > means the client is free to ignore them. > > 2. The existing sentiment of letting a (legacy) client pick only a > subset of modules from those advertised by the server means that the > client in any case cannot be expected to support an annotation that > is defined in a YANG module. > > As for #1, it would help to make "annotation" a built-in statement, and > that was actually one of the questions I asked earlier: I believe we need to work with extensions, we can't revise the YANG specifications each time an addition is needed. My understanding is that this particular extension provides the mechanics to define and encode metadata. It will be up to concrete metadata definitions to figure out how to make things work such that ignorant clients and servers will continue to function. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 02:35:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957A61A1A02 for ; Wed, 21 Jan 2015 02:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtaIEd8MpTQJ for ; Wed, 21 Jan 2015 02:35:41 -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 EEB1A1A19EF for ; Wed, 21 Jan 2015 02:35:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C1B801117 for ; Wed, 21 Jan 2015 11:35:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2p4pT_hkWnO2 for ; Wed, 21 Jan 2015 11:35:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 21 Jan 2015 11:35:39 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EDF420035 for ; Wed, 21 Jan 2015 11:35:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id p81YIhCAAjZU; Wed, 21 Jan 2015 11:27:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37A922002F; Wed, 21 Jan 2015 11:35:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C831A30DF780; Wed, 21 Jan 2015 11:35:38 +0100 (CET) Date: Wed, 21 Jan 2015 11:35:38 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150121103538.GB32345@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150108082459.GA15583@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150108082459.GA15583@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] VRFY :Y59: restrict use of 64-bit numbers in XPath expressions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:35:42 -0000 On Thu, Jan 08, 2015 at 09:24:59AM +0100, Juergen Schoenwaelder wrote: > The 2015-01-07 virtual interim meeting proposal is to adopt Y59-01. > Please speak up by Thursday 2015-01-15 if you disagree with this > proposal. > > For more details, see the issues list and the virtual interim meeting > minutes available here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > Since there were no comments on the mailing list, I have moved this issue to EDIT. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 02:37:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9968E1A19F4 for ; Wed, 21 Jan 2015 02:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k76qWd9rD7V4 for ; Wed, 21 Jan 2015 02:37:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03ED1A0673 for ; Wed, 21 Jan 2015 02:37:34 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id 8E9CE13FD88; Wed, 21 Jan 2015 11:37:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421836653; bh=O0XTVARxhwy2KHt0Yv1+XzGLTOTaU0wON/s5+tfJWxM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dYQ4Q+IhIoxIf6loON0HYhPdCFJ3yzHC6corv+7f5eyLcapBEp8fo8tDy2xEu1Y4h x53bZIypW9YGNTQbEHAGcmir41KpYejGFyt+c9jHjHAnuok6ksqJZYb4bcXahE6wMB VQ2lQYQwVUcZ9jgl6mY36HxEyTSlzVYYgexy7g3o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150121103154.GA32345@elstar.local> Date: Wed, 21 Jan 2015 11:37:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <130009F7-7BFA-4567-93A0-DECB91278591@nic.cz> References: <20150106212118.GB11692@elstar.local> <20150121103154.GA32345@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:37:36 -0000 > On 21 Jan 2015, at 11:31, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 08, 2015 at 09:38:57AM +0100, Ladislav Lhotka wrote: >> Kent Watsen writes: >>=20 >>>> - who believes a mechanism to define metadata annotations >>>> should be standardized >>>=20 >>>=20 >>> Not yet. =20 >>>=20 >>> First I think we need to clear the way for attributes to be used = safely. >>> We used attributes in and also with-defaults, but in = both >>> cases the client either accepted the contract of the protocol = (base:1.1) >>> or explicitly opted into receiving the attributes = (report-all-tagged). >>> Specifically, what happens to a legacy client if the attribute MUST = be >>> semantically understood (e.g., the enabled/inactive) in order to = correctly >>> process the data? Even if we don't care about the client, we might >>> want >>=20 >> You are right but I think we have two separate issues here: >>=20 >> 1. Annotations are defined via an extension, and that by definition >> means the client is free to ignore them. >>=20 >> 2. The existing sentiment of letting a (legacy) client pick only a >> subset of modules from those advertised by the server means that = the >> client in any case cannot be expected to support an annotation that >> is defined in a YANG module. >>=20 >> As for #1, it would help to make "annotation" a built-in statement, = and >> that was actually one of the questions I asked earlier: >=20 > I believe we need to work with extensions, we can't revise the YANG > specifications each time an addition is needed. >=20 > My understanding is that this particular extension provides the > mechanics to define and encode metadata. It will be up to concrete > metadata definitions to figure out how to make things work such that > ignorant clients and servers will continue to function. Fine with me. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 21 02:37:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A521A1A19 for ; Wed, 21 Jan 2015 02:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9Me5ANuk-zG for ; Wed, 21 Jan 2015 02:37:44 -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 1C0381A19F4 for ; Wed, 21 Jan 2015 02:37:41 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E34A71117 for ; Wed, 21 Jan 2015 11:37:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id M8-MwM6v7_RB for ; Wed, 21 Jan 2015 11:37:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 21 Jan 2015 11:37:39 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38A4C20034 for ; Wed, 21 Jan 2015 11:37:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2TBWt1oDOF6j; Wed, 21 Jan 2015 11:37:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3BB72002F; Wed, 21 Jan 2015 11:37:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7C7C830DF7AD; Wed, 21 Jan 2015 11:37:38 +0100 (CET) Date: Wed, 21 Jan 2015 11:37:38 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150121103738.GC32345@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150107145502.GD13482@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150107145502.GD13482@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] VRFY :Y49: clarify nested submodule behavior X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 10:37:50 -0000 On Wed, Jan 07, 2015 at 03:55:02PM +0100, Juergen Schoenwaelder wrote: > The 2014-12-03 virtual interim meeting proposal is to adopt Y49-04. > Please speak up by Wednesday 2015-01-14 if you disagree with this > proposal. > > For more details, see the issues list and the virtual interim meeting > minutes available here: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > Since there were not further comments, I have moved this issue to the EDIT state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 04:14:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC411A1A23 for ; Wed, 21 Jan 2015 04:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGFM5QKVcagW for ; Wed, 21 Jan 2015 04:14: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 F05FF1A1A1C for ; Wed, 21 Jan 2015 04:14: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 BF2AA71B; Wed, 21 Jan 2015 13:13:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id i-Aw46Nc7Nqe; Wed, 21 Jan 2015 13:13:45 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Jan 2015 13:13:59 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A87F20034; Wed, 21 Jan 2015 13:13:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qsRIfrRFBnpH; Wed, 21 Jan 2015 13:13: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 55D812002F; Wed, 21 Jan 2015 13:13:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D964430E0031; Wed, 21 Jan 2015 13:13:56 +0100 (CET) Date: Wed, 21 Jan 2015 13:13:55 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150121121353.GA32649@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Virtual Interim Jan. 21 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:14:07 -0000 On Tue, Jan 20, 2015 at 02:42:21PM -0800, Andy Bierman wrote: > Hi, > > The IESG announcement 11/5/14 says there is an interim meeting > tomorrow. Is there an agenda? Will all co-authors attend? > The high-level agenda is to work on YANG 1.1. I will post a more detailed status update in a couple of minutes. Yes, it helps if main contributors manage to attend. If not, we can quit early. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 04:24:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A301A1A33 for ; Wed, 21 Jan 2015 04:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNtj38ORXfgY for ; Wed, 21 Jan 2015 04:24:03 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C46FC1A1A36 for ; Wed, 21 Jan 2015 04:23:08 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id CF7781280052 for ; Wed, 21 Jan 2015 13:23:07 +0100 (CET) Date: Wed, 21 Jan 2015 13:24:33 +0100 (CET) Message-Id: <20150121.132433.1505626678838099831.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Y18: fix "when" expression context problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:24:06 -0000 Hi, I had an action point to clarify the evaluation order of when expressions, in Y18. I have updated Y18 with this proposal, in 7.19.5: OLD: The result of the XPath expression is converted to a boolean value using the standard XPath rules. NEW: The result of the XPath expression is converted to a boolean value using the standard XPath rules. If the XPath expression references any node that also has associated "when" statements, these "when" expressions MUST be evaluated first. There MUST NOT be any circular dependencies in these "when" expressions. /martin From nobody Wed Jan 21 04:24:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637A11A1A23 for ; Wed, 21 Jan 2015 04:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YyQA0DpThOt for ; Wed, 21 Jan 2015 04:24: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 B260E1A1A25 for ; Wed, 21 Jan 2015 04:24:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 872A1742 for ; Wed, 21 Jan 2015 13:24:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id X4IeLPWIzMJC for ; Wed, 21 Jan 2015 13:24:05 +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 for ; Wed, 21 Jan 2015 13:24:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9134520035 for ; Wed, 21 Jan 2015 13:24:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zLhPqfdBmGRm; Wed, 21 Jan 2015 13:24:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70C0620034; Wed, 21 Jan 2015 13:24:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F090E30E021F; Wed, 21 Jan 2015 13:24:16 +0100 (CET) Date: Wed, 21 Jan 2015 13:24:15 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150121122412.GB32649@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] yang 1.1 status summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:24:45 -0000 Hi, here is where we are with the YANG 1.1 effort. | Status | Description | Count | |--------+----------------------------------------+-------| | NEW | new issue | 0 | | DEAD | issue has been rejected | 26 | | OPEN | open to discuss | 7 | | VRFY | proposal to verify on the list | 2 | | EDIT | waiting for Martin to do the edits | 3 | | REVIEW | waiting for the WG to review the edits | 21 | | DONE | review has completed | 0 | |--------+----------------------------------------+-------| Not surprisingly, there is a tendency for the more difficult or controversial issues to stay with us the longest. This should not cause our motivation to drop. I think it is natural that the number of issues we can move forward through the state machine is getting smaller towards the end. Here is a more list detailing where I think we are with the issues that are OPEN or that were moved to VRFY recently: * VRFY :Y09: introduce optional keys <> -> apparently, there is no consensus, moving the state of this issue back to OPEN since we are not even in any way close to consensus * VRFY :Y16: module advertisement optimization <> -> we may need to decide whether the netconf-capability-change notification (RFC 6470) should be augmented with a module-set-id or we want to define a more specific notification or we just provide guidance that implementations may want to sync the module-set-id after receiving a netconf-capability-change notification; left in VRFY state for now * VRFY :Y34: remove/deprecate/replace the 'anyxml' statement -> discussion on the mailing list, clarifying the difference between Y34-02 and Y34-04; left in VRFY state for now * VRFY :Y49: clarify nested submodule behavior -> moved to EDIT state * VRFY :Y59: restrict use of 64-bit numbers in XPath expressions -> moved to EDIT state * OPEN :Y18: fix "when" expression context problem -> pending action MB * OPEN :Y25: make enum numbering purely informative and optional -> pending action JS * OPEN :Y26: allow mandatory nodes in augment -> we need concrete proposals how to relax the current rules * OPEN :Y45: better conformance mechanism <> -> some mailing list discussion, how do we make forward progress? one option might be to factor all conformance discusssion and module update rules out of the core YANG specification into a separate document - this does not solve the problem but it might help to factor it out into a separate deliverable * OPEN :Y57: non-unique leaf-list -> ready to be discussed? * OPEN :Y58: associate actions with a data node -> NETCONF seems to support a NACM update to support actions, call ending on 2015-01-22; if NETCONF supports the update, can we move this to EDIT (Andy raised the NACM update is required argument during VRFY) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 04:34:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D4E1A1A25 for ; Wed, 21 Jan 2015 04:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gxY9z0XHQzn for ; Wed, 21 Jan 2015 04:34:00 -0800 (PST) Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CAC1A1A29 for ; Wed, 21 Jan 2015 04:34:00 -0800 (PST) Received: from jva2tc117.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-6.webex.com [64.68.121.241]) by sjmda10.webex.com (Postfix) with ESMTP id A1D292E0 for ; Wed, 21 Jan 2015 12:33:59 +0000 (GMT) Received: from jva2tc117.webex.com (localhost [127.0.0.1]) by jva2tc117.webex.com (Postfix) with ESMTP id 2FBDA9FB3D for ; Wed, 21 Jan 2015 12:33:59 +0000 (GMT) Date: Wed, 21 Jan 2015 12:33:59 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <1421230948.125954.1421843639181.JavaMail.nobody@jva2tc117.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_125952_1119277021.1421843639180" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:34:01 -0000 ------=_Part_125952_1119277021.1421843639180 Content-Type: multipart/Alternative; boundary="----=_Part_125953_1879627874.1421843639180" ------=_Part_125953_1879627874.1421843639180 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCldlZG5lc2RheSwgSmFudWFyeSAyMSwgMjAx NQo0OjAwIHBtICB8ICBFdXJvcGUgVGltZSAoQmVybGluLCBHTVQrMDE6MDApICB8ICAyIGhyCgoK Sk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElE PW0xYzRjMWM1MDkxZThkN2U2NjdmYzc4M2UwZTZjZjg3ZQpNZWV0aW5nIG51bWJlcjogNjQ4IDQ4 MSA3MzUKTWVldGluZyBwYXNzd29yZDogdXVXYWk0RUwKCg0KSk9JTiBCWSBQSE9ORQ0KMS04Nzct NjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1MC00Nzkt MzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2NDggNDgx IDczNQoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJleC5j b20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcgdG8g eW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTYy MDgyNGM1ZWY5OTQ5OGU2ZjhiNTQ0ODFhZDFhNTQwDQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0aW5n PyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jCgoK SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLgo= ------=_Part_125953_1879627874.1421843639180 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+V2Vk bmVzZGF5LCBKYW51YXJ5IDIxLCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD40OjAwIHBtJm5ic3A7Jm5ic3A7 fCZuYnNwOyZuYnNwO0V1cm9wZSBUaW1lIChCZXJsaW4sIEdNVCswMTowMCkmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7MiBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxl PgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0 eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFjNGMxYzUwOTFlOGQ3ZTY2N2Zj NzgzZTBlNmNmODdlIgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQt c2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9pbiBXZWJFeCBtZWV0aW5n PC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFi bGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQi PgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRp bmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlcjoKCQkJCQkJCQk8L3RkPgoJ CQkJCQkJCTx0ZD42NDggNDgxIDczNQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJ PHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVldGluZyBwYXNz d29yZDo8L3RkPgoJCQkJCQkJCTx0ZD51dVdhaTRFTDwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8 L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0 eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQg c3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIg c3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtDYWxsLWlu IHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46 MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3MgY29k ZTombmJzcDs2NDggNDgxIDczNTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48 YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk ZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMwMEFG Rjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGFibGU+ CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxlPSJm b250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bTYyMDgyNGM1ZWY5OTQ5OGU2ZjhiNTQ0ODFhZDFhNTQwIiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFkZCB0aGlzIG1lZXRp bmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9udC1z aXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAgIENh bid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2Zv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAgICAg ICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0YWJs ZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBweCI+ Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJCQkJ CQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJCUlN UE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93 cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8g YmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIu IEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1 Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBk aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vz c2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwvdHI+ CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_125953_1879627874.1421843639180-- ------=_Part_125952_1119277021.1421843639180 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDEyMVQxNjAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUwMTIxVDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxClVJRDpXRUJFWC1NRUVUSU5HIENFTlRF Ui02LjA0NTY2ODAtMzE5NjAxODUyLVNVPWlldGYKRFRTVEFNUDoyMDE1MDEyMVQxNTAwMDBaCkRF U0NSSVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTFjNGMxYzUwOTFlOGQ3ZTY2N2ZjNzgzZTBlNmNmODdlXG5NZWV0 aW5nIG51bWJlcjogNjQ4IDQ4MSA3MzVcbk1lZXRpbmcgcGFzc3dvcmQ6IHV1V2FpNEVMXG5cblxu Sk9JTiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChV Uy9DYW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KVxuQWNjZXNzIGNvZGU6IDY0OCA0ODEgNzM1XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0 aW9uczogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk ZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vz c2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlv dSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5z IHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztG TVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4g PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xYzRjMWM1MDkxZThkN2U2NjdmYzc4M2UwZTZjZjg3 ZSI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4 IG1lZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9G T05UPgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPjY0OCA0ODEgNzM1PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8 L3RhYmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0i MiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+dXVXYWk0RUw8L0ZPTlQ+PC90ZD48L3Ry PjwvdGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4m bmJzcDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIz IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7 IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+ MS04NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVT L0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ4IDQ4MSA3MzU8L0ZP TlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVf cmVzdHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFy aWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJS PjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVm PSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0i IzAwQUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8 QlI+Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUK Q0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRF U0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_125952_1119277021.1421843639180-- From nobody Wed Jan 21 04:38:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C731A1A31 for ; Wed, 21 Jan 2015 04:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqQIQmvEQKRK for ; Wed, 21 Jan 2015 04:38:10 -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 778B21A1A32 for ; Wed, 21 Jan 2015 04:38:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 43BCF787; Wed, 21 Jan 2015 13:38:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5SUqmsvfA_M0; Wed, 21 Jan 2015 13:37:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Jan 2015 13:38:08 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 539C520035; Wed, 21 Jan 2015 13:38:08 +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 MNR8pdHAKyxU; Wed, 21 Jan 2015 13:38:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CA5120034; Wed, 21 Jan 2015 13:38:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7375A30E0603; Wed, 21 Jan 2015 13:38:04 +0100 (CET) Date: Wed, 21 Jan 2015 13:38:04 +0100 From: Juergen Schoenwaelder To: netmod-chairs@tools.ietf.org Message-ID: <20150121123803.GA32782@elstar.local> Mail-Followup-To: netmod-chairs@tools.ietf.org, netmod@ietf.org References: <1421230948.125954.1421843639181.JavaMail.nobody@jva2tc117.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1421230948.125954.1421843639181.JavaMail.nobody@jva2tc117.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 12:38:12 -0000 Hi, the etherpad we are going to use is this one: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-01-21?useMonospaceFont=true /js On Wed, Jan 21, 2015 at 12:33:59PM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Wednesday, January 21, 2015 > 4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hr > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m1c4c1c5091e8d7e667fc783e0e6cf87e > Meeting number: 648 481 735 > Meeting password: uuWai4EL > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 648 481 735 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=m620824c5ef99498e6f8b54481ad1a540 > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jan 21 05:28:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10881A1AAE for ; Wed, 21 Jan 2015 05:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T666briBJxEw for ; Wed, 21 Jan 2015 05:28:21 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E284D1A1AB1 for ; Wed, 21 Jan 2015 05:28:20 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 20E661CC0604; Wed, 21 Jan 2015 14:28:20 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20150121.132433.1505626678838099831.mbj@tail-f.com> References: <20150121.132433.1505626678838099831.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 21 Jan 2015 14:28:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Y18: fix "when" expression context problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 13:28:26 -0000 Martin Bjorklund writes: > Hi, > > I had an action point to clarify the evaluation order of when > expressions, in Y18. > > I have updated Y18 with this proposal, in 7.19.5: > > OLD: > > The result of the XPath expression is converted to a boolean value > using the standard XPath rules. > > NEW: > > The result of the XPath expression is converted to a boolean value > using the standard XPath rules. > > If the XPath expression references any node that also has associated > "when" statements, these "when" expressions MUST be evaluated first. > There MUST NOT be any circular dependencies in these "when" > expressions. I think this sufficiently specifies the order of evaluations. I am now looking at the last bullet in sec. 7.9.15. The old (6020) text worked for the case when the node instance was present in the data tree, while the new text proposed in Y18 seems to cover the situation when the context node is missing. Maybe these two should be combined? NEW: o If the "when" statement is a child of any other data definition statement, the context node is the node in the accessible tree for which the "when" statement is defined. If no such node exists, it is tentatively created with no value and no children. Hmm, but what is the context node when *multiple* instances exist? This could happen if the when statement is on a list or leaf-list node. Lada > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 21 06:41:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DD81A001C for ; Wed, 21 Jan 2015 06:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-gXfdmR0HgJ for ; Wed, 21 Jan 2015 06:41:13 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id A768F1A1ABB for ; Wed, 21 Jan 2015 06:41:13 -0800 (PST) Received: from [192.168.1.136] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 489452CC5D51; Wed, 21 Jan 2015 09:41:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Thomas D. Nadeau" In-Reply-To: <20150121073002.GA31780@elstar.local> Date: Wed, 21 Jan 2015 09:41:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54B14720-D23C-4FC8-961A-6C1172DFCFBD@lucidvision.com> References: <5DA5E354-761B-4498-9E66-C6821CA1AB08@lucidvision.com> <20150121073002.GA31780@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1993) Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Virtual Interim Jan. 21 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 14:41:14 -0000 That is my understanding too. --Tom > On Jan 21, 2015:2:30 AM, at 2:30 AM, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 20, 2015 at 06:02:04PM -0500, Thomas D. Nadeau wrote: >>=20 >> For Yang 1.1. or modeling? If it is for the latter, it is not = happening. I need to go reboot the schedule/webex/etc... >>=20 >=20 > Tom, >=20 > I do not recall that you scheduled any data modeling meetings. This > is the regular YANG 1.1 meeting. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From nobody Wed Jan 21 07:05:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137B11A1ACE for ; Wed, 21 Jan 2015 07:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2xuMuOfQgHr for ; Wed, 21 Jan 2015 07:05:06 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76411A1ADA for ; Wed, 21 Jan 2015 07:05:05 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id s18so7426014lam.3 for ; Wed, 21 Jan 2015 07:05:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ShirdSn6WItwDcvLQ1yLpbf8wUI/1qsBvtCc40gn7Dk=; b=ernPntUZvCY0WGhTf7mZAZzv6Bf/WM0GyYWS5igq1lErlwxHW8J9uCJzTLrysJzOZH 1wEDVddsrpEh66ncV8lLWCY0q3bmAYxClVjfp+MmpcoKaq8EzbbABqT/KQ3orYLDmp0U 5cjU2qdVNXjJaGnEBUgsAWYq1qeYislQOS5NcZzyVMMFYpDznG9EkZFEiRloDKt6ruc+ o+pcLCRmFLvzV+Hj5HYEBXwxxq8xDqXmz2tEMLi92lPU+JMgtx7bgua6caKiMamHQKtA cRd+X+7EgLP/umiEv/mxLpUaR3PlXHfZ0EuQ/6UtrZFNF7kqr0+UE6pCvcBpENIpQ0qL WN2g== X-Gm-Message-State: ALoCoQleRbLRsr80pRzOuzs1KJK9ST7VRMLG4A6b0Rfc81bvKV9+JO1MAvH6czYqaBr5ZAbPptU0 MIME-Version: 1.0 X-Received: by 10.112.170.36 with SMTP id aj4mr44388457lbc.3.1421852703889; Wed, 21 Jan 2015 07:05:03 -0800 (PST) Received: by 10.112.160.41 with HTTP; Wed, 21 Jan 2015 07:05:03 -0800 (PST) In-Reply-To: <20150121102144.GE32055@elstar.local> References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> Date: Wed, 21 Jan 2015 07:05:03 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:05:07 -0000 On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >> Hi, >> >> Juergen Schoenwaelder wrote: >> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. >> >> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >> 'root) correctly, the difference between it and Y34-02 (add 'anydata') >> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as >> 'anydata' with the constraint that it only can hande top-level nodes. >> >> As an example of why this is not sufficient, YANG PATCH uses anyxml >> with non-top-level nodes. It would not be possible to use 'root' in >> this case. 'anydata' would be a better match. >> > > Andy, > > can you please respond to this since you created Y34-04? I now hear > two people in favour of Y34-02 and we had this back in July 2014: > > 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out > a concrete proposal. > > So is the main delta of Y34-04 compared to Y34-02 (i) the additional > text (the three list items) or (ii) additional restrictions of "root" > to top-level nodes. (The Y34-04 referes to ncx:root which is not known > to everybody.) > There are corner cases like YANG Patch edit value that need to be anyxml. > Would adoption of Y34-02 with the additional text (the three list > items) of Y34-04 be a workable solution? > yes > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jan 21 10:07:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595AC1A1B4E for ; Wed, 21 Jan 2015 10:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO4u9g0Bc7Ek for ; Wed, 21 Jan 2015 10:07:38 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA711A1B49 for ; Wed, 21 Jan 2015 10:07:38 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id id10so2991245vcb.12 for ; Wed, 21 Jan 2015 10:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uwl7yuTKLqe7PtnW8rPoVSpO7COZuyM9Mdt824DARZ8=; b=Vq29kCnuvj/69Ulv4IYZzinjev2iDDVFw7yvrP8nYZEWtAqEH3PPaTniZQKlOJ40Sk 1uRhes0swpv/fFxCRYR0t2fvyU0bDTnX+2bLz+lyidJaQdyc96MLKmx3Fq4Lfza9jnhy oylbzZFPFgb3wmplIR2aUQ/sYkQaNeKx4PtBiJX7s2J4dKOHpYw5FWbNz29AR1oykdti KoFYoWyFbS3KB1ESjOYW/tkIXUwgos3nfBVd6YeWOqSmG11JZv9tM40KD7oNROgJgPFD hihjkQ5cCM3K98e9v46yU+1X00gj6lLqfXAjUUn2/LcpNUHdesh/n0fmXCawO7IzJHLa vNOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=uwl7yuTKLqe7PtnW8rPoVSpO7COZuyM9Mdt824DARZ8=; b=MmDa7TNB76Iwb/6TuKNUSgP5OOOPA/aMdbEMpOlDmWwCAADe+Oh6HMoYCJqJnix9/5 2o4wm/JxSeLlQS3z2HQQr/FcJSwtUFAcCXMw7URU2rvsOgYjPhGvEQfG9VG2/HQj5om9 DJECUvmjWtxv+QebBN92gKyNUyoxXi4HX87gP4teMTg8efqdlhWQfw9Pm57oHh6Q5Tot BiCV/rR82cE3ee7n6fhjjYe6YHDtIV06n73rMKh3gZE35zg7xuD3kZF+DBEoHAv0BgZX uYUsGYSFlq/B4gpS57q7FHVHP5DtKNPxycpMRmjRiqpozwYRgUZpc7RiXEvYqPrX7Qbz W/mA== X-Gm-Message-State: ALoCoQlfRJmO1siL/MhhWTi11JWHRpRj3tKZzJOnau396PW3/aoWZDicujzDyc9tJBXnHbM42CYC MIME-Version: 1.0 X-Received: by 10.52.242.75 with SMTP id wo11mr10137012vdc.82.1421863657050; Wed, 21 Jan 2015 10:07:37 -0800 (PST) Received: by 10.52.166.99 with HTTP; Wed, 21 Jan 2015 10:07:36 -0800 (PST) Date: Thu, 22 Jan 2015 05:07:36 +1100 Message-ID: From: Paul Borman To: netmod@ietf.org Content-Type: multipart/mixed; boundary=001a1134d7ba349ab5050d2d6e06 Archived-At: Subject: [netmod] Questions about namings and prefixes in leafrefs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 18:07:40 -0000 --001a1134d7ba349ab5050d2d6e06 Content-Type: multipart/alternative; boundary=001a1134d7ba349ab0050d2d6e04 --001a1134d7ba349ab0050d2d6e04 Content-Type: text/plain; charset=UTF-8 Hi, I am trying to understand RFC6020 without having had the benefit of being in any of the discussions of the working group. I have found the discussion of path names unclear so I have used pyang to try and understand what is expected. It seems to me that a path in a leafref: - may descend into submodule's containers - may descend into used groupings, no matter where the grouping is defined - may *not* ascend into the parent module - may optionally use the module's prefix for any element in a leafref path, no matter where the element is defined - may optionally use the belongs-to-prefix in elements in paths inside a submodule - may *never* use the prefix for/from an imported module Some questions this raise are: - are these observations correct (and intended)? - is there ever a time where a prefix is required in a leafref path? Attached are the modules and submodules I used that lead to these assumptions and questions. pyang -f tree produces the following errors: base.yang:50: error: other:other-group-container-leaf1 in the path for base-container-badref1 at base.yang:49 is not found base.yang:53: error: prefix "pother" is not defined (reported only once) sub.yang:15: error: base:base-container in the path for sub-badref2 at sub.yang:14 is not found sub.yang:18: error: base:base-container in the path for sub-badref3 at sub.yang:17 is not found I am also trying to understand the prefixes used in XPath representations. I have tried using --tree-prefix but that does not appear to accept any prefixes. Thanks for any guidance, -Paul // Base test yang module. module base { namespace "urn:mod"; prefix "base"; include sub; import other { prefix bother; } grouping base-group { leaf base-group-leaf { type string; } } // test uses and leaf ref container base-container { uses base-group; uses bother:other-group; uses base:sub-group; leaf base-container-leaf { type string; } leaf base-container-ref1 { type leafref { path ../base-container-leaf; } } leaf base-container-ref2 { type leafref { path ../base-group-leaf; } } leaf base-container-ref3 { type leafref { path ../other-group-leaf; } } leaf base-container-ref4 { type leafref { path ../sub-group-container/sub-group-leaf; } } leaf base-container-ref5 { type leafref { path ../../base:sub-container/sub-container-leaf; } } leaf base-container-ref6 { type leafref { path ../../base:sub-container/base:sub-container-leaf; } } leaf base-container-ref7 { type leafref { path ../../sub-container/base:sub-container-leaf; } } leaf base-container-ref8 { type leafref { path ../other-group-container/other-group-container-leaf1; } } leaf base-container-ref9 { type leafref { path ../other-group-container/base:other-group-container-leaf1; } } // These next two ar invalid leaf base-container-badref1 { type leafref { path ../other-group-container/bother:other-group-container-leaf1; } } leaf base-container-badref2 { type leafref { path ../other-group-container/pother:other-group-container-leaf1; } } } } // included by base.yang. submodule sub { belongs-to base { prefix "sbase"; } container sub-container { leaf sub-container-leaf { type string; } container subsub { leaf sub-leafref { type leafref { path ../../sub-container-leaf; } } leaf sub-leafref1 { type leafref { path ../../sbase:sub-container-leaf; } } // the next two both fail trying to ascend into the parent leaf sub-badref2 { type leafref { path ../../../base-container/base-container-leaf; } } leaf sub-badref3 { type leafref { path ../../../sbase:base-container/base-container-leaf; } } } } grouping sub-group { container sub-group-container { leaf sub-group-leaf { type string; } } } } // imported by base.yang. module other { namespace "uri:empty"; prefix "otherp"; container other-container { leaf other-container-leaf1 { type string; } leaf other-container-leaf2 { type string; } } grouping other-group { leaf other-group-leaf { type string; } container other-group-container { leaf other-group-container-leaf1 { type string; } leaf other-group-container-leaf2 { type string; } } } } --001a1134d7ba349ab0050d2d6e04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, I am trying to understand RFC6020 without having had t= he benefit of being in any of the discussions of the working group.=C2=A0 I= have found the discussion of path names unclear so I have used pyang to tr= y and understand what is expected.=C2=A0 It seems to me that a path in a le= afref:
  • may descend into submodule's containers
  • may = descend into used groupings, no matter where the grouping is defined
    • may not=C2=A0ascend into the parent module
  • may optionally = use the module's prefix for any element in a leafref path, no matter wh= ere the element is defined
  • may=C2=A0optionally use the belongs-= to-prefix in elements in paths inside a submodule
  • may never= =C2=A0use the prefix for/from an imported module
Some questio= ns this raise are:
  • are these observations correct (= and intended)?
  • is there ever a time where a prefix is required in a= leafref path?
Attached are the modules and submodules I used= that lead to these assumptions and questions. =C2=A0pyang -f tree produces the following errors:

base.yang:50= : error: other:other-group-container-leaf1 in the path for base-container-b= adref1 at base.yang:49 is not found
base.yang:53: error: prefix "pother" is not defined= (reported only once)
= sub.yang:15: error: base:base-container in the path for sub-badref2 at sub.= yang:14 is not found
s= ub.yang:18: error: base:base-container in the path for sub-badref3 at sub.y= ang:17 is not found

I am also trying = to understand the prefixes used in XPath representations.=C2=A0 I have trie= d using --tree-prefix but that does not appear to accept any prefixes.

Thanks for any guidance,

=C2= =A0 =C2=A0 -Paul

// Base test yang module.
module base {
=C2=A0 namespace "urn:mod";
=C2=A0 prefix "base";
=C2=A0=C2=A0
=C2=A0 include sub;
=C2=A0 import other {
=C2=A0 =C2=A0 prefix bother;
=C2=A0 }

=C2= =A0 grouping base-group {
=C2=A0 =C2=A0 leaf base-group-leaf { type string; }
=C2=A0 }

=C2=A0 // test uses and leaf ref
=C2=A0 container base-container {
=C2=A0 =C2=A0 uses base-group;
= =C2=A0 =C2=A0 uses bother:other-group;<= /font>
=C2=A0 =C2=A0 uses bas= e:sub-group;
=C2=A0 = =C2=A0 leaf base-container-leaf { type string; }
=C2=A0 =C2=A0 leaf base-container-ref1 {<= /div>
=C2=A0 =C2=A0 =C2=A0 type lea= fref { path ../base-container-leaf; }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 leaf base-container-ref2 {
=C2=A0 =C2=A0 =C2=A0 type leafref { path ../ba= se-group-leaf; }
=C2= =A0 =C2=A0 }
=C2=A0 = =C2=A0 leaf base-container-ref3 {
=C2=A0 =C2=A0 =C2=A0 type leafref { path ../other-group-leaf; }=
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 leaf base-con= tainer-ref4 {
=C2=A0 = =C2=A0 =C2=A0 type leafref { path ../sub-group-container/sub-group-leaf; }<= /font>
=C2=A0 =C2=A0 }=
=C2=A0 =C2=A0 leaf base-cont= ainer-ref5 {
=C2=A0 = =C2=A0 =C2=A0 type leafref { path ../../base:sub-container/sub-container-le= af; }
=C2=A0 =C2=A0 }<= /font>
=C2=A0 =C2=A0 leaf bas= e-container-ref6 {
=C2= =A0 =C2=A0 =C2=A0 type leafref { path ../../base:sub-container/base:sub-con= tainer-leaf; }
=C2=A0 = =C2=A0 }
=C2=A0 =C2=A0= leaf base-container-ref7 {
=C2=A0 =C2=A0 =C2=A0 type leafref { path ../../sub-container/base:sub= -container-leaf; }
=C2= =A0 =C2=A0 }
=C2=A0 = =C2=A0 leaf base-container-ref8 {
=C2=A0 =C2=A0 =C2=A0 type leafref { path ../other-group-contain= er/other-group-container-leaf1; }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 leaf base-container-ref9 {
=C2=A0 =C2=A0 =C2=A0 type leafref { path ../other= -group-container/base:other-group-container-leaf1; }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 // These next two ar invalid=
=C2=A0 =C2=A0 leaf base-cont= ainer-badref1 {
=C2=A0= =C2=A0 =C2=A0 type leafref { path ../other-group-container/bother:other-gr= oup-container-leaf1; }
=C2=A0 =C2=A0 }
=C2= =A0 =C2=A0 leaf base-container-badref2 {
=C2=A0 =C2=A0 =C2=A0 type leafref { path ../other-group-= container/pother:other-group-container-leaf1; }
=C2=A0 =C2=A0 }
=C2=A0 }
}

// included by base.yang.
submodule sub {
=C2=A0 belongs-to base { prefix = "sbase"; }
= =C2=A0 container sub-container {
=C2=A0 =C2=A0 leaf sub-container-leaf { type string; }
=C2=A0 =C2=A0 container subsub = {
=C2=A0 =C2=A0 =C2=A0= leaf sub-leafref {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref { path ../../sub-container-leaf; }=
=C2=A0 =C2=A0 =C2=A0 = }
=C2=A0 =C2=A0 =C2=A0= leaf sub-leafref1 {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref { path ../../sbase:sub-container-l= eaf; }
=C2=A0 =C2=A0 = =C2=A0 }
=C2=A0 =C2=A0= =C2=A0 // the next two both fail trying to ascend into the parent
=C2=A0 =C2=A0 =C2=A0 leaf sub-= badref2 {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 type leafref { path ../../../base-container/base-containe= r-leaf; }
=C2=A0 =C2= =A0 =C2=A0 }
=C2=A0 = =C2=A0 =C2=A0 leaf sub-badref3 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref { path ../../../sbase:b= ase-container/base-container-leaf; }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
=C2= =A0 grouping sub-group {
=C2=A0 =C2=A0 container sub-group-container {
=C2=A0 =C2=A0 =C2=A0 leaf sub-group-leaf { type = string; }
=C2=A0 =C2= =A0 }
=C2=A0 }<= /div>
}=C2=A0

// imported by base.yang.
module other {
=C2=A0 namespace "uri:empty";
=C2=A0 prefix "otherp";
=C2=A0 container other-container = {
=C2=A0 =C2=A0 leaf o= ther-container-leaf1 { type string; }
=C2=A0 =C2=A0 leaf other-container-leaf2 { type string; }
=C2=A0 }
=C2=A0 grouping other-group {=
=C2=A0 =C2=A0 leaf other-gro= up-leaf { type string; }
=C2=A0 =C2=A0 container =C2=A0other-group-container {
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 leaf other-group-co= ntainer-leaf1 { type string; }
=C2=A0 =C2=A0 =C2=A0 leaf other-group-container-leaf2 { type strin= g; }
=C2=A0 =C2=A0 }
=C2=A0 }
}=C2=A0

<= /div>
--001a1134d7ba349ab0050d2d6e04-- --001a1134d7ba349ab5050d2d6e06 Content-Type: application/octet-stream; name="base.yang" Content-Disposition: attachment; filename="base.yang" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i570i9uz0 Ly8gQmFzZSB0ZXN0IHlhbmcgbW9kdWxlLgptb2R1bGUgYmFzZSB7CiAgbmFtZXNwYWNlICJ1cm46 bW9kIjsKICBwcmVmaXggImJhc2UiOwogIAogIGluY2x1ZGUgc3ViOwogIGltcG9ydCBvdGhlciB7 CiAgICBwcmVmaXggYm90aGVyOwogIH0KCiAgZ3JvdXBpbmcgYmFzZS1ncm91cCB7CiAgICBsZWFm IGJhc2UtZ3JvdXAtbGVhZiB7IHR5cGUgc3RyaW5nOyB9CiAgfQoKICAvLyB0ZXN0IHVzZXMgYW5k IGxlYWYgcmVmCiAgY29udGFpbmVyIGJhc2UtY29udGFpbmVyIHsKICAgIHVzZXMgYmFzZS1ncm91 cDsKICAgIHVzZXMgYm90aGVyOm90aGVyLWdyb3VwOwogICAgdXNlcyBiYXNlOnN1Yi1ncm91cDsK ICAgIGxlYWYgYmFzZS1jb250YWluZXItbGVhZiB7IHR5cGUgc3RyaW5nOyB9CiAgICBsZWFmIGJh c2UtY29udGFpbmVyLXJlZjEgewogICAgICB0eXBlIGxlYWZyZWYgeyBwYXRoIC4uL2Jhc2UtY29u dGFpbmVyLWxlYWY7IH0KICAgIH0KICAgIGxlYWYgYmFzZS1jb250YWluZXItcmVmMiB7CiAgICAg IHR5cGUgbGVhZnJlZiB7IHBhdGggLi4vYmFzZS1ncm91cC1sZWFmOyB9CiAgICB9CiAgICBsZWFm IGJhc2UtY29udGFpbmVyLXJlZjMgewogICAgICB0eXBlIGxlYWZyZWYgeyBwYXRoIC4uL290aGVy LWdyb3VwLWxlYWY7IH0KICAgIH0KICAgIGxlYWYgYmFzZS1jb250YWluZXItcmVmNCB7CiAgICAg IHR5cGUgbGVhZnJlZiB7IHBhdGggLi4vc3ViLWdyb3VwLWNvbnRhaW5lci9zdWItZ3JvdXAtbGVh ZjsgfQogICAgfQogICAgbGVhZiBiYXNlLWNvbnRhaW5lci1yZWY1IHsKICAgICAgdHlwZSBsZWFm cmVmIHsgcGF0aCAuLi8uLi9iYXNlOnN1Yi1jb250YWluZXIvc3ViLWNvbnRhaW5lci1sZWFmOyB9 CiAgICB9CiAgICBsZWFmIGJhc2UtY29udGFpbmVyLXJlZjYgewogICAgICB0eXBlIGxlYWZyZWYg eyBwYXRoIC4uLy4uL2Jhc2U6c3ViLWNvbnRhaW5lci9iYXNlOnN1Yi1jb250YWluZXItbGVhZjsg fQogICAgfQogICAgbGVhZiBiYXNlLWNvbnRhaW5lci1yZWY3IHsKICAgICAgdHlwZSBsZWFmcmVm IHsgcGF0aCAuLi8uLi9zdWItY29udGFpbmVyL2Jhc2U6c3ViLWNvbnRhaW5lci1sZWFmOyB9CiAg ICB9CiAgICBsZWFmIGJhc2UtY29udGFpbmVyLXJlZjggewogICAgICB0eXBlIGxlYWZyZWYgeyBw YXRoIC4uL290aGVyLWdyb3VwLWNvbnRhaW5lci9vdGhlci1ncm91cC1jb250YWluZXItbGVhZjE7 IH0KICAgIH0KICAgIGxlYWYgYmFzZS1jb250YWluZXItcmVmOSB7CiAgICAgIHR5cGUgbGVhZnJl ZiB7IHBhdGggLi4vb3RoZXItZ3JvdXAtY29udGFpbmVyL2Jhc2U6b3RoZXItZ3JvdXAtY29udGFp bmVyLWxlYWYxOyB9CiAgICB9CiAgICAvLyBUaGVzZSBuZXh0IHR3byBhciBpbnZhbGlkCiAgICBs ZWFmIGJhc2UtY29udGFpbmVyLWJhZHJlZjEgewogICAgICB0eXBlIGxlYWZyZWYgeyBwYXRoIC4u L290aGVyLWdyb3VwLWNvbnRhaW5lci9ib3RoZXI6b3RoZXItZ3JvdXAtY29udGFpbmVyLWxlYWYx OyB9CiAgICB9CiAgICBsZWFmIGJhc2UtY29udGFpbmVyLWJhZHJlZjIgewogICAgICB0eXBlIGxl YWZyZWYgeyBwYXRoIC4uL290aGVyLWdyb3VwLWNvbnRhaW5lci9wb3RoZXI6b3RoZXItZ3JvdXAt Y29udGFpbmVyLWxlYWYxOyB9CiAgICB9CiAgfQp9Cg== --001a1134d7ba349ab5050d2d6e06 Content-Type: application/octet-stream; name="other.yang" Content-Disposition: attachment; filename="other.yang" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i570i9wy1 Ly8gaW1wb3J0ZWQgYnkgYmFzZS55YW5nLgptb2R1bGUgb3RoZXIgewogIG5hbWVzcGFjZSAidXJp OmVtcHR5IjsKICBwcmVmaXggIm90aGVycCI7CiAgY29udGFpbmVyIG90aGVyLWNvbnRhaW5lciB7 CiAgICBsZWFmIG90aGVyLWNvbnRhaW5lci1sZWFmMSB7IHR5cGUgc3RyaW5nOyB9CiAgICBsZWFm IG90aGVyLWNvbnRhaW5lci1sZWFmMiB7IHR5cGUgc3RyaW5nOyB9CiAgfQogIGdyb3VwaW5nIG90 aGVyLWdyb3VwIHsKICAgIGxlYWYgb3RoZXItZ3JvdXAtbGVhZiB7IHR5cGUgc3RyaW5nOyB9CiAg ICBjb250YWluZXIgIG90aGVyLWdyb3VwLWNvbnRhaW5lciB7CiAgICAgIGxlYWYgb3RoZXItZ3Jv dXAtY29udGFpbmVyLWxlYWYxIHsgdHlwZSBzdHJpbmc7IH0KICAgICAgbGVhZiBvdGhlci1ncm91 cC1jb250YWluZXItbGVhZjIgeyB0eXBlIHN0cmluZzsgfQogICAgfQogIH0KfSAK --001a1134d7ba349ab5050d2d6e06 Content-Type: application/octet-stream; name="sub.yang" Content-Disposition: attachment; filename="sub.yang" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i570i9xc2 Ly8gaW5jbHVkZWQgYnkgYmFzZS55YW5nLgpzdWJtb2R1bGUgc3ViIHsKICBiZWxvbmdzLXRvIGJh c2UgeyBwcmVmaXggInNiYXNlIjsgfQogIGNvbnRhaW5lciBzdWItY29udGFpbmVyIHsKICAgIGxl YWYgc3ViLWNvbnRhaW5lci1sZWFmIHsgdHlwZSBzdHJpbmc7IH0KICAgIGNvbnRhaW5lciBzdWJz dWIgewogICAgICBsZWFmIHN1Yi1sZWFmcmVmIHsKICAgICAgICB0eXBlIGxlYWZyZWYgeyBwYXRo IC4uLy4uL3N1Yi1jb250YWluZXItbGVhZjsgfQogICAgICB9CiAgICAgIGxlYWYgc3ViLWxlYWZy ZWYxIHsKICAgICAgICB0eXBlIGxlYWZyZWYgeyBwYXRoIC4uLy4uL3NiYXNlOnN1Yi1jb250YWlu ZXItbGVhZjsgfQogICAgICB9CiAgICAgIC8vIHRoZSBuZXh0IHR3byBib3RoIGZhaWwgdHJ5aW5n IHRvIGFzY2VuZCBpbnRvIHRoZSBwYXJlbnQKICAgICAgbGVhZiBzdWItYmFkcmVmMiB7CiAgICAg ICAgdHlwZSBsZWFmcmVmIHsgcGF0aCAuLi8uLi8uLi9iYXNlLWNvbnRhaW5lci9iYXNlLWNvbnRh aW5lci1sZWFmOyB9CiAgICAgIH0KICAgICAgbGVhZiBzdWItYmFkcmVmMyB7CiAgICAgICAgdHlw ZSBsZWFmcmVmIHsgcGF0aCAuLi8uLi8uLi9zYmFzZTpiYXNlLWNvbnRhaW5lci9iYXNlLWNvbnRh aW5lci1sZWFmOyB9CiAgICAgIH0KICAgIH0KICB9CiAgZ3JvdXBpbmcgc3ViLWdyb3VwIHsKICAg IGNvbnRhaW5lciBzdWItZ3JvdXAtY29udGFpbmVyIHsKICAgICAgbGVhZiBzdWItZ3JvdXAtbGVh ZiB7IHR5cGUgc3RyaW5nOyB9CiAgICB9CiAgfQp9IAo= --001a1134d7ba349ab5050d2d6e06-- From nobody Wed Jan 21 12:53:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9091A87CC for ; Wed, 21 Jan 2015 12:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PvDgTw8Mp92 for ; Wed, 21 Jan 2015 12:53:16 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBE51A87D2 for ; Wed, 21 Jan 2015 12:53:16 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id q1so27285212lam.2 for ; Wed, 21 Jan 2015 12:53:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=CP913zAWoimwGXoJDeRLSKlnnO3uMwmMcD6vEEvJjjg=; b=U8zarWSoDMC+ERE9WTGY3ALH2jwsCbWsyaYc+w4t1eA8htZYct7IVcymyVBlBKwSZP W1whCG3yeb48ab31bb7rfqFr/a2Z1kF80cBXbNXtVo9w7ECGueohEtoOuQBeMYwxcBx0 RKPgTySFIxCHEni1AO9SQAZDX+lqFfDf8QclsWQXienZBOJ2gf2jCX8d4MX3gtoHeP4l bpEds5wCr+eNFJa+UACTyjyYIazYztZFswzxxpmvxJtz/DM1aL4mhe454WXzlWAG38kp n1W8OSo0uSxTs73a8jHEnev9mgYj+cDVF3rILO5FXoVn1b6ku1+SfS2q4tF00ocNphZH IdvA== X-Gm-Message-State: ALoCoQk84Qvpm3xBcGeqbvlHalfWLhyNS1NtYAtElrw4Vx86ochoqTevRdfBQW37dkg2rMd4GgOb MIME-Version: 1.0 X-Received: by 10.112.8.69 with SMTP id p5mr46165247lba.97.1421873594773; Wed, 21 Jan 2015 12:53:14 -0800 (PST) Received: by 10.112.160.41 with HTTP; Wed, 21 Jan 2015 12:53:14 -0800 (PST) Date: Wed, 21 Jan 2015 12:53:14 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [netmod] ietf-snmp question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 20:53:18 -0000 Hi, I am working on a YANG parser bug related to "augment when". I am running yangdump-pro and getting this warning for ietf-snmp.yang Warning: no child nodes found in XPath expr 'snmp:v1 or snmp:v2c' ietf-snmp-community.yang:220.10: warning(1032): no child node available augment /snmp:snmp/snmp:target { when "snmp:v1 or snmp:v2c"; leaf mms { ... } } I can't find child nodes of /snmp/target named "v1" or "v2c". I find these nodes: "v1" leaf /snmp/engine/version/v1 case /snmp/target-params/params/v1 container /snmp/target-params/params/v1/v1 "v2c" leaf /snmp/engine/version/v2c case /snmp/target-params/params/v2c container /snmp/target-params/params/v2c/v2c Maybe it's because searching all the submodules is confusing, but I cannot find the child nodes of 'target' that would make the when-stmt true. Is this a bug in the RFC or am I missing something? Andy From nobody Wed Jan 21 13:25:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74C21A888E for ; Wed, 21 Jan 2015 13:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8OWFPyFXvpM for ; Wed, 21 Jan 2015 13:25:29 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44D1A887E for ; Wed, 21 Jan 2015 13:25:29 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 31EF91280996; Wed, 21 Jan 2015 22:25:28 +0100 (CET) Date: Wed, 21 Jan 2015 22:26:56 +0100 (CET) Message-Id: <20150121.222656.978148438571440598.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ietf-snmp question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:25:30 -0000 Hi, Andy Bierman wrote: > Hi, > > I am working on a YANG parser bug related to "augment when". > I am running yangdump-pro and getting this warning for ietf-snmp.yang > > Warning: no child nodes found in XPath expr 'snmp:v1 or snmp:v2c' > ietf-snmp-community.yang:220.10: warning(1032): no child node available [...] > Is this a bug in the RFC or am I missing something? It is a bug :( It used to be correct, but in draft -05 (I think) the data model was changed. Unfortunately, pyang doesn't have a XPath parser so it doesn't detect this. (I am working on a new compiler that *should* have detected this, but it turns out it had a bug which I just fixed, and now it also detects this error.) /martin From nobody Thu Jan 22 01:06:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB681A01F6 for ; Thu, 22 Jan 2015 01:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alGA-8Um7SoF for ; Thu, 22 Jan 2015 01:06:12 -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 76B0D1A01F2 for ; Thu, 22 Jan 2015 01:06:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 45A2E10CD; Thu, 22 Jan 2015 10:06:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rIaDvSbO_krZ; Thu, 22 Jan 2015 10:05:51 +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, 22 Jan 2015 10:06:10 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94BA920036; Thu, 22 Jan 2015 10:06:10 +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 u7_KN8dWjuaT; Thu, 22 Jan 2015 10:06:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6112420037; Thu, 22 Jan 2015 10:06:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 34B0B30E27AB; Thu, 22 Jan 2015 10:06:08 +0100 (CET) Date: Thu, 22 Jan 2015 10:06:07 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150122090607.GI34402@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20150121.222656.978148438571440598.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150121.222656.978148438571440598.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ietf-snmp question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 09:06:14 -0000 On Wed, Jan 21, 2015 at 10:26:56PM +0100, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > > Hi, > > > > I am working on a YANG parser bug related to "augment when". > > I am running yangdump-pro and getting this warning for ietf-snmp.yang > > > > Warning: no child nodes found in XPath expr 'snmp:v1 or snmp:v2c' > > ietf-snmp-community.yang:220.10: warning(1032): no child node available > > [...] > > > Is this a bug in the RFC or am I missing something? > > It is a bug :( It used to be correct, but in draft -05 (I think) the > data model was changed. Unfortunately, pyang doesn't have a XPath > parser so it doesn't detect this. (I am working on a new compiler > that *should* have detected this, but it turns out it had a bug which > I just fixed, and now it also detects this error.) > Martin, can you file an errata? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 22 05:07:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324D31ACC8D for ; Thu, 22 Jan 2015 05:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOOdWsz3r4Ez for ; Thu, 22 Jan 2015 05:07:08 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B90641ACC8F for ; Thu, 22 Jan 2015 05:07:07 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2FD161CC0604; Thu, 22 Jan 2015 14:07:09 +0100 (CET) From: Ladislav Lhotka To: Paul Borman , netmod@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 22 Jan 2015 14:07:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Questions about namings and prefixes in leafrefs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 13:07:10 -0000 Hi Paul, Paul Borman writes: > Hi, I am trying to understand RFC6020 without having had the benefit of > being in any of the discussions of the working group. I have found the > discussion of path names unclear so I have used pyang to try and understand > what is expected. It seems to me that a path in a leafref: > > - may descend into submodule's containers yes > - may descend into used groupings, no matter where the grouping is > defined yes > - may *not* ascend into the parent module Actually, I am not sure about this one. > - may optionally use the module's prefix for any element in a leafref > path, no matter where the element is defined The prefix has to be present if the node is defined in another module. For example, a leafref in "base" pointing to "other-container-leaf1" would have path "/bother:other-container/bother:other-container-leaf1"; > - may optionally use the belongs-to-prefix in elements in paths inside a > submodule yes > - may *never* use the prefix for/from an imported module It must *always* use it. > > Some questions this raise are: > > - are these observations correct (and intended)? > - is there ever a time where a prefix is required in a leafref > path? Yes, see above. I hope submodule rules will be significantly simplified in YANG 1.1, see issue Y49: https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-50 ... > > I am also trying to understand the prefixes used in XPath representations. > I have tried using --tree-prefix but that does not appear to accept any > prefixes. The "tree" plugin has no such option, RTFM. > // These next two ar invalid > leaf base-container-badref1 { > type leafref { path > ../other-group-container/bother:other-group-container-leaf1; } The prefix "bother" is wrong. It is because YANG groupings are "chameleons": nodes defined in a grouping receive the namespace of the module where the grouping is used, not the one in which it is defined. Sec sec. 7.12 in RFC 6020. Lada > } > leaf base-container-badref2 { > type leafref { path > ../other-group-container/pother:other-group-container-leaf1; } > } > } > } > > // included by base.yang. > submodule sub { > belongs-to base { prefix "sbase"; } > container sub-container { > leaf sub-container-leaf { type string; } > container subsub { > leaf sub-leafref { > type leafref { path ../../sub-container-leaf; } > } > leaf sub-leafref1 { > type leafref { path ../../sbase:sub-container-leaf; } > } > // the next two both fail trying to ascend into the parent > leaf sub-badref2 { > type leafref { path ../../../base-container/base-container-leaf; } > } > leaf sub-badref3 { > type leafref { path > ../../../sbase:base-container/base-container-leaf; } > } > } > } > grouping sub-group { > container sub-group-container { > leaf sub-group-leaf { type string; } > } > } > } > > // imported by base.yang. > module other { > namespace "uri:empty"; > prefix "otherp"; > container other-container { > leaf other-container-leaf1 { type string; } > leaf other-container-leaf2 { type string; } > } > grouping other-group { > leaf other-group-leaf { type string; } > container other-group-container { > leaf other-group-container-leaf1 { type string; } > leaf other-group-container-leaf2 { type string; } > } > } > } > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 22 09:43:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D319C1ACE17 for ; Thu, 22 Jan 2015 09:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j59QRGVEl8sH for ; Thu, 22 Jan 2015 09:43:55 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::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 013441ACE13 for ; Thu, 22 Jan 2015 09:43:54 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id hy10so759937vcb.11 for ; Thu, 22 Jan 2015 09:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WP2Ij16+9ScEGAlfCnKFhRRyi06YIEe7AizMmWibzls=; b=lYJqZn1CrfBvQXJviGudv1yqsjJaw3Izm7RrTnFI86KJK9BmOsv2DoR3rpjnMbA9yx dJGx2YzFwG1+3sMC2PCFF3MYXhGnkgJK8ggpJ78cPXapIFOM0Yx+j6t85fx9gd4OaLQU pfjfTVi6ALpnhiQDL9cD2WKQvfbKpyb/R1c40HD87yX8tF2+uBi/qv5+WyKXhRCC05Xz d+uJVVKoK7q7/J24QYemq+l1+4SRfJhQMalTHdOjIKX7fz62nQ+caLalAU1bpnhNIgfY bXiuoJwLzKC3agNHqTII4YgRHS+FvL96kzZ8JwwzOdPxm9y7dEKs8pWKYVBF1iNXhRwW ovLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WP2Ij16+9ScEGAlfCnKFhRRyi06YIEe7AizMmWibzls=; b=aTfpR7llVhKCu/x19jB3X1GU/ZC0jf0IwVy5j7ASWcCCvJSxVtpP+y1/K0HaBL78tb td7GF/O1lYeu/Gk7Ntz1/MlFCcpLTYouRew61VjhsFPllQ60c6IkbIjcfxK1xHncSN03 o+YlkorE9KdKPJArT5HChELADsSt6Jn6HIZvzyXJA90exFjxu89mNYJgjcABFUyNIDtR 6LWHWrOOH2mqq2aEaDunY290aiRadaucVXTe0Dse7Gg1Fflp2f5uPUpLN+jCVCBIaMUx /MC3H5OeVa6Tp/lYAC2pSYwSRSBzw4RGqWBUQf0lfPUx8icOCstNaK8SLpl9QQ6h1q6V xyvg== X-Gm-Message-State: ALoCoQkuERvqeznc0mtJrjTQTAZR5pGyNHlqSb3XRwJgGSkQ2+OL2BmhxssIW3TTwOtapF+nPp62 MIME-Version: 1.0 X-Received: by 10.52.29.172 with SMTP id l12mr1053948vdh.33.1421948633978; Thu, 22 Jan 2015 09:43:53 -0800 (PST) Received: by 10.52.246.194 with HTTP; Thu, 22 Jan 2015 09:43:53 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Jan 2015 09:43:53 -0800 Message-ID: From: Paul Borman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf30780cb237b851050d413773 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Questions about namings and prefixes in leafrefs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 17:43:58 -0000 --20cf30780cb237b851050d413773 Content-Type: text/plain; charset=UTF-8 Thanks for the response and clarification, Lada. > I am also trying to understand the prefixes used in XPath representations. > > I have tried using --tree-prefix but that does not appear to accept any > > prefixes. > The "tree" plugin has no such option, RTFM. Yes, clearly I meant --tree-path. Sorry to have confused you. Given the chameleon aspect of groups, I take it that paths to a node in a data tree (not the schema tree) do not have prefixes, and --tree-path takes a path in the data tree (the documentation I read just says "Subtree to print"). I am actually very happy to not have prefixes in the resulting data tree at all. > - may optionally use the module's prefix for any element in a leafref > > path, no matter where the element is defined > The prefix has to be present if the node is defined in another > module. For example, a leafref in "base" pointing to > "other-container-leaf1" would have path "/bother:other-container/bother:other-container-leaf1"; Interesting. So a path in a leafref references the resulting data tree, while the path provided to augment references the schema tree. Re-reading the "uses" description I see where it switches namespaces. Since it appears, via empirical evidence with pyang, that the nodes of an imported tree do not become part of the tree of the importing module. What does it mean to have a leafref reference a node in a tree other than its own? I will note that my example referred to a node within a grouping defined in other but used in base, while your example refers to a node that only exists in other. So, my assertion about paths (they were all relative) and prefix names was actually correct, but does not apply when referencing a node in a different data tree (i.e., not part of the data tree of the base module), which is what you gave an example of. The "switching names spaces" aspect of uses explains why I cannot use the bother prefix in relative paths, or even in paths rooted in base, that include nodes from a grouping in other. The satisfaction of types does seem inconsistent with this, however. I added some typedefs to base.yang and other.yang (base-type and other-type, respectively), and then modified the grouping in other.yang to have: grouping other-group { leaf other-group-leaf { type other-type; } leaf other-base-leaf { type base-type; } leaf other-bad-leaf { type bad-type; } } When the other-group is used in base.yang, only bad-type is flagged as not found (shouldn't other-type also be flagged as not found?), while when other-group is used in other.yang, both base-type and bad-type are flagged as not found (as I would expect). Thanks, -Paul On Thu, Jan 22, 2015 at 5:07 AM, Ladislav Lhotka wrote: > Hi Paul, > > Paul Borman writes: > > > Hi, I am trying to understand RFC6020 without having had the benefit of > > being in any of the discussions of the working group. I have found the > > discussion of path names unclear so I have used pyang to try and > understand > > what is expected. It seems to me that a path in a leafref: > > > > - may descend into submodule's containers > > yes > > > - may descend into used groupings, no matter where the grouping is > > defined > > yes > > > - may *not* ascend into the parent module > > Actually, I am not sure about this one. > > > - may optionally use the module's prefix for any element in a leafref > > path, no matter where the element is defined > > The prefix has to be present if the node is defined in another > module. For example, a leafref in "base" pointing to > "other-container-leaf1" would have > > path "/bother:other-container/bother:other-container-leaf1"; > > > - may optionally use the belongs-to-prefix in elements in paths > inside a > > submodule > > yes > > > - may *never* use the prefix for/from an imported module > > It must *always* use it. > > > > > Some questions this raise are: > > > > - are these observations correct (and intended)? > > - is there ever a time where a prefix is required in a leafref > > path? > > Yes, see above. > > I hope submodule rules will be significantly simplified in YANG 1.1, see > issue Y49: > > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-50 > > ... > > > > > I am also trying to understand the prefixes used in XPath > representations. > > I have tried using --tree-prefix but that does not appear to accept any > > prefixes. > > The "tree" plugin has no such option, RTFM. > > > // These next two ar invalid > > leaf base-container-badref1 { > > type leafref { path > > ../other-group-container/bother:other-group-container-leaf1; } > > The prefix "bother" is wrong. It is because YANG groupings are > "chameleons": nodes defined in a grouping receive the namespace of the > module where the grouping is used, not the one in which it is > defined. Sec sec. 7.12 in RFC 6020. > > Lada > > > } > > leaf base-container-badref2 { > > type leafref { path > > ../other-group-container/pother:other-group-container-leaf1; } > > } > > } > > } > > > > // included by base.yang. > > submodule sub { > > belongs-to base { prefix "sbase"; } > > container sub-container { > > leaf sub-container-leaf { type string; } > > container subsub { > > leaf sub-leafref { > > type leafref { path ../../sub-container-leaf; } > > } > > leaf sub-leafref1 { > > type leafref { path ../../sbase:sub-container-leaf; } > > } > > // the next two both fail trying to ascend into the parent > > leaf sub-badref2 { > > type leafref { path ../../../base-container/base-container-leaf; > } > > } > > leaf sub-badref3 { > > type leafref { path > > ../../../sbase:base-container/base-container-leaf; } > > } > > } > > } > > grouping sub-group { > > container sub-group-container { > > leaf sub-group-leaf { type string; } > > } > > } > > } > > > > // imported by base.yang. > > module other { > > namespace "uri:empty"; > > prefix "otherp"; > > container other-container { > > leaf other-container-leaf1 { type string; } > > leaf other-container-leaf2 { type string; } > > } > > grouping other-group { > > leaf other-group-leaf { type string; } > > container other-group-container { > > leaf other-group-container-leaf1 { type string; } > > leaf other-group-container-leaf2 { type string; } > > } > > } > > } > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --20cf30780cb237b851050d413773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the response and clarification, Lada.

<= /div>
> I am also trying to unders= tand the prefixes used in XPath representations.
> I have tried using --tree-prefix but that does not appear to accept a= ny
> prefixes.=C2=A0

The "tree" plugin has no = such option, RTFM.

Yes, clearly I meant --t= ree-path.=C2=A0 Sorry to have confused you.=C2=A0 Given the chameleon aspec= t of groups, I take it that paths to a node in a data tree (not the schema = tree) do not have prefixes, and --tree-path takes a path in the data tree (= the documentation I read just says "Subtree to print").=C2=A0 I a= m actually very happy to not have prefixes in the resulting data tree at al= l.

>=C2=A0 =C2=A0 - may optionally use the = module's prefix for any element in a leafref
>= =C2=A0 =C2=A0 path, no matter where the element is defined=C2=A0

The prefix has to be = present if the node is defined in another
module. For example, a leafref= in "base" pointing to
"other-container-leaf1" would= have=C2=A0
=C2=A0
=C2=A0 path "/bother:other-container/bother:other-container-leaf1&qu= ot;;

Interesting.=C2=A0 So a path in a leaf= ref references the resulting data tree, while the path provided to augment = references the schema tree.=C2=A0 Re-reading the "uses" descripti= on I see where it switches namespaces.

Since it ap= pears, via empirical evidence with pyang, that the nodes of an imported tre= e do not become part of the tree of the importing module.=C2=A0 What does i= t mean to have a leafref reference a node in a tree other than its own?=C2= =A0 I will note that my example referred to a node within a grouping define= d in other but used in base, while your example refers to a node that only = exists in other.=C2=A0 So, my assertion about paths (they were all relative= ) and prefix names was actually correct, but does not apply when referencin= g a node in a different data tree (i.e., not part of the data tree of the b= ase module), which is what you gave an example of.

The "switching names spaces" aspect of uses explains why I canno= t use the bother prefix in relative paths, or even in paths rooted in base,= that include nodes from a grouping in other.=C2=A0 The satisfaction of typ= es does seem inconsistent with this, however.=C2=A0 I added some typedefs t= o base.yang and other.yang (base-type and other-type, respectively), and th= en modified the grouping in other.yang to have:

<= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
<= div>
=C2=A0 grouping other-group {<= /font>
= =C2=A0 =C2=A0 leaf other-group-leaf { type other-type; }
=
=C2=A0 =C2=A0 leaf= other-base-leaf { type base-type; }
=C2=A0 =C2=A0 leaf other-bad-leaf { ty= pe bad-type; }
=C2=A0 }

=
When the other-group is used in base.yang, only bad-type is flag= ged as not found (shouldn't other-type also be flagged as not found?), = while when other-group is used in other.yang, both base-type and bad-type a= re flagged as not found (as I would expect).

Thank= s,

=C2=A0 =C2=A0 -Paul

On Thu, Jan 22, 2015 at 5:07= AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
= Hi Paul,

Paul Borman <borman@google.com&= gt; writes:

> Hi, I am trying to understand RFC6020 without having had the benefit o= f
> being in any of the discussions of the working group.=C2=A0 I have fou= nd the
> discussion of path names unclear so I have used pyang to try and under= stand
> what is expected.=C2=A0 It seems to me that a path in a leafref:
>
>=C2=A0 =C2=A0 - may descend into submodule's containers

yes

>=C2=A0 =C2=A0 - may descend into used groupings, no matter where the gr= ouping is
>=C2=A0 =C2=A0 defined

yes

>=C2=A0 =C2=A0 - may *not* ascend into the parent module

Actually, I am not sure about this one.

>=C2=A0 =C2=A0 - may optionally use the module's prefix for any elem= ent in a leafref
>=C2=A0 =C2=A0 path, no matter where the element is def= ined

The prefix has to be present if the node is defined in another
module. For example, a leafref in "base" pointing to
"other-container-leaf1" would have

=C2=A0 path "/bother:other-container/bother:other-container-leaf1"= ;;

>=C2=A0 =C2=A0 - may optionally use the belongs-to-prefix in elements in= paths inside a
>=C2=A0 =C2=A0 submodule

yes

>=C2=A0 =C2=A0 - may *never* use the prefix for/from an imported module<= br>
It must *always* use it.

>
> Some questions this raise are:
>
>=C2=A0 =C2=A0 - are these observations correct (and intended)? >=C2=A0 =C2=A0 - is there ever a time where a prefix is required in a le= afref
>=C2=A0 =C2=A0 path?

Yes, see above.

I hope submodule rules will be significantly simplified in YANG 1.1, see issue Y49:

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/i= ssues.html#sec-50

...

>
> I am also trying to understand the prefixes used in XPath representati= ons.
> I have tried using --tree-prefix but that does not appear to accept an= y
> prefixes.

The "tree" plugin has no such option, RTFM.

>=C2=A0 =C2=A0 =C2=A0// These next two ar invalid
>=C2=A0 =C2=A0 =C2=A0leaf base-container-badref1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path
> ../other-group-container/bother:other-group-container-leaf1; }

The prefix "bother" is wrong. It is because YANG groupings= are
"chameleons": nodes defined in a grouping receive the namespace o= f the
module where the grouping is used, not the one in which it is
defined. Sec sec. 7.12 in RFC 6020.

Lada

>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0leaf base-container-badref2 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path
> ../other-group-container/pother:other-group-container-leaf1; }
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> // included by base.yang.
> submodule sub {
>=C2=A0 =C2=A0belongs-to base { prefix "sbase"; }
>=C2=A0 =C2=A0container sub-container {
>=C2=A0 =C2=A0 =C2=A0leaf sub-container-leaf { type string; }
>=C2=A0 =C2=A0 =C2=A0container subsub {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-leafref {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path ../../sub-contain= er-leaf; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-leafref1 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path ../../sbase:sub-c= ontainer-leaf; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0// the next two both fail trying to ascend i= nto the parent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-badref2 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path ../../../base-con= tainer/base-container-leaf; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-badref3 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path
> ../../../sbase:base-container/base-container-leaf; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0grouping sub-group {
>=C2=A0 =C2=A0 =C2=A0container sub-group-container {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-group-leaf { type string; }
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> // imported by base.yang.
> module other {
>=C2=A0 =C2=A0namespace "uri:empty";
>=C2=A0 =C2=A0prefix "otherp";
>=C2=A0 =C2=A0container other-container {
>=C2=A0 =C2=A0 =C2=A0leaf other-container-leaf1 { type string; }
>=C2=A0 =C2=A0 =C2=A0leaf other-container-leaf2 { type string; }
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0grouping other-group {
>=C2=A0 =C2=A0 =C2=A0leaf other-group-leaf { type string; }
>=C2=A0 =C2=A0 =C2=A0container=C2=A0 other-group-container {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf other-group-container-leaf1 { type stri= ng; }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf other-group-container-leaf2 { type stri= ng; }
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--20cf30780cb237b851050d413773-- From nobody Thu Jan 22 10:19:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC30A1ACF1D for ; Thu, 22 Jan 2015 10:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.539 X-Spam-Level: X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnVz7P5-jJJH for ; Thu, 22 Jan 2015 10:18:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B102A1ACF60 for ; Thu, 22 Jan 2015 10:18:40 -0800 (PST) Received: from [172.20.6.143] (unknown [172.20.6.143]) by mail.nic.cz (Postfix) with ESMTPSA id 4A7E513F961; Thu, 22 Jan 2015 19:18:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421950718; bh=dyONsMCmzKz34FL8vG+mjhs0OX3+p42DoPPDt8YeVqs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BWoCvv3Z4T02PeGSWQXLj7b8GdyfOp8rEod5yXv7xoWRFNYHcrgRJ/oALRIh5Cby1 +hPgjnVzs+tVEXCSkfYJnLikfTyWTBSL96BTDMx7L0EUfXcxVWQLCIXCF7AMnWGPTs x/RZ8TjAxPCIH3SThx1VhuAJgm2aPi2WIW50EChg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 22 Jan 2015 19:18:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Borman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Questions about namings and prefixes in leafrefs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 18:18:59 -0000 > On 22 Jan 2015, at 18:43, Paul Borman wrote: >=20 > Thanks for the response and clarification, Lada. >=20 > > I am also trying to understand the prefixes used in XPath = representations. > > I have tried using --tree-prefix but that does not appear to accept = any > > prefixes.=20 >=20 > The "tree" plugin has no such option, RTFM. >=20 > Yes, clearly I meant --tree-path. Sorry to have confused you. Given = the chameleon aspect of groups, I take it that paths to a node in a data = tree (not the schema tree) do not have prefixes, and --tree-path takes a = path in the data tree (the documentation I read just says "Subtree to = print"). I am actually very happy to not have prefixes in the resulting = data tree at all. Sometimes they are needed, even in JSON encoding that tries to suppress = them as much as possible. =20 >=20 > > - may optionally use the module's prefix for any element in a = leafref > > path, no matter where the element is defined=20 >=20 > The prefix has to be present if the node is defined in another > module. For example, a leafref in "base" pointing to > "other-container-leaf1" would have=20 > =20 > path "/bother:other-container/bother:other-container-leaf1"; >=20 > Interesting. So a path in a leafref references the resulting data = tree, while the path provided to augment references the schema tree. = Re-reading the "uses" description I see where it switches That=E2=80=99s right, augments modify the schema tree. > namespaces. >=20 > Since it appears, via empirical evidence with pyang, that the nodes of = an imported tree do not become part of the tree of the importing module. = What does it mean to have a leafref reference a node in a That=E2=80=99s correct, the importing module only gets access to = top-level groupings, typedefs, identities and features. > tree other than its own? I will note that my example referred to a = node within a grouping defined in The information about the set of modules that comprise the data model = has to be supplied by other means. In NETCONF it is the hello message, = and in pyang you can either provide a hello message as an XML document = (with the --hello option), or simply put all modules on the command = line. In your case it could be $ pyang -f tree base.yang other.yang > other but used in base, while your example refers to a node that only = exists in other. So, my assertion about paths (they were all relative) = and prefix names was actually correct, but does not apply when = referencing a node in a different data tree (i.e., not part of the data = tree of the base module), which is what you gave an example of. >=20 > The "switching names spaces" aspect of uses explains why I cannot use = the bother prefix in relative paths, or even in paths rooted in base, = that include nodes from a grouping in other. The satisfaction of types = does seem inconsistent with this, however. I added some typedefs to = base.yang and other.yang (base-type and other-type, respectively), and = then modified the grouping in other.yang to have: >=20 > grouping other-group { > leaf other-group-leaf { type other-type; } > leaf other-base-leaf { type base-type; } > leaf other-bad-leaf { type bad-type; } > } >=20 > When the other-group is used in base.yang, only bad-type is flagged as = not found (shouldn't other-type also be flagged as not found?), while = when other-group is used in other.yang, both base-type and bad-type are = flagged as not found (as I would expect). This is not what I get:=20 $ pyang base.yang other.yang=20 other.yang:15: error: type "base-type" not found in module other other.yang:16: error: type "bad-type" not found in module other This is correct because types and everything else in a grouping are = resolved in the context of the module where the grouping is defined, = only reusable data nodes defined by the grouping receive the namespace = of the module where the grouping is used. In your case, =E2=80=9Cbase-type= =E2=80=9D is not known in =E2=80=9Cother=E2=80=9D. In the =E2=80=9Cbase=E2=80=9D module you could refer to =E2=80=9Cother-typ= e=E2=80=9D but only with the prefix: type bother:other-type This is because =E2=80=9Cbase=E2=80=9D imports =E2=80=9Cother=E2=80=9D. Lada >=20 > Thanks, >=20 > -Paul >=20 > On Thu, Jan 22, 2015 at 5:07 AM, Ladislav Lhotka = wrote: > Hi Paul, >=20 > Paul Borman writes: >=20 > > Hi, I am trying to understand RFC6020 without having had the benefit = of > > being in any of the discussions of the working group. I have found = the > > discussion of path names unclear so I have used pyang to try and = understand > > what is expected. It seems to me that a path in a leafref: > > > > - may descend into submodule's containers >=20 > yes >=20 > > - may descend into used groupings, no matter where the grouping = is > > defined >=20 > yes >=20 > > - may *not* ascend into the parent module >=20 > Actually, I am not sure about this one. >=20 > > - may optionally use the module's prefix for any element in a = leafref > > path, no matter where the element is defined >=20 > The prefix has to be present if the node is defined in another > module. For example, a leafref in "base" pointing to > "other-container-leaf1" would have >=20 > path "/bother:other-container/bother:other-container-leaf1"; >=20 > > - may optionally use the belongs-to-prefix in elements in paths = inside a > > submodule >=20 > yes >=20 > > - may *never* use the prefix for/from an imported module >=20 > It must *always* use it. >=20 > > > > Some questions this raise are: > > > > - are these observations correct (and intended)? > > - is there ever a time where a prefix is required in a leafref > > path? >=20 > Yes, see above. >=20 > I hope submodule rules will be significantly simplified in YANG 1.1, = see > issue Y49: >=20 > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-50 >=20 > ... >=20 > > > > I am also trying to understand the prefixes used in XPath = representations. > > I have tried using --tree-prefix but that does not appear to accept = any > > prefixes. >=20 > The "tree" plugin has no such option, RTFM. >=20 > > // These next two ar invalid > > leaf base-container-badref1 { > > type leafref { path > > ../other-group-container/bother:other-group-container-leaf1; } >=20 > The prefix "bother" is wrong. It is because YANG groupings are > "chameleons": nodes defined in a grouping receive the namespace of the > module where the grouping is used, not the one in which it is > defined. Sec sec. 7.12 in RFC 6020. >=20 > Lada >=20 > > } > > leaf base-container-badref2 { > > type leafref { path > > ../other-group-container/pother:other-group-container-leaf1; } > > } > > } > > } > > > > // included by base.yang. > > submodule sub { > > belongs-to base { prefix "sbase"; } > > container sub-container { > > leaf sub-container-leaf { type string; } > > container subsub { > > leaf sub-leafref { > > type leafref { path ../../sub-container-leaf; } > > } > > leaf sub-leafref1 { > > type leafref { path ../../sbase:sub-container-leaf; } > > } > > // the next two both fail trying to ascend into the parent > > leaf sub-badref2 { > > type leafref { path = ../../../base-container/base-container-leaf; } > > } > > leaf sub-badref3 { > > type leafref { path > > ../../../sbase:base-container/base-container-leaf; } > > } > > } > > } > > grouping sub-group { > > container sub-group-container { > > leaf sub-group-leaf { type string; } > > } > > } > > } > > > > // imported by base.yang. > > module other { > > namespace "uri:empty"; > > prefix "otherp"; > > container other-container { > > leaf other-container-leaf1 { type string; } > > leaf other-container-leaf2 { type string; } > > } > > grouping other-group { > > leaf other-group-leaf { type string; } > > container other-group-container { > > leaf other-group-container-leaf1 { type string; } > > leaf other-group-container-leaf2 { type string; } > > } > > } > > } > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 22 11:32:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890581A6F3B for ; Thu, 22 Jan 2015 11:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvW1QShUvdCZ for ; Thu, 22 Jan 2015 11:32:11 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589371B29D9 for ; Thu, 22 Jan 2015 11:32:11 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id id10so1180251vcb.4 for ; Thu, 22 Jan 2015 11:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0ngo/hBid8aq6FfPlJ02pR9iaJUf57NpD/Zm2iRNW8=; b=L4wogGpih+691Zmy82RBN4zjX/nnqIB/VXx71neWq8Ik9y2cvZm2553XasJg2I5xE9 0TUlcjYdeJbj+OTT3+KvGWjY72fm9pJxrai3npEI5DD0cR3zpkGa8ieD5eiRq9Vk7w6C NaEQibgDHCxGF+UGW8tKP+NRPIzYOKXnukFpsRqsK89Fvohbio44x5UVl4t20SAw+NAN ZXlu7SCeJswJi0X246vuNpOCyxt/ic3+U7/jeIKkTcm+AhFVEVf6Hwu7DvR3rRXxB0XZ VWUk6QyF8IIJMU869VSqxi/ixy0OzS0uQg5cp87ed36sNYGuo+ugQxC1d4gSVZqyBpNs AP8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m0ngo/hBid8aq6FfPlJ02pR9iaJUf57NpD/Zm2iRNW8=; b=VVLfQKEXHoZ7OgAh823J+JeXtK+n1MOn/CbFO65wIQdlKOufm77/hV29ai/sMTBNal zR6+Jsl75LOm7VVFkPBQsYseyIJvo3tEwg3S0EjnVoNjOgiJBTEBbd5L7VVPbIkJKyeo VjzcZneIW21j8wRu/Bg9l3tfmFRCV3nX4vNYN95rYcWBQ68sdl8QRN/shYMx/M5a6kPk 2OnL8QfNWszbQS8YJ/99+ioeaDmYeS+k5CnCaF6bcZJZekQtkXPqsNEZR5DfOSwfDRyq rPFpDyUaOw6UlTbUKHmbREAPk+xvpWH8h5ZA2DEVIDTIJ64QgBAYcEd4sdPEvnGSlqvf G+Ag== X-Gm-Message-State: ALoCoQnT2Kr/WbU9kP8UUaxsBe9pCfPfnpZd9qMF/wZ0N1P8Xz+AZcStCHJE4QLvaeUDjllD2rfh MIME-Version: 1.0 X-Received: by 10.52.87.209 with SMTP id ba17mr1413626vdb.28.1421955130021; Thu, 22 Jan 2015 11:32:10 -0800 (PST) Received: by 10.52.246.194 with HTTP; Thu, 22 Jan 2015 11:32:09 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Jan 2015 11:32:09 -0800 Message-ID: From: Paul Borman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec50407fe697821050d42ba75 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Questions about namings and prefixes in leafrefs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 19:32:15 -0000 --bcaec50407fe697821050d42ba75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > $ pyang base.yang other.yang > other.yang:15: error: type "base-type" not found in module other > other.yang:16: error: type "bad-type" not found in module other Okay, this appears to be a bug in the tree format: $ *pyang base.yang 2>&1 | grep -- -type* other.yang:15: error: type "base-type" not found in module other other.yang:16: error: type "bad-type" not found in module other $ *pyang -f tree base.yang 2>&1 | grep -- -type* +--rw other-group-leaf? other-type +--rw other-base-leaf? base-type +--rw other-bad-leaf? bad-type $ *pyang -f tree base.yang other.yang 2>&1 | grep -- -type* other.yang:15: error: type "base-type" not found in module other other.yang:16: error: type "bad-type" not found in module other +--rw other-group-leaf? other-type +--rw other-base-leaf? base-type +--rw other-bad-leaf? bad-type +--rw other-group-leaf? other-type +--rw other-base-leaf? base-type +--rw other-bad-leaf? bad-type I only specified base.yang as that was the only tree I was interested in. This research is part of a larger issue of how we are going to be able to combine various disparate modules defined in YANG into a single tree. Thus far it appears that module writers decide where the root of their tree is and the data tree of one module cannot become part of a tree for another module. That is, we cannot write, in pure YANG, a super module that includes several other modules where those module writers were unaware of the super module. It is recursive because we probably will later need a super super module that is a collection of super modules (and regular modules). Currently it appears that modules always know the root of the tree (either their own or one they augment). I don't yet see a combination of include, import, grouping, augment and/or uses that would enable this ability, but perhaps I am missing something. Thanks, -Paul On Thu, Jan 22, 2015 at 10:18 AM, Ladislav Lhotka wrote: > > > On 22 Jan 2015, at 18:43, Paul Borman wrote: > > > > Thanks for the response and clarification, Lada. > > > > > I am also trying to understand the prefixes used in XPath > representations. > > > I have tried using --tree-prefix but that does not appear to accept a= ny > > > prefixes. > > > > The "tree" plugin has no such option, RTFM. > > > > Yes, clearly I meant --tree-path. Sorry to have confused you. Given > the chameleon aspect of groups, I take it that paths to a node in a data > tree (not the schema tree) do not have prefixes, and --tree-path takes a > path in the data tree (the documentation I read just says "Subtree to > print"). I am actually very happy to not have prefixes in the resulting > data tree at all. > > Sometimes they are needed, even in JSON encoding that tries to suppress > them as much as possible. > > > > > > - may optionally use the module's prefix for any element in a > leafref > > > path, no matter where the element is defined > > > > The prefix has to be present if the node is defined in another > > module. For example, a leafref in "base" pointing to > > "other-container-leaf1" would have > > > > path "/bother:other-container/bother:other-container-leaf1"; > > > > Interesting. So a path in a leafref references the resulting data tree= , > while the path provided to augment references the schema tree. Re-readin= g > the "uses" description I see where it switches > > That=E2=80=99s right, augments modify the schema tree. > > > namespaces. > > > > Since it appears, via empirical evidence with pyang, that the nodes of > an imported tree do not become part of the tree of the importing module. > What does it mean to have a leafref reference a node in a > > That=E2=80=99s correct, the importing module only gets access to top-leve= l > groupings, typedefs, identities and features. > > > tree other than its own? I will note that my example referred to a > node within a grouping defined in > > The information about the set of modules that comprise the data model has > to be supplied by other means. In NETCONF it is the hello message, and in > pyang you can either provide a hello message as an XML document (with the > --hello option), or simply put all modules on the command line. In your > case it could be > > $ pyang -f tree base.yang other.yang > > > other but used in base, while your example refers to a node that only > exists in other. So, my assertion about paths (they were all relative) a= nd > prefix names was actually correct, but does not apply when referencing a > node in a different data tree (i.e., not part of the data tree of the bas= e > module), which is what you gave an example of. > > > > The "switching names spaces" aspect of uses explains why I cannot use > the bother prefix in relative paths, or even in paths rooted in base, tha= t > include nodes from a grouping in other. The satisfaction of types does > seem inconsistent with this, however. I added some typedefs to base.yang > and other.yang (base-type and other-type, respectively), and then modifie= d > the grouping in other.yang to have: > > > > grouping other-group { > > leaf other-group-leaf { type other-type; } > > leaf other-base-leaf { type base-type; } > > leaf other-bad-leaf { type bad-type; } > > } > > > > When the other-group is used in base.yang, only bad-type is flagged as > not found (shouldn't other-type also be flagged as not found?), while whe= n > other-group is used in other.yang, both base-type and bad-type are flagge= d > as not found (as I would expect). > > This is not what I get: > > $ pyang base.yang other.yang > other.yang:15: error: type "base-type" not found in module other > other.yang:16: error: type "bad-type" not found in module other > > This is correct because types and everything else in a grouping are > resolved in the context of the module where the grouping is defined, only > reusable data nodes defined by the grouping receive the namespace of the > module where the grouping is used. In your case, =E2=80=9Cbase-type=E2=80= =9D is not known > in =E2=80=9Cother=E2=80=9D. > > In the =E2=80=9Cbase=E2=80=9D module you could refer to =E2=80=9Cother-ty= pe=E2=80=9D but only with the > prefix: > > type bother:other-type > > This is because =E2=80=9Cbase=E2=80=9D imports =E2=80=9Cother=E2=80=9D. > > Lada > > > > > Thanks, > > > > -Paul > > > > On Thu, Jan 22, 2015 at 5:07 AM, Ladislav Lhotka wrote: > > Hi Paul, > > > > Paul Borman writes: > > > > > Hi, I am trying to understand RFC6020 without having had the benefit = of > > > being in any of the discussions of the working group. I have found t= he > > > discussion of path names unclear so I have used pyang to try and > understand > > > what is expected. It seems to me that a path in a leafref: > > > > > > - may descend into submodule's containers > > > > yes > > > > > - may descend into used groupings, no matter where the grouping is > > > defined > > > > yes > > > > > - may *not* ascend into the parent module > > > > Actually, I am not sure about this one. > > > > > - may optionally use the module's prefix for any element in a > leafref > > > path, no matter where the element is defined > > > > The prefix has to be present if the node is defined in another > > module. For example, a leafref in "base" pointing to > > "other-container-leaf1" would have > > > > path "/bother:other-container/bother:other-container-leaf1"; > > > > > - may optionally use the belongs-to-prefix in elements in paths > inside a > > > submodule > > > > yes > > > > > - may *never* use the prefix for/from an imported module > > > > It must *always* use it. > > > > > > > > Some questions this raise are: > > > > > > - are these observations correct (and intended)? > > > - is there ever a time where a prefix is required in a leafref > > > path? > > > > Yes, see above. > > > > I hope submodule rules will be significantly simplified in YANG 1.1, se= e > > issue Y49: > > > > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-50 > > > > ... > > > > > > > > I am also trying to understand the prefixes used in XPath > representations. > > > I have tried using --tree-prefix but that does not appear to accept a= ny > > > prefixes. > > > > The "tree" plugin has no such option, RTFM. > > > > > // These next two ar invalid > > > leaf base-container-badref1 { > > > type leafref { path > > > ../other-group-container/bother:other-group-container-leaf1; } > > > > The prefix "bother" is wrong. It is because YANG groupings are > > "chameleons": nodes defined in a grouping receive the namespace of the > > module where the grouping is used, not the one in which it is > > defined. Sec sec. 7.12 in RFC 6020. > > > > Lada > > > > > } > > > leaf base-container-badref2 { > > > type leafref { path > > > ../other-group-container/pother:other-group-container-leaf1; } > > > } > > > } > > > } > > > > > > // included by base.yang. > > > submodule sub { > > > belongs-to base { prefix "sbase"; } > > > container sub-container { > > > leaf sub-container-leaf { type string; } > > > container subsub { > > > leaf sub-leafref { > > > type leafref { path ../../sub-container-leaf; } > > > } > > > leaf sub-leafref1 { > > > type leafref { path ../../sbase:sub-container-leaf; } > > > } > > > // the next two both fail trying to ascend into the parent > > > leaf sub-badref2 { > > > type leafref { path > ../../../base-container/base-container-leaf; } > > > } > > > leaf sub-badref3 { > > > type leafref { path > > > ../../../sbase:base-container/base-container-leaf; } > > > } > > > } > > > } > > > grouping sub-group { > > > container sub-group-container { > > > leaf sub-group-leaf { type string; } > > > } > > > } > > > } > > > > > > // imported by base.yang. > > > module other { > > > namespace "uri:empty"; > > > prefix "otherp"; > > > container other-container { > > > leaf other-container-leaf1 { type string; } > > > leaf other-container-leaf2 { type string; } > > > } > > > grouping other-group { > > > leaf other-group-leaf { type string; } > > > container other-group-container { > > > leaf other-group-container-leaf1 { type string; } > > > leaf other-group-container-leaf2 { type string; } > > > } > > > } > > > } > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --bcaec50407fe697821050d42ba75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
$ pyang base.yang other.yang
other.yan= g:15: error: type "base-type" not found in module other
other.= yang:16: error: type "bad-type" not found in module other

Okay, this appears to be a bug in the tree format:=

$ pyang base.yang 2>&1 | grep -- -type
other.yang:15: error: type "base-type"= not found in module other
other.yang:16: error: type "bad-type" not found in module ot= her
$ pyang -f tree= base.yang 2>&1 | grep -- -type
=C2=A0 =C2=A0 =C2=A0 +--rw other-group-leaf? =C2=A0 = =C2=A0 =C2=A0 =C2=A0 other-type
=C2=A0 =C2=A0 =C2=A0 +--rw other-base-leaf? =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0base-type
=C2=A0 =C2=A0 =C2=A0 +--rw other-bad-leaf? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 bad-type
$ pyan= g -f tree base.yang other.yang 2>&1 | grep -- -type
other.yang:15: error: type &qu= ot;base-type" not found in module other
other.yang:16: error: type "bad-type" not = found in module other
= =C2=A0 =C2=A0 =C2=A0 +--rw other-group-leaf? =C2=A0 =C2=A0 =C2=A0 =C2=A0 ot= her-type
=C2=A0 =C2=A0= =C2=A0 +--rw other-base-leaf? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base-type<= /font>
=C2=A0 =C2=A0 =C2=A0 += --rw other-bad-leaf? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bad-type
=C2=A0 =C2=A0+--rw other-group-l= eaf? =C2=A0 =C2=A0 =C2=A0 =C2=A0other-type
=C2=A0 =C2=A0+--rw other-base-leaf? =C2=A0 =C2=A0 =C2= =A0 =C2=A0 base-type
= =C2=A0 =C2=A0+--rw other-bad-leaf? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bad-ty= pe

I only specified base.yang as that= was the only tree I was interested in.

This resea= rch is part of a larger issue of how we are going to be able to combine var= ious disparate modules defined in YANG into a single tree.=C2=A0 Thus far i= t appears that module writers decide where the root of their tree is and th= e data tree of one module cannot become part of a tree for another module.= =C2=A0 That is, we cannot write, in pure YANG, a super module that includes= several other modules where those module writers were unaware of the super= module.=C2=A0 It is recursive because we probably will later need a super = super module that is a collection of super modules (and regular modules).= =C2=A0 Currently it appears that modules always know the root of the tree (= either their own or one they augment).=C2=A0 I don't yet see a combinat= ion of include, import, grouping, augment and/or uses that would enable thi= s ability, but perhaps I am missing something.

Tha= nks,

=C2=A0 =C2=A0 -Paul

On Thu, Jan= 22, 2015 at 10:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 22 Jan 2015, at 18:43, Paul Borman <borman@google.com> wrote:
>
> Thanks for the response and clarification, Lada.
>
> > I am also trying to understand the prefixes used in XPath represe= ntations.
> > I have tried using --tree-prefix but that does not appear to acce= pt any
> > prefixes.
>
> The "tree" plugin has no such option, RTFM.
>
> Yes, clearly I meant --tree-path.=C2=A0 Sorry to have confused you.=C2= =A0 Given the chameleon aspect of groups, I take it that paths to a node in= a data tree (not the schema tree) do not have prefixes, and --tree-path ta= kes a path in the data tree (the documentation I read just says "Subtr= ee to print").=C2=A0 I am actually very happy to not have prefixes in = the resulting data tree at all.

Sometimes they are needed, even in JSON encoding that tries to suppr= ess them as much as possible.

>
> >=C2=A0 =C2=A0 - may optionally use the module's prefix for any= element in a leafref
> >=C2=A0 =C2=A0 path, no matter where the element is defined
>
> The prefix has to be present if the node is defined in another
> module. For example, a leafref in "base" pointing to
> "other-container-leaf1" would have
>
>=C2=A0 =C2=A0path "/bother:other-container/bother:other-container-= leaf1";
>
> Interesting.=C2=A0 So a path in a leafref references the resulting dat= a tree, while the path provided to augment references the schema tree.=C2= =A0 Re-reading the "uses" description I see where it switches

That=E2=80=99s right, augments modify the schema tree.

>=C2=A0 namespaces.
>
> Since it appears, via empirical evidence with pyang, that the nodes of= an imported tree do not become part of the tree of the importing module.= =C2=A0 What does it mean to have a leafref reference a node in a

That=E2=80=99s correct, the importing module only gets access to top= -level groupings, typedefs, identities and features.

>=C2=A0 tree other than its own?=C2=A0 I will note that my example refer= red to a node within a grouping defined in

The information about the set of modules that comprise the data mode= l has to be supplied by other means. In NETCONF it is the hello message, an= d in pyang you can either provide a hello message as an XML document (with = the --hello option), or simply put all modules on the command line. In your= case it could be

$ pyang -f tree base.yang other.yang

>=C2=A0 other but used in base, while your example refers to a node that= only exists in other.=C2=A0 So, my assertion about paths (they were all re= lative) and prefix names was actually correct, but does not apply when refe= rencing a node in a different data tree (i.e., not part of the data tree of= the base module), which is what you gave an example of.
>
> The "switching names spaces" aspect of uses explains why I c= annot use the bother prefix in relative paths, or even in paths rooted in b= ase, that include nodes from a grouping in other.=C2=A0 The satisfaction of= types does seem inconsistent with this, however.=C2=A0 I added some typede= fs to base.yang and other.yang (base-type and other-type, respectively), an= d then modified the grouping in other.yang to have:
>
>=C2=A0 =C2=A0grouping other-group {
>=C2=A0 =C2=A0 =C2=A0leaf other-group-leaf { type other-type; }
>=C2=A0 =C2=A0 =C2=A0leaf other-base-leaf { type base-type; }
>=C2=A0 =C2=A0 =C2=A0leaf other-bad-leaf { type bad-type; }
>=C2=A0 =C2=A0}
>
> When the other-group is used in base.yang, only bad-type is flagged as= not found (shouldn't other-type also be flagged as not found?), while = when other-group is used in other.yang, both base-type and bad-type are fla= gged as not found (as I would expect).

This is not what I get:

$ pyang base.yang other.yang
other.yang:15: error: type "base-type" not found in module other<= br> other.yang:16: error: type "bad-type" not found in module other
This is correct because types and everything else in a grouping are resolve= d in the context of the module where the grouping is defined, only reusable= data nodes defined by the grouping receive the namespace of the module whe= re the grouping is used. In your case, =E2=80=9Cbase-type=E2=80=9D is not k= nown in =E2=80=9Cother=E2=80=9D.

In the =E2=80=9Cbase=E2=80=9D module you could refer to =E2=80=9Cother-type= =E2=80=9D but only with the prefix:

type bother:other-type

This is because =E2=80=9Cbase=E2=80=9D imports =E2=80=9Cother=E2=80=9D.

Lada

>
> Thanks,
>
>=C2=A0 =C2=A0 =C2=A0-Paul
>
> On Thu, Jan 22, 2015 at 5:07 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi Paul,
>
> Paul Borman <borman@google.com= > writes:
>
> > Hi, I am trying to understand RFC6020 without having had the bene= fit of
> > being in any of the discussions of the working group.=C2=A0 I hav= e found the
> > discussion of path names unclear so I have used pyang to try and = understand
> > what is expected.=C2=A0 It seems to me that a path in a leafref:<= br> > >
> >=C2=A0 =C2=A0 - may descend into submodule's containers
>
> yes
>
> >=C2=A0 =C2=A0 - may descend into used groupings, no matter where t= he grouping is
> >=C2=A0 =C2=A0 defined
>
> yes
>
> >=C2=A0 =C2=A0 - may *not* ascend into the parent module
>
> Actually, I am not sure about this one.
>
> >=C2=A0 =C2=A0 - may optionally use the module's prefix for any= element in a leafref
> >=C2=A0 =C2=A0 path, no matter where the element is defined
>
> The prefix has to be present if the node is defined in another
> module. For example, a leafref in "base" pointing to
> "other-container-leaf1" would have
>
>=C2=A0 =C2=A0path "/bother:other-container/bother:other-container-= leaf1";
>
> >=C2=A0 =C2=A0 - may optionally use the belongs-to-prefix in elemen= ts in paths inside a
> >=C2=A0 =C2=A0 submodule
>
> yes
>
> >=C2=A0 =C2=A0 - may *never* use the prefix for/from an imported mo= dule
>
> It must *always* use it.
>
> >
> > Some questions this raise are:
> >
> >=C2=A0 =C2=A0 - are these observations correct (and intended)?
> >=C2=A0 =C2=A0 - is there ever a time where a prefix is required in= a leafref
> >=C2=A0 =C2=A0 path?
>
> Yes, see above.
>
> I hope submodule rules will be significantly simplified in YANG 1.1, s= ee
> issue Y49:
>
> https://svn.tools.ietf.org/svn/wg/netmod/yang-= 1.1/issues.html#sec-50
>
> ...
>
> >
> > I am also trying to understand the prefixes used in XPath represe= ntations.
> > I have tried using --tree-prefix but that does not appear to acce= pt any
> > prefixes.
>
> The "tree" plugin has no such option, RTFM.
>
> >=C2=A0 =C2=A0 =C2=A0// These next two ar invalid
> >=C2=A0 =C2=A0 =C2=A0leaf base-container-badref1 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path
> > ../other-group-container/bother:other-group-container-leaf1; } >
> The prefix "bother" is wrong. It is because YANG groupings a= re
> "chameleons": nodes defined in a grouping receive the namesp= ace of the
> module where the grouping is used, not the one in which it is
> defined. Sec sec. 7.12 in RFC 6020.
>
> Lada
>
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf base-container-badref2 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path
> > ../other-group-container/pother:other-group-container-leaf1; } > >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> > }
> >
> > // included by base.yang.
> > submodule sub {
> >=C2=A0 =C2=A0belongs-to base { prefix "sbase"; }
> >=C2=A0 =C2=A0container sub-container {
> >=C2=A0 =C2=A0 =C2=A0leaf sub-container-leaf { type string; }
> >=C2=A0 =C2=A0 =C2=A0container subsub {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-leafref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path ../../sub-co= ntainer-leaf; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-leafref1 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path ../../sbase:= sub-container-leaf; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0// the next two both fail trying to asc= end into the parent
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-badref2 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path ../../../bas= e-container/base-container-leaf; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-badref3 {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref { path
> > ../../../sbase:base-container/base-container-leaf; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0grouping sub-group {
> >=C2=A0 =C2=A0 =C2=A0container sub-group-container {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf sub-group-leaf { type string; } > >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> > }
> >
> > // imported by base.yang.
> > module other {
> >=C2=A0 =C2=A0namespace "uri:empty";
> >=C2=A0 =C2=A0prefix "otherp";
> >=C2=A0 =C2=A0container other-container {
> >=C2=A0 =C2=A0 =C2=A0leaf other-container-leaf1 { type string; } > >=C2=A0 =C2=A0 =C2=A0leaf other-container-leaf2 { type string; } > >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0grouping other-group {
> >=C2=A0 =C2=A0 =C2=A0leaf other-group-leaf { type string; }
> >=C2=A0 =C2=A0 =C2=A0container=C2=A0 other-group-container {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf other-group-container-leaf1 { type= string; }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf other-group-container-leaf2 { type= string; }
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> > }
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--bcaec50407fe697821050d42ba75-- From nobody Thu Jan 22 15:57:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45C31A0035 for ; Thu, 22 Jan 2015 15:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Q4obabnmIE for ; Thu, 22 Jan 2015 15:57:38 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 450031A8A49 for ; Thu, 22 Jan 2015 15:57:38 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id 10so3215029lbg.6 for ; Thu, 22 Jan 2015 15:57:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ZEo7uLkj2X0C61/C5k93b4kql4x6AcGegKHE3W20jwo=; b=agnUHyhYvM4MFoyIrRTzeMX0YiTCPfJ9nkkMJWamY9WumCUCLYLf5XU66+s1fN+o/f kQz8kvxBFe5QvykxvO5gHJf2cJte/vZKsHOCRCZEaBsjTQ1gBlEg0l/HI583RXGji9zz 2XzPQUj7jd6xNJZCnFBjzS5EZ6fvpHNLvFnYUzY0iL82O7EimygTzOpUXYkJy8Hy3ID1 enTb00Oz2kytEg2jQ1/JC/NeSVrKKhdpv+eOYj+gSHHFALeNXXuLoCIPS8CTlwhr1zaI dWx+68SRtpPPRKNC0OwiOaiaI5wyj3V8rS75F1C3TBt7sWuApZKiHMnx1EZzVxQPdhR3 fP7w== X-Gm-Message-State: ALoCoQmpipY6AzRipCiIbyHlAuhy0DSEqjaTVYGP5oQQvI3gtAezELIx9S7+GcWUP/q6EFAlUj7j MIME-Version: 1.0 X-Received: by 10.112.12.65 with SMTP id w1mr4479576lbb.68.1421971056779; Thu, 22 Jan 2015 15:57:36 -0800 (PST) Received: by 10.112.160.41 with HTTP; Thu, 22 Jan 2015 15:57:36 -0800 (PST) In-Reply-To: References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> Date: Thu, 22 Jan 2015 15:57:36 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 23:57:40 -0000 On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder > wrote: >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >>> Hi, >>> >>> Juergen Schoenwaelder wrote: >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. >>> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as >>> 'anydata' with the constraint that it only can hande top-level nodes. >>> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml >>> with non-top-level nodes. It would not be possible to use 'root' in >>> this case. 'anydata' would be a better match. >>> >> >> Andy, >> >> can you please respond to this since you created Y34-04? I now hear >> two people in favour of Y34-02 and we had this back in July 2014: >> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out >> a concrete proposal. >> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional >> text (the three list items) or (ii) additional restrictions of "root" >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known >> to everybody.) >> > > > There are corner cases like YANG Patch edit value that need to be > anyxml. > >> Would adoption of Y34-02 with the additional text (the three list >> items) of Y34-04 be a workable solution? >> The discussion in the last VI meeting seemed to favor this solution but there is still this issue of JSON -> XML -> JSON round-trip conversion of anydata (unstructured data). IMO the loss of JSON typing through the XML conversion is not an issue because the only schema that matters is the YANG anydata. E.g., booleans and numbers are just strings. null is not supported. All simple nodes are strings. There are no keys so there are no real arrays. The server may return multiple containers that could have been encoded as an array. > > yes > > >> /js >> > > Andy > Andy >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jan 22 17:08:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68561A009B; Thu, 22 Jan 2015 17:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRt1nGTeqGcH; Thu, 22 Jan 2015 17:08:25 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 270FB1B2AC0; Thu, 22 Jan 2015 17:08:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=156.39.127.195; From: "Susan Hares" To: "NETCONF" , , Date: Thu, 22 Jan 2015 20:08:21 -0500 Message-ID: <030b01d036a9$14f3cf80$3edb6e80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030C_01D0367F.2C1EB1E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA2qMM51LzDU+5zTs6Y4GauOzob4g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Joel Jaeggli Subject: [netmod] IDR Interim on 1/26/2015 10-11:00am ET - Topic BGP Yang Data Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 01:08:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_030C_01D0367F.2C1EB1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cross-posting of a Discussion of BGP Yang Data Modules to yang data modules. IDR Interim 2 (BGP Yang Modules) Monday, January 26, 2015 10-00 - 11:30 am | Eastern Standard Time (New York, GMT-05:00) | 1.5 hours Agenda: 1) Agenda Bashing (Sue Hares) - 5 minutes 2) OpenConfig BGP Yang Data Model (Anees Shaikh) - 25 minutes 3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) - 10 minutes 4) Discussion of Two Yang Data Model - 20 minutes Documents or code to read for the meeting: https://github.com/YangModels/yang/tree/master/experimental/openconfig http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 Slides for the interim are at: http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html Sue Hares Webex info: https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d Meeting number: 645 690 989 Meeting password: yangisfun Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 645 690 989 ------=_NextPart_000_030C_01D0367F.2C1EB1E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cross-postin= g of a Discussion of BGP Yang Data Modules to yang data modules. =

 

IDR Interim 2 (BGP Yang Modules) =

Monday, January 26, 2015 =

10-00 – 11:30 am  |  = Eastern Standard Time (New York, GMT-05:00)  | 1.5 hours =

 

Agenda:

1) = Agenda Bashing (Sue Hares) - 5 minutes

2) OpenConfig BGP Yang Data Model  (Anees Shaikh) = - 25 minutes

3) Update on = draft-zhdankin-netmod-bgp-cfg (TBD)  - 10 minutes

4) Discussion of Two Yang Data Model - 20 minutes =  

 

Documents or code to read for the = meeting:

 

https://github.com/YangModels/yang/tree/master/experimental/openco= nfig

http= ://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01

 

Slides for the interim are at: =   

 

http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceeding= s.html

 

Sue Hares =

 

Webex info:

https://ietf.webex.com/ietf/j.php?MTID=3Dm0221956daac063993195= 5e8e6eef206d

 

 

Meeting = number:            645 = 690 989

Meeting = password:         = yangisfun

 

Join by phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in = toll number (US/Canada)

Access code: = 645 690 989

 

 

------=_NextPart_000_030C_01D0367F.2C1EB1E0-- From nobody Thu Jan 22 23:57:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585951A036F for ; Thu, 22 Jan 2015 23:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDjY4-RiO4Wp for ; Thu, 22 Jan 2015 23:56:57 -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 120AB1A010A for ; Thu, 22 Jan 2015 23:56:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 65805781; Fri, 23 Jan 2015 08:56:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EdOZMByVy8VG; Fri, 23 Jan 2015 08:56:29 +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, 23 Jan 2015 08:56:54 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6752D20036; Fri, 23 Jan 2015 08:56:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uMiwiPEI6-eY; Fri, 23 Jan 2015 08:56:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9785A20035; Fri, 23 Jan 2015 08:56:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 26F9530E4ACB; Fri, 23 Jan 2015 08:56:51 +0100 (CET) Date: Fri, 23 Jan 2015 08:56:51 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150123075651.GA37850@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 07:56:59 -0000 On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: > On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: > > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder > > wrote: > >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: > >>> Hi, > >>> > >>> Juergen Schoenwaelder wrote: > >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. > >>> > >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add > >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') > >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as > >>> 'anydata' with the constraint that it only can hande top-level nodes. > >>> > >>> As an example of why this is not sufficient, YANG PATCH uses anyxml > >>> with non-top-level nodes. It would not be possible to use 'root' in > >>> this case. 'anydata' would be a better match. > >>> > >> > >> Andy, > >> > >> can you please respond to this since you created Y34-04? I now hear > >> two people in favour of Y34-02 and we had this back in July 2014: > >> > >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out > >> a concrete proposal. > >> > >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional > >> text (the three list items) or (ii) additional restrictions of "root" > >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known > >> to everybody.) > >> > > > > > > There are corner cases like YANG Patch edit value that need to be > > anyxml. > > > >> Would adoption of Y34-02 with the additional text (the three list > >> items) of Y34-04 be a workable solution? > >> > > > The discussion in the last VI meeting seemed to favor this solution > but there is still this issue of JSON -> XML -> JSON round-trip > conversion of anydata (unstructured data). > > IMO the loss of JSON typing through the XML conversion > is not an issue because the only schema that matters is > the YANG anydata. E.g., booleans and numbers are > just strings. null is not supported. All simple nodes are > strings. There are no keys so there are no real arrays. > The server may return multiple containers that could > have been encoded as an array. > Yes, the JSON I-D must be updated to define how anydata is encoded. In general, I believe a JSON receiver must be able to do conversions if needed, that is, if the JSON type does not match the type of the YANG data model, the receiver must convert as needed instead of throwing an error. I believe the YANG type is authoritative, not the type used in the encoding. Lada may not like this but since the two type systems do not align 1:1, I think giving the YANG type system authority is the way to go. And the principle "the receiver converts as needed" instead of throwing an error follows the Postel principle. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 23 00:07:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B91A903A for ; Fri, 23 Jan 2015 00:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB7KRb5-6ARX for ; Fri, 23 Jan 2015 00:06:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7481A9037 for ; Fri, 23 Jan 2015 00:06:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F3778187E26; Fri, 23 Jan 2015 00:06:32 -0800 (PST) To: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, tnadeau@lucidvision.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150123080632.F3778187E26@rfc-editor.org> Date: Fri, 23 Jan 2015 00:06:32 -0800 (PST) Archived-At: Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC7407 (4240) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 08:06:59 -0000 The following errata report has been submitted for RFC7407, "A YANG Data Model for SNMP Configuration". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7407&eid=4240 -------------------------------------- Type: Technical Reported by: Martin Bj̦rklund Section: 4.8 Original Text ------------- augment /snmp:snmp/snmp:target { when "snmp:v1 or snmp:v2c"; Corrected Text -------------- augment /snmp:snmp/snmp:target { Notes ----- The nodes refered to in the "when" expression do not exist. (They were there in an early draft version, but when they were moved, we forgot to fix the "when" expression). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7407 (draft-ietf-netmod-snmp-cfg-08) -------------------------------------- Title : A YANG Data Model for SNMP Configuration Publication Date : December 2014 Author(s) : M. Bjorklund, J. Schoenwaelder Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Jan 23 00:21:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFF11A00D8; Fri, 23 Jan 2015 00:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qF7afuvI6IR; Fri, 23 Jan 2015 00:21:43 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45151A8912; Fri, 23 Jan 2015 00:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7176; q=dns/txt; s=iport; t=1422001303; x=1423210903; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Xc+cZodv1ZiPTmUXruUHb3YelM4MTNWmlNE59fdzxrg=; b=UBjipF43opEPpDe2k3AhBEAa0yPtFb2wsF0v6pOlsamRtdEJdU9I6Mot arrcGbf8OhDxwse3gxK3mCGv+AgXcHw+gaUD1bOja6x1G5E27CE8cNZkE EJAjJ9WlrkQs+OpgfA0l//sMAYtptVrNNfA7EF+aAK6xvMRGwU5u4Awem Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8EABoDwlStJssW/2dsb2JhbABAFwOCQ4EVWMZPhSVKAoFVAQEBAQF9hA0BAQQtORIBDgILDhMLBAcFCgkDAgECAQk7AQMDAQwBBwEBBYgjDTfDA48yAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSMRIJsNBAHEQeEEQWSMIVPgRQ2hGghhTOGLyKCD4ERTz0xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,453,1418083200"; d="scan'208,217";a="323509175" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 23 Jan 2015 08:21:42 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0N8Ld9f030462; Fri, 23 Jan 2015 08:21:40 GMT Message-ID: <54C20493.2060200@cisco.com> Date: Fri, 23 Jan 2015 09:21:39 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Susan Hares , NETCONF , netmod@ietf.org, Rtg-yang-coord@ietf.org References: <030b01d036a9$14f3cf80$3edb6e80$@ndzh.com> In-Reply-To: <030b01d036a9$14f3cf80$3edb6e80$@ndzh.com> Content-Type: multipart/alternative; boundary="------------020708000705080904030604" Archived-At: Cc: Joel Jaeggli Subject: Re: [netmod] IDR Interim on 1/26/2015 10-11:00am ET - Topic BGP Yang Data Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 08:21:45 -0000 This is a multi-part message in MIME format. --------------020708000705080904030604 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Sue, Thanks for forwarding. I will be in a plane at that time. Would you mind recording the meeting. Regards, Benoit > > *Cross-posting of a Discussion of BGP Yang Data Modules to yang data > modules. * > > *IDR Interim 2 (BGP Yang Modules) * > > Monday, January 26, 2015 > > 10-00 Р11:30 am | Eastern Standard Time (New York, GMT-05:00) | > 1.5 hours > > *Agenda: * > > 1) Agenda Bashing (Sue Hares) - 5 minutes > > 2) OpenConfig BGP Yang Data Model (Anees Shaikh) - 25 minutes > > 3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) - 10 minutes > > 4) Discussion of Two Yang Data Model - 20 minutes > > *Documents or code to read for the meeting:* > > https://github.com/YangModels/yang/tree/master/experimental/openconfig > > http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 > > *Slides for the interim are at: * > > http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html > > Sue Hares > > Webex info: > > https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d > > Meeting number: 645 690 989 > > Meeting password: yangisfun > > Join by phone > > 1-877-668-4493 Call-in toll free number (US/Canada) > > 1-650-479-3208 Call-in toll number (US/Canada) > > Access code: 645 690 989 > --------------020708000705080904030604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Sue,

Thanks for forwarding.
I will be in a plane at that time.
Would you mind recording the meeting.

Regards, Benoit

Cross-posting of a Discussion of BGP Yang Data Modules to yang data modules.

 

IDR Interim 2 (BGP Yang Modules)

Monday, January 26, 2015

10-00 – 11:30 am  |  Eastern Standard Time (New York, GMT-05:00)  | 1.5 hours

 

Agenda:

1) Agenda Bashing (Sue Hares) - 5 minutes

2) OpenConfig BGP Yang Data Model  (Anees Shaikh) - 25 minutes

3) Update on draft-zhdankin-netmod-bgp-cfg (TBD)  - 10 minutes

4) Discussion of Two Yang Data Model - 20 minutes  

 

Documents or code to read for the meeting:

 

https://github.com/YangModels/yang/tree/master/experimental/openconfig

http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01

 

Slides for the interim are at:   

 

http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html

 

Sue Hares

 

Webex info:

https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d

 

 

Meeting number:            645 690 989

Meeting password:         yangisfun

 

Join by phone

1-877-668-4493 Call-in toll free number (US/Canada)

1-650-479-3208 Call-in toll number (US/Canada)

Access code: 645 690 989

 

 


--------------020708000705080904030604-- From nobody Fri Jan 23 01:34:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF41A0204 for ; Fri, 23 Jan 2015 01:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qehc5D31ZbNJ for ; Fri, 23 Jan 2015 01:34:14 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9511A01AE for ; Fri, 23 Jan 2015 01:34:13 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 743041CC05F5; Fri, 23 Jan 2015 10:34:14 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , "netmod\@ietf.org" In-Reply-To: References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 23 Jan 2015 10:34:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 09:34:16 -0000 Andy Bierman writes: > On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: >> On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >> wrote: >>> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >>>> Hi, >>>> >>>> Juergen Schoenwaelder wrote: >>>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. >>>> >>>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >>>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') >>>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as >>>> 'anydata' with the constraint that it only can hande top-level nodes. >>>> >>>> As an example of why this is not sufficient, YANG PATCH uses anyxml >>>> with non-top-level nodes. It would not be possible to use 'root' in >>>> this case. 'anydata' would be a better match. >>>> >>> >>> Andy, >>> >>> can you please respond to this since you created Y34-04? I now hear >>> two people in favour of Y34-02 and we had this back in July 2014: >>> >>> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out >>> a concrete proposal. >>> >>> So is the main delta of Y34-04 compared to Y34-02 (i) the additional >>> text (the three list items) or (ii) additional restrictions of "root" >>> to top-level nodes. (The Y34-04 referes to ncx:root which is not known >>> to everybody.) >>> >> >> >> There are corner cases like YANG Patch edit value that need to be >> anyxml. >> >>> Would adoption of Y34-02 with the additional text (the three list >>> items) of Y34-04 be a workable solution? >>> > > > The discussion in the last VI meeting seemed to favor this solution > but there is still this issue of JSON -> XML -> JSON round-trip > conversion of anydata (unstructured data). > > IMO the loss of JSON typing through the XML conversion > is not an issue because the only schema that matters is > the YANG anydata. E.g., booleans and numbers are > just strings. null is not supported. All simple nodes are > strings. There are no keys so there are no real arrays. > The server may return multiple containers that could > have been encoded as an array. So it seems JSON encoding will change (compared to draft-ietf-netmod-yang-json-02, sec. 5.5) only so that null will be allowed only in a single-element array ("[null]") and array containing both scalar values and objects/arrays won't be allowed. Is it correct? Lada > > >> >> yes >> >> >>> /js >>> >> >> Andy >> > > Andy > > >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 02:03:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA49D1A03A8; Fri, 23 Jan 2015 02:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5JK4jkdBvt6; Fri, 23 Jan 2015 02:03:26 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE91A0277; Fri, 23 Jan 2015 02:03:26 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4800E187E26; Fri, 23 Jan 2015 02:03:01 -0800 (PST) To: mbj@tail-f.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150123100301.4800E187E26@rfc-editor.org> Date: Fri, 23 Jan 2015 02:03:01 -0800 (PST) Archived-At: Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Errata Verified] RFC7407 (4240) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:03:28 -0000 The following errata report has been verified for RFC7407, "A YANG Data Model for SNMP Configuration". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7407&eid=4240 -------------------------------------- Status: Verified Type: Technical Reported by: Martin Björklund Date Reported: 2015-01-23 Verified by: Benoit Claise (IESG) Section: 4.8 Original Text ------------- augment /snmp:snmp/snmp:target { when "snmp:v1 or snmp:v2c"; Corrected Text -------------- augment /snmp:snmp/snmp:target { Notes ----- The nodes refered to in the "when" expression do not exist. (They were there in an early draft version, but when they were moved, we forgot to fix the "when" expression). -------------------------------------- RFC7407 (draft-ietf-netmod-snmp-cfg-08) -------------------------------------- Title : A YANG Data Model for SNMP Configuration Publication Date : December 2014 Author(s) : M. Bjorklund, J. Schoenwaelder Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Jan 23 02:14:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976CA1A044D for ; Fri, 23 Jan 2015 02:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCY0Lpn2kPlV for ; Fri, 23 Jan 2015 02:14:08 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 52A011A03A2 for ; Fri, 23 Jan 2015 02:14:08 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DD9881CC05F5; Fri, 23 Jan 2015 11:14:10 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Andy Bierman In-Reply-To: <20150123075651.GA37850@elstar.local> References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> <20150123075651.GA37850@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 23 Jan 2015 11:14:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:14:10 -0000 Juergen Schoenwaelder writes: > On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: >> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >> > wrote: >> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >> >>> Hi, >> >>> >> >>> Juergen Schoenwaelder wrote: >> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. >> >>> >> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') >> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as >> >>> 'anydata' with the constraint that it only can hande top-level nodes. >> >>> >> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml >> >>> with non-top-level nodes. It would not be possible to use 'root' in >> >>> this case. 'anydata' would be a better match. >> >>> >> >> >> >> Andy, >> >> >> >> can you please respond to this since you created Y34-04? I now hear >> >> two people in favour of Y34-02 and we had this back in July 2014: >> >> >> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out >> >> a concrete proposal. >> >> >> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional >> >> text (the three list items) or (ii) additional restrictions of "root" >> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known >> >> to everybody.) >> >> >> > >> > >> > There are corner cases like YANG Patch edit value that need to be >> > anyxml. >> > >> >> Would adoption of Y34-02 with the additional text (the three list >> >> items) of Y34-04 be a workable solution? >> >> >> >> >> The discussion in the last VI meeting seemed to favor this solution >> but there is still this issue of JSON -> XML -> JSON round-trip >> conversion of anydata (unstructured data). >> >> IMO the loss of JSON typing through the XML conversion >> is not an issue because the only schema that matters is >> the YANG anydata. E.g., booleans and numbers are >> just strings. null is not supported. All simple nodes are >> strings. There are no keys so there are no real arrays. >> The server may return multiple containers that could >> have been encoded as an array. >> > > Yes, the JSON I-D must be updated to define how anydata is encoded. > > In general, I believe a JSON receiver must be able to do conversions > if needed, that is, if the JSON type does not match the type of the > YANG data model, the receiver must convert as needed instead of > throwing an error. I believe the YANG type is authoritative, not the > type used in the encoding. Lada may not like this but since the two Well, I fully agree that YANG types should be authoritative but, strangely enough, it leads me to a completely different conclusion: If a leaf is defined as uint8, and both parties are supposed to know that, why should the sender want to encode it as string? > type systems do not align 1:1, I think giving the YANG type system > authority is the way to go. And the principle "the receiver converts > as needed" instead of throwing an error follows the Postel principle. If Postel principle is so great, why don't we allow 42.0 as a valid value of uint8? Why don't we allow "001.002.003.004" as a valid IPv4 address? Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 03:56:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932161A90A1 for ; Fri, 23 Jan 2015 03:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYWcJYEf3xwG for ; Fri, 23 Jan 2015 03:56:05 -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 D5CEC1A9097 for ; Fri, 23 Jan 2015 03:56:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AB02AC3C for ; Fri, 23 Jan 2015 12:56:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id noWGBWzX38ic for ; Fri, 23 Jan 2015 12:55:37 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 23 Jan 2015 12:56:03 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B7EB20036 for ; Fri, 23 Jan 2015 12:56:03 +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 sG8hH6BRBaX8; Fri, 23 Jan 2015 12:48:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09A8D20035; Fri, 23 Jan 2015 12:56:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7FB8F30E53E3; Fri, 23 Jan 2015 12:56:01 +0100 (CET) Date: Fri, 23 Jan 2015 12:56:00 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150123115600.GA39304@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] yang nested list reference question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 11:56:07 -0000 Hi, lets say I have a list 'a' (keyed by n) with a nested list 'b' (keyed by m): list a { key n; leaf n; list b { key m; leaf m; } } I now want to refer to a list element of list 'b' within list 'a'. What is the best way to express this? I could do this: list c { key x; leaf x; leaf aref { type leafref { path /a/n; } } leaf bref { type leafref { path /a/b/m; } } } What is the best way to constrain the leafrefs so that they are forced to point to a 'b' within an 'a' element? Alternatively, I could consider using an instance-identifier: list c { key x; leaf x; leaf bref { type instance-identifier; } } What is the best way to restrict the instance-identifier so that it has to point to a 'b' element? Are there other approaches? I think this is a rather common modeling problem and perhaps we can come up with a best practice pattern for this? If so, I am happy to add it to my pattern collection I-D. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 23 04:04:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAE11A9094 for ; Fri, 23 Jan 2015 04:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU3C1C7aIjIk for ; Fri, 23 Jan 2015 04:04:02 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 1A31A1A19FA for ; Fri, 23 Jan 2015 04:04:02 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u10so6611305lbd.12 for ; Fri, 23 Jan 2015 04:04:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YttvS5Nfr7bas5qLYLXrMCIGQre60fcMLVb+S5VofDY=; b=iEHFFvMIuZTX0Nhoc73WYat6We4r2JyCOIlvoX028oRizEYQxFHWC3OsSFNsNyHzrn BQwekty5Ox1KTzflV800KjVb31Eqi0O0jKjI8lCRtSTx3lPrlRaId5egBcwrQWV+aUQc 7aOea/4uQANtPr9UC8S937qKxH9h1zveP9dFeNqmFRT/shK9yRg7Tj+v1fUB7HtmA0jh q7WAZ4mke7NLDCPkF8ZL3Lz9rDh0xTBiJpsTikQoiKvR68ynOpl4pKdzGcyPOc7Pmmuf MqL6cWjqpe4bAdIthTM9VQZdrP3Av4d2ljx5UQjEqhyVRYD/NAO5UdLd+TwAkBW6IHuZ BFQQ== X-Gm-Message-State: ALoCoQkFEBCRnMGsoG+U9Dnc76hdtoJPdA6Lq77vlrguQjNRXBDQ/hx6vORMRsQPeoIt8+aKC3nT MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr6921553lab.1.1422014640517; Fri, 23 Jan 2015 04:04:00 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 04:04:00 -0800 (PST) In-Reply-To: References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> <20150123075651.GA37850@elstar.local> Date: Fri, 23 Jan 2015 04:04:00 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:04:04 -0000 On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > >> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: >>> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >>> > wrote: >>> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >>> >>> Hi, >>> >>> >>> >>> Juergen Schoenwaelder wrote: >>> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. >>> >>> >>> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >>> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') >>> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as >>> >>> 'anydata' with the constraint that it only can hande top-level nodes. >>> >>> >>> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml >>> >>> with non-top-level nodes. It would not be possible to use 'root' in >>> >>> this case. 'anydata' would be a better match. >>> >>> >>> >> >>> >> Andy, >>> >> >>> >> can you please respond to this since you created Y34-04? I now hear >>> >> two people in favour of Y34-02 and we had this back in July 2014: >>> >> >>> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out >>> >> a concrete proposal. >>> >> >>> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional >>> >> text (the three list items) or (ii) additional restrictions of "root" >>> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known >>> >> to everybody.) >>> >> >>> > >>> > >>> > There are corner cases like YANG Patch edit value that need to be >>> > anyxml. >>> > >>> >> Would adoption of Y34-02 with the additional text (the three list >>> >> items) of Y34-04 be a workable solution? >>> >> >>> >>> >>> The discussion in the last VI meeting seemed to favor this solution >>> but there is still this issue of JSON -> XML -> JSON round-trip >>> conversion of anydata (unstructured data). >>> >>> IMO the loss of JSON typing through the XML conversion >>> is not an issue because the only schema that matters is >>> the YANG anydata. E.g., booleans and numbers are >>> just strings. null is not supported. All simple nodes are >>> strings. There are no keys so there are no real arrays. >>> The server may return multiple containers that could >>> have been encoded as an array. >>> >> >> Yes, the JSON I-D must be updated to define how anydata is encoded. >> >> In general, I believe a JSON receiver must be able to do conversions >> if needed, that is, if the JSON type does not match the type of the >> YANG data model, the receiver must convert as needed instead of >> throwing an error. I believe the YANG type is authoritative, not the >> type used in the encoding. Lada may not like this but since the two > > Well, I fully agree that YANG types should be authoritative but, > strangely enough, it leads me to a completely different conclusion: If a > leaf is defined as uint8, and both parties are supposed to know that, > why should the sender want to encode it as string? > Because we are talking about anyxml, not uint8. The entire point of anyxml is that is carries absolultely no YANG schema information whatsoever. The peer parsing the node has no way to associate uint8 with any sub-node of the anyxml blob. >> type systems do not align 1:1, I think giving the YANG type system >> authority is the way to go. And the principle "the receiver converts >> as needed" instead of throwing an error follows the Postel principle. > > If Postel principle is so great, why don't we allow 42.0 as a valid > value of uint8? Why don't we allow "001.002.003.004" as a valid IPv4 > address? > > Lada > Andy >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Fri Jan 23 04:06:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4BC1A909B for ; Fri, 23 Jan 2015 04:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4z_NmewsGYm for ; Fri, 23 Jan 2015 04:06:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E26F31A19FA for ; Fri, 23 Jan 2015 04:06:49 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id F218D1280052; Fri, 23 Jan 2015 13:06:48 +0100 (CET) Date: Fri, 23 Jan 2015 13:06:48 +0100 (CET) Message-Id: <20150123.130648.1464345748997979172.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150123115600.GA39304@elstar.local> References: <20150123115600.GA39304@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang nested list reference question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:06:52 -0000 Juergen Schoenwaelder wrote: > Hi, > > lets say I have a list 'a' (keyed by n) with a nested list 'b' (keyed > by m): > > list a { > key n; > leaf n; > > list b { > key m; > leaf m; > } > } > > I now want to refer to a list element of list 'b' within list 'a'. > What is the best way to express this? > > I could do this: > > list c { > key x; > leaf x; > > leaf aref { type leafref { path /a/n; } } > leaf bref { type leafref { path /a/b/m; } } > } > > What is the best way to constrain the leafrefs so that they are > forced to point to a 'b' within an 'a' element? leaf bref { type leafref { path "/a[n = current()/../aref]/b/m"; } } Note that this special syntax with current() is allowed by a leafref; and the reason is to handle this common use case. See RFC 6020, section 9.9.5. With a third key (and more), this syntax still works, but gets clumsy. This is why I have suggested to use: path "deref(../aref)/../b/m"; as an optional syntax to leafref path. /martin From nobody Fri Jan 23 04:08:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171D41A909B for ; Fri, 23 Jan 2015 04:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inOdA7LMU8SH for ; Fri, 23 Jan 2015 04:08:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DD0A21A19FA for ; Fri, 23 Jan 2015 04:08:14 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 24CE61280052; Fri, 23 Jan 2015 13:08:14 +0100 (CET) Date: Fri, 23 Jan 2015 13:08:14 +0100 (CET) Message-Id: <20150123.130814.797514719780233079.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150123075651.GA37850@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:08:20 -0000 Andy Bierman wrote: > On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka wrote: > > Juergen Schoenwaelder writes: > > > >> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: > >>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: > >>> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder > >>> > wrote: > >>> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: > >>> >>> Hi, > >>> >>> > >>> >>> Juergen Schoenwaelder wrote: > >>> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. > >>> >>> > >>> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add > >>> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') > >>> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as > >>> >>> 'anydata' with the constraint that it only can hande top-level nodes. > >>> >>> > >>> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml > >>> >>> with non-top-level nodes. It would not be possible to use 'root' in > >>> >>> this case. 'anydata' would be a better match. > >>> >>> > >>> >> > >>> >> Andy, > >>> >> > >>> >> can you please respond to this since you created Y34-04? I now hear > >>> >> two people in favour of Y34-02 and we had this back in July 2014: > >>> >> > >>> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out > >>> >> a concrete proposal. > >>> >> > >>> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional > >>> >> text (the three list items) or (ii) additional restrictions of "root" > >>> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known > >>> >> to everybody.) > >>> >> > >>> > > >>> > > >>> > There are corner cases like YANG Patch edit value that need to be > >>> > anyxml. > >>> > > >>> >> Would adoption of Y34-02 with the additional text (the three list > >>> >> items) of Y34-04 be a workable solution? > >>> >> > >>> > >>> > >>> The discussion in the last VI meeting seemed to favor this solution > >>> but there is still this issue of JSON -> XML -> JSON round-trip > >>> conversion of anydata (unstructured data). > >>> > >>> IMO the loss of JSON typing through the XML conversion > >>> is not an issue because the only schema that matters is > >>> the YANG anydata. E.g., booleans and numbers are > >>> just strings. null is not supported. All simple nodes are > >>> strings. There are no keys so there are no real arrays. > >>> The server may return multiple containers that could > >>> have been encoded as an array. > >>> > >> > >> Yes, the JSON I-D must be updated to define how anydata is encoded. > >> > >> In general, I believe a JSON receiver must be able to do conversions > >> if needed, that is, if the JSON type does not match the type of the > >> YANG data model, the receiver must convert as needed instead of > >> throwing an error. I believe the YANG type is authoritative, not the > >> type used in the encoding. Lada may not like this but since the two > > > > Well, I fully agree that YANG types should be authoritative but, > > strangely enough, it leads me to a completely different conclusion: If a > > leaf is defined as uint8, and both parties are supposed to know that, > > why should the sender want to encode it as string? > > > > Because we are talking about anyxml, not uint8. > The entire point of anyxml is that is carries absolultely > no YANG schema information whatsoever. > The peer parsing the node has no way to associate > uint8 with any sub-node of the anyxml blob. In the generic case this is true. But for example in YANG PATCH, the target node is known from the context, so the anydata blob can/will be parsed according to the schema. /martin From nobody Fri Jan 23 04:11:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10051A90A2; Fri, 23 Jan 2015 04:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEXcHZD9arJG; Fri, 23 Jan 2015 04:10:56 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 113911A90A3; Fri, 23 Jan 2015 04:10:55 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.173.248.22; Date: Fri, 23 Jan 2015 07:13:19 -0500 Message-ID: Importance: normal From: Sue Hares To: Benoit Claise , NETCONF , netmod@ietf.org, Rtg-yang-coord@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_679818315222450" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Joel Jaeggli Subject: Re: [netmod] IDR Interim on 1/26/2015 10-11:00am ET - Topic BGP Yang Data Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:11:03 -0000 ----_com.android.email_679818315222450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB3aWxsIHJlY29yZCB0aGUgbWVldGluZy4gwqBTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBH QUxBWFkgU8KuNCwgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9uZQoKPGRpdj4tLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBCZW5vaXQgQ2xhaXNlIDxiY2xh aXNlQGNpc2NvLmNvbT4gPC9kaXY+PGRpdj5EYXRlOjAxLzIzLzIwMTUgIDM6MjEgQU0gIChHTVQt MDU6MDApIDwvZGl2PjxkaXY+VG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+LE5FVENP TkYgPG5ldGNvbmZAaWV0Zi5vcmc+LG5ldG1vZEBpZXRmLm9yZyxSdGcteWFuZy1jb29yZEBpZXRm Lm9yZyA8L2Rpdj48ZGl2PkNjOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4sSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPiA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBJRFIgSW50ZXJp bSBvbiAxLzI2LzIwMTUgMTAtMTE6MDBhbSBFVCAtIFRvcGljIEJHUCBZYW5nIERhdGEgTW9kdWxl cyA8L2Rpdj48ZGl2Pgo8L2Rpdj5IaSBTdWUsCgpUaGFua3MgZm9yIGZvcndhcmRpbmcuCkkgd2ls bCBiZSBpbiBhIHBsYW5lIGF0IHRoYXQgdGltZS4KV291bGQgeW91IG1pbmQgcmVjb3JkaW5nIHRo ZSBtZWV0aW5nLgoKUmVnYXJkcywgQmVub2l0CkNyb3NzLXBvc3Rpbmcgb2YgYSBEaXNjdXNzaW9u IG9mIEJHUCBZYW5nIERhdGEgTW9kdWxlcyB0byB5YW5nIGRhdGEgbW9kdWxlcy4KIApJRFIgSW50 ZXJpbSAyIChCR1AgWWFuZyBNb2R1bGVzKQpNb25kYXksIEphbnVhcnkgMjYsIDIwMTUKMTAtMDAg 4oCTIDExOjMwIGFtICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQtMDU6 MDApICB8IDEuNSBob3VycwogCkFnZW5kYToKMSkgQWdlbmRhIEJhc2hpbmcgKFN1ZSBIYXJlcykg LSA1IG1pbnV0ZXMKMikgT3BlbkNvbmZpZyBCR1AgWWFuZyBEYXRhIE1vZGVsICAoQW5lZXMgU2hh aWtoKSAtIDI1IG1pbnV0ZXMKMykgVXBkYXRlIG9uIGRyYWZ0LXpoZGFua2luLW5ldG1vZC1iZ3At Y2ZnIChUQkQpICAtIDEwIG1pbnV0ZXMKNCkgRGlzY3Vzc2lvbiBvZiBUd28gWWFuZyBEYXRhIE1v ZGVsIC0gMjAgbWludXRlcyAgCiAKRG9jdW1lbnRzIG9yIGNvZGUgdG8gcmVhZCBmb3IgdGhlIG1l ZXRpbmc6CiAKaHR0cHM6Ly9naXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy90cmVlL21hc3Rlci9l eHBlcmltZW50YWwvb3BlbmNvbmZpZwpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGRhbmtpbi1uZXRtb2QtYmdwLWNmZy0wMQogClNsaWRlcyBmb3IgdGhlIGludGVyaW0gYXJlIGF0 OiAgIAogCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzAxLzI2 L2lkci9wcm9jZWVkaW5ncy5odG1sCiAKU3VlIEhhcmVzCiAKV2ViZXggaW5mbzoKaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTAyMjE5NTZkYWFjMDYzOTkzMTk1NWU4ZTZl ZWYyMDZkCiAKIApNZWV0aW5nIG51bWJlcjogICAgICAgICAgICA2NDUgNjkwIDk4OQpNZWV0aW5n IHBhc3N3b3JkOiAgICAgICAgIHlhbmdpc2Z1bgogCkpvaW4gYnkgcGhvbmUKMS04NzctNjY4LTQ0 OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpCjEtNjUwLTQ3OS0zMjA4IENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0NSA2OTAgOTg5CiAK IAoK ----_com.android.email_679818315222450 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5JIHdpbGwgcmVjb3JkIHRo ZSBtZWV0aW5nLiAmbmJzcDtTdWU8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo5cHg7Y29sb3I6IzU3NTc1NyI+U2VudCB2aWEgdGhl IFNhbXN1bmcgR0FMQVhZIFPCrjQsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+ PC9kaXY+PGJyPjxicj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rp dj48ZGl2PkZyb206IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiA8L2Rpdj48ZGl2 PkRhdGU6MDEvMjMvMjAxNSAgMzoyMSBBTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogU3Vz YW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4sTkVUQ09ORiA8bmV0Y29uZkBpZXRmLm9yZz4sbmV0 bW9kQGlldGYub3JnLFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIDwvZGl2PjxkaXY+Q2M6IFFpbiBX dSA8YmlsbC53dUBodWF3ZWkuY29tPixKb2VsIEphZWdnbGkgPGpvZWxqYUBib2d1cy5jb20+IDwv ZGl2PjxkaXY+U3ViamVjdDogUmU6IElEUiBJbnRlcmltIG9uIDEvMjYvMjAxNSAxMC0xMTowMGFt IEVUIC0gVG9waWMgQkdQIFlhbmcgRGF0YSBNb2R1bGVzIDwvZGl2PjxkaXY+PGJyPjwvZGl2Pgog ICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5IaSBTdWUsPGJyPgogICAgICA8YnI+CiAg ICAgIFRoYW5rcyBmb3IgZm9yd2FyZGluZy48YnI+CiAgICAgIEkgd2lsbCBiZSBpbiBhIHBsYW5l IGF0IHRoYXQgdGltZS48YnI+CiAgICAgIFdvdWxkIHlvdSBtaW5kIHJlY29yZGluZyB0aGUgbWVl dGluZy48YnI+CiAgICAgIDxicj4KICAgICAgUmVnYXJkcywgQmVub2l0PGJyPgogICAgPC9kaXY+ CiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6MDMwYjAxZDAzNmE5JDE0ZjNjZjgwJDNlZGI2ZTgw JEBuZHpoLmNvbSIgdHlwZT0iY2l0ZSI+CiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOwogICAgICAgIGNoYXJzZXQ9d2luZG93cy0xMjUyIj4K ICAgICAgPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAo ZmlsdGVyZWQKICAgICAgICBtZWRpdW0pIj4KICAgICAgPHN0eWxlPjwhLS0KLyogRm9udCBEZWZp bml0aW9ucyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7CglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZh bWlseTpUYWhvbWE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9Ci8qIFN0eWxlIERl ZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXtt YXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30Kc3Bhbi5FbWFpbFN0eWxlMTcKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsKCWNvbG9yOndpbmRvd3RleHQ7 fQouTXNvQ2hwRGVmYXVsdAoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6OC41 aW4gMTEuMGluOwoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30KZGl2LldvcmRTZWN0 aW9uMQoJe3BhZ2U6V29yZFNlY3Rpb24xO30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4KICAgICAgPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4K ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Q3Jvc3MtcG9zdGluZwogICAgICAgICAgICAgIG9mIGEgRGlzY3Vzc2lvbiBvZiBCR1AgWWFu ZyBEYXRhIE1vZHVsZXMgdG8geWFuZyBkYXRhCiAgICAgICAgICAgICAgbW9kdWxlcy4gPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5JRFIgSW50ZXJp bSAyIChCR1AgWWFuZyBNb2R1bGVzKSA8bzpwPjwvbzpwPjwvYj48L3A+CiAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+TW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDxvOnA+PC9vOnA+PC9wPgog ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjEwLTAwIOKAkyAxMTozMCBhbSZuYnNwOyB8Jm5i c3A7IEVhc3Rlcm4gU3RhbmRhcmQgVGltZQogICAgICAgICAgKE5ldyBZb3JrLCBHTVQtMDU6MDAp Jm5ic3A7IHwgMS41IGhvdXJzIDxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkFnZW5kYTogPG86cD48L286cD48L2I+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjEpIEFnZW5kYSBCYXNoaW5nIChTdWUgSGFyZXMpIC0gNSBtaW51dGVzPG86cD48L286cD48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgT3BlbkNvbmZpZyBCR1AgWWFuZyBE YXRhIE1vZGVsICZuYnNwOyhBbmVlcwogICAgICAgICAgU2hhaWtoKSAtIDI1IG1pbnV0ZXM8bzpw PjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBVcGRhdGUgb24gZHJh ZnQtemhkYW5raW4tbmV0bW9kLWJncC1jZmcKICAgICAgICAgIChUQkQpICZuYnNwOy0gMTAgbWlu dXRlcyA8bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSBEaXNj dXNzaW9uIG9mIFR3byBZYW5nIERhdGEgTW9kZWwgLSAyMAogICAgICAgICAgbWludXRlcyAmbmJz cDs8bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Eb2N1bWVudHMgb3Ig Y29kZSB0byByZWFkIGZvciB0aGUKICAgICAgICAgICAgbWVldGluZzo8bzpwPjwvbzpwPjwvYj48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vWWFuZ01vZGVscy95YW5nL3RyZWUvbWFzdGVyL2V4cGVyaW1l bnRhbC9vcGVuY29uZmlnIj5odHRwczovL2dpdGh1Yi5jb20vWWFuZ01vZGVscy95YW5nL3RyZWUv bWFzdGVyL2V4cGVyaW1lbnRhbC9vcGVuY29uZmlnPC9hPjxvOnA+PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhkYW5raW4tbmV0bW9kLWJncC1jZmctMDEi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZGFua2luLW5ldG1vZC1iZ3AtY2Zn LTAxPC9hPjxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5TbGlkZXMgZm9yCiAgICAgICAgICAgICAgdGhlIGludGVyaW0g YXJlIGF0OiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPgogICAgICAgIDxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMDEvMjYvaWRyL3Byb2NlZWRp bmdzLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzAx LzI2L2lkci9wcm9jZWVkaW5ncy5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdWUgSGFyZXMgPG86cD48L286cD48L3NwYW4+PC9wPgog ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPldlYmV4IGluZm86IDxvOnA+PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTAyMjE5NTZkYWFjMDYzOTkzMTk1 NWU4ZTZlZWYyMDZkIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMDIy MTk1NmRhYWMwNjM5OTMxOTU1ZThlNmVlZjIwNmQ8L2E+PG86cD48L286cD48L3A+CiAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+TWVldGluZyBudW1iZXI6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2NDUgNjkwIDk4OSA8bzpwPjwvbzpwPjwvcD4K ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWV0aW5nIHBhc3N3b3JkOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB5YW5naXNmdW48bzpwPjwvbzpw PjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4K ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2luIGJ5IHBob25lPG86cD48L286cD48L3A+ CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xs IGZyZWUgbnVtYmVyCiAgICAgICAgICAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIK ICAgICAgICAgIChVUy9DYW5hZGEpPG86cD48L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWNjZXNzIGNvZGU6IDY0NSA2OTAgOTg5PG86cD48L286cD48L3A+CiAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgIDwvZGl2PgogICAgPC9i bG9ja3F1b3RlPgogICAgPGJyPgogIAoKPC9ib2R5Pg== ----_com.android.email_679818315222450-- From nobody Fri Jan 23 04:12:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AEC1A90A3 for ; Fri, 23 Jan 2015 04:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_1PdLiLLgDs for ; Fri, 23 Jan 2015 04:12:11 -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 D0C3B1A90A2 for ; Fri, 23 Jan 2015 04:12:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A40A4F88; Fri, 23 Jan 2015 13:12:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Z-jqIYFkXimX; Fri, 23 Jan 2015 13:11:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Jan 2015 13:12:08 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7246520036; Fri, 23 Jan 2015 13:12:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id elbzg6b3hHL6; Fri, 23 Jan 2015 13:12:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADAE020035; Fri, 23 Jan 2015 13:12:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 48D4F30E54F1; Fri, 23 Jan 2015 13:12:05 +0100 (CET) Date: Fri, 23 Jan 2015 13:12:04 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150123121204.GA39438@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> <20150123075651.GA37850@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:12:12 -0000 On Fri, Jan 23, 2015 at 11:14:07AM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: > >> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: > >> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder > >> > wrote: > >> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: > >> >>> Hi, > >> >>> > >> >>> Juergen Schoenwaelder wrote: > >> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. > >> >>> > >> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add > >> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') > >> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as > >> >>> 'anydata' with the constraint that it only can hande top-level nodes. > >> >>> > >> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml > >> >>> with non-top-level nodes. It would not be possible to use 'root' in > >> >>> this case. 'anydata' would be a better match. > >> >>> > >> >> > >> >> Andy, > >> >> > >> >> can you please respond to this since you created Y34-04? I now hear > >> >> two people in favour of Y34-02 and we had this back in July 2014: > >> >> > >> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out > >> >> a concrete proposal. > >> >> > >> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional > >> >> text (the three list items) or (ii) additional restrictions of "root" > >> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known > >> >> to everybody.) > >> >> > >> > > >> > > >> > There are corner cases like YANG Patch edit value that need to be > >> > anyxml. > >> > > >> >> Would adoption of Y34-02 with the additional text (the three list > >> >> items) of Y34-04 be a workable solution? > >> >> > >> > >> > >> The discussion in the last VI meeting seemed to favor this solution > >> but there is still this issue of JSON -> XML -> JSON round-trip > >> conversion of anydata (unstructured data). > >> > >> IMO the loss of JSON typing through the XML conversion > >> is not an issue because the only schema that matters is > >> the YANG anydata. E.g., booleans and numbers are > >> just strings. null is not supported. All simple nodes are > >> strings. There are no keys so there are no real arrays. > >> The server may return multiple containers that could > >> have been encoded as an array. > >> > > > > Yes, the JSON I-D must be updated to define how anydata is encoded. > > > > In general, I believe a JSON receiver must be able to do conversions > > if needed, that is, if the JSON type does not match the type of the > > YANG data model, the receiver must convert as needed instead of > > throwing an error. I believe the YANG type is authoritative, not the > > type used in the encoding. Lada may not like this but since the two > > Well, I fully agree that YANG types should be authoritative but, > strangely enough, it leads me to a completely different conclusion: If a > leaf is defined as uint8, and both parties are supposed to know that, > why should the sender want to encode it as string? a) In the context of anydata, the sender may simply not have the type information. b) In other contexts, there might be translators involved or encoding layers that have not access to the type information. And there is always conversion since we will send 64-bit ints as strings etc. The JSON type in the encoding simply is not authoritative and dropping messages because someone did send 5 instead of "5" or "False" instead of False in JSON seems counter productive if our goal is interoperability. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 23 04:14:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9575D1A90A7 for ; Fri, 23 Jan 2015 04:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsABF_7U5nUA for ; Fri, 23 Jan 2015 04:14:39 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CEB1A90A9 for ; Fri, 23 Jan 2015 04:14:38 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so6919565lab.12 for ; Fri, 23 Jan 2015 04:14:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/A4cHvdDs4LQtwAfecZa1y003H6HmMpM0QhF67j+vFA=; b=OEgeLdFDSZXsj0Hvm4sPA4bZwGvkBSQV7vMSGmlJoCoXHO0aHj76Uaa+l/znyFFI8s +G93BhsvXdpoZDBTivOUOkWg0fUH7N+vU0KfU8e/YNNFnC59zIub1JM0otZyIowimoAK ckq0l+7kGtnkWTXQKZGSCUXe7NUI3nuUI4P+ihBaWl/WiKSxiES9ylfOJREp1OROh9rq Pu9OgWiHr3w96xiS2QjQ7pmcbeTA0Vlere11H/d/KtlixcwmSpEvBUrvQVfL8/7W/Ec5 p1mzz8FZvdlta1kqI4PCDLaLdIlZrzsb+UWFE0G0HdJCoZIbsGDVhYEhmHnlqZ5/o3/O nDdA== X-Gm-Message-State: ALoCoQnMvbQtzlMk+3Ryvs+PeHHrwMpCAvmfjb42RmiVFvCVg2mEG6ddY4SIZbKhvQ0krbpPP6di MIME-Version: 1.0 X-Received: by 10.152.42.164 with SMTP id p4mr6965623lal.45.1422015277472; Fri, 23 Jan 2015 04:14:37 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 04:14:37 -0800 (PST) In-Reply-To: <20150123.130814.797514719780233079.mbj@tail-f.com> References: <20150123075651.GA37850@elstar.local> <20150123.130814.797514719780233079.mbj@tail-f.com> Date: Fri, 23 Jan 2015 04:14:37 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:14:40 -0000 On Fri, Jan 23, 2015 at 4:08 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka wrote: >> > Juergen Schoenwaelder writes: >> > >> >> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >> >>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: >> >>> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >> >>> > wrote: >> >>> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >> >>> >>> Hi, >> >>> >>> >> >>> >>> Juergen Schoenwaelder wrote: >> >>> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. >> >>> >>> >> >>> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >> >>> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') >> >>> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as >> >>> >>> 'anydata' with the constraint that it only can hande top-level nodes. >> >>> >>> >> >>> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml >> >>> >>> with non-top-level nodes. It would not be possible to use 'root' in >> >>> >>> this case. 'anydata' would be a better match. >> >>> >>> >> >>> >> >> >>> >> Andy, >> >>> >> >> >>> >> can you please respond to this since you created Y34-04? I now hear >> >>> >> two people in favour of Y34-02 and we had this back in July 2014: >> >>> >> >> >>> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out >> >>> >> a concrete proposal. >> >>> >> >> >>> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional >> >>> >> text (the three list items) or (ii) additional restrictions of "root" >> >>> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known >> >>> >> to everybody.) >> >>> >> >> >>> > >> >>> > >> >>> > There are corner cases like YANG Patch edit value that need to be >> >>> > anyxml. >> >>> > >> >>> >> Would adoption of Y34-02 with the additional text (the three list >> >>> >> items) of Y34-04 be a workable solution? >> >>> >> >> >>> >> >>> >> >>> The discussion in the last VI meeting seemed to favor this solution >> >>> but there is still this issue of JSON -> XML -> JSON round-trip >> >>> conversion of anydata (unstructured data). >> >>> >> >>> IMO the loss of JSON typing through the XML conversion >> >>> is not an issue because the only schema that matters is >> >>> the YANG anydata. E.g., booleans and numbers are >> >>> just strings. null is not supported. All simple nodes are >> >>> strings. There are no keys so there are no real arrays. >> >>> The server may return multiple containers that could >> >>> have been encoded as an array. >> >>> >> >> >> >> Yes, the JSON I-D must be updated to define how anydata is encoded. >> >> >> >> In general, I believe a JSON receiver must be able to do conversions >> >> if needed, that is, if the JSON type does not match the type of the >> >> YANG data model, the receiver must convert as needed instead of >> >> throwing an error. I believe the YANG type is authoritative, not the >> >> type used in the encoding. Lada may not like this but since the two >> > >> > Well, I fully agree that YANG types should be authoritative but, >> > strangely enough, it leads me to a completely different conclusion: If a >> > leaf is defined as uint8, and both parties are supposed to know that, >> > why should the sender want to encode it as string? >> > >> >> Because we are talking about anyxml, not uint8. >> The entire point of anyxml is that is carries absolultely >> no YANG schema information whatsoever. >> The peer parsing the node has no way to associate >> uint8 with any sub-node of the anyxml blob. > > In the generic case this is true. > > But for example in YANG PATCH, the target node is known from the > context, so the anydata blob can/will be parsed according to the > schema. > This is a corner-case full of implementation details. e.g., all the data can be passed before all the resource offsets that identify the schema. There is nothing except description-stmt text to associate the target leaf with the anyxml blob. Not sure how an off-the-shelf tool could ever implement YANG Patch correctly. > > /martin Andy From nobody Fri Jan 23 04:17:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0383E1A90A3 for ; Fri, 23 Jan 2015 04:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJpCMi74yo-B for ; Fri, 23 Jan 2015 04:17:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7991A909D for ; Fri, 23 Jan 2015 04:17:13 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4b0:625d:f229:d528] (unknown [IPv6:2001:718:1a02:1:4b0:625d:f229:d528]) by mail.nic.cz (Postfix) with ESMTPSA id 2F66D13F744; Fri, 23 Jan 2015 13:17:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422015432; bh=RQJliitljMWOD6SKcEYRpfMQ8OBsc1Bdze9wdD82/3g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MyEE25MdaAw4Fj/GRGrFdWOXe3Ft/9z+MdTRCw3psHM/pM9lv6GG7xRj3D1SfO6nN zn5BT0GspvuTpRVESW9qSr4e38/vcX67K9sEImpSp5PWUlu8jUQ/qiqxCcLJxPwDPQ zKg/9bnP82zntm1jZlgHM4JTL8I+/MNo/zsPpE9A= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 23 Jan 2015 13:17:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74E92BD2-0787-4AD2-B43D-D0D98EBE9135@nic.cz> References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> <20150123075651.GA37850@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:17:16 -0000 > On 23 Jan 2015, at 13:04, Andy Bierman wrote: >=20 > On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka = wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >>>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman = wrote: >>>>> On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >>>>> wrote: >>>>>> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> Juergen Schoenwaelder = wrote: >>>>>>>> The 2014-12-03 virtual interim meeting proposal is to adopt = Y34-04. >>>>>>>=20 >>>>>>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >>>>>>> 'root) correctly, the difference between it and Y34-02 (add = 'anydata') >>>>>>> is that 'root' is a special case of 'anydata'; i.e., 'root' = behaves as >>>>>>> 'anydata' with the constraint that it only can hande top-level = nodes. >>>>>>>=20 >>>>>>> As an example of why this is not sufficient, YANG PATCH uses = anyxml >>>>>>> with non-top-level nodes. It would not be possible to use = 'root' in >>>>>>> this case. 'anydata' would be a better match. >>>>>>>=20 >>>>>>=20 >>>>>> Andy, >>>>>>=20 >>>>>> can you please respond to this since you created Y34-04? I now = hear >>>>>> two people in favour of Y34-02 and we had this back in July 2014: >>>>>>=20 >>>>>> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to = work out >>>>>> a concrete proposal. >>>>>>=20 >>>>>> So is the main delta of Y34-04 compared to Y34-02 (i) the = additional >>>>>> text (the three list items) or (ii) additional restrictions of = "root" >>>>>> to top-level nodes. (The Y34-04 referes to ncx:root which is not = known >>>>>> to everybody.) >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> There are corner cases like YANG Patch edit value that need to be >>>>> anyxml. >>>>>=20 >>>>>> Would adoption of Y34-02 with the additional text (the three list >>>>>> items) of Y34-04 be a workable solution? >>>>>>=20 >>>>=20 >>>>=20 >>>> The discussion in the last VI meeting seemed to favor this solution >>>> but there is still this issue of JSON -> XML -> JSON round-trip >>>> conversion of anydata (unstructured data). >>>>=20 >>>> IMO the loss of JSON typing through the XML conversion >>>> is not an issue because the only schema that matters is >>>> the YANG anydata. E.g., booleans and numbers are >>>> just strings. null is not supported. All simple nodes are >>>> strings. There are no keys so there are no real arrays. >>>> The server may return multiple containers that could >>>> have been encoded as an array. >>>>=20 >>>=20 >>> Yes, the JSON I-D must be updated to define how anydata is encoded. >>>=20 >>> In general, I believe a JSON receiver must be able to do conversions >>> if needed, that is, if the JSON type does not match the type of the >>> YANG data model, the receiver must convert as needed instead of >>> throwing an error. I believe the YANG type is authoritative, not the >>> type used in the encoding. Lada may not like this but since the two >>=20 >> Well, I fully agree that YANG types should be authoritative but, >> strangely enough, it leads me to a completely different conclusion: = If a >> leaf is defined as uint8, and both parties are supposed to know that, >> why should the sender want to encode it as string? >>=20 >=20 > Because we are talking about anyxml, not uint8. Yes, but Juergen talks about YANG types, i.e. not about anyxml/anydata, = so I responded to it. > The entire point of anyxml is that is carries absolultely > no YANG schema information whatsoever. > The peer parsing the node has no way to associate > uint8 with any sub-node of the anyxml blob. The peer may have other non-YANG knowledge about the types, or not. I = agree that a client sending a JSON number must be prepared to receive it = back as string. I just don=E2=80=99t agree that only strings be allowed = in JSON encoding of anydata. Lada >=20 >=20 >>> type systems do not align 1:1, I think giving the YANG type system >>> authority is the way to go. And the principle "the receiver converts >>> as needed" instead of throwing an error follows the Postel = principle. >>=20 >> If Postel principle is so great, why don't we allow 42.0 as a valid >> value of uint8? Why don't we allow "001.002.003.004" as a valid IPv4 >> address? >>=20 >> Lada >>=20 >=20 > Andy >=20 >=20 >>>=20 >>> /js >>>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 04:22:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152A91A90B8 for ; Fri, 23 Jan 2015 04:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XqKfDLNVJ35 for ; Fri, 23 Jan 2015 04:22:19 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B58681A90BD for ; Fri, 23 Jan 2015 04:22:15 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 090851280056; Fri, 23 Jan 2015 13:22:15 +0100 (CET) Date: Fri, 23 Jan 2015 13:22:14 +0100 (CET) Message-Id: <20150123.132214.879268627000276944.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150123.130814.797514719780233079.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:22:21 -0000 Andy Bierman wrote: > On Fri, Jan 23, 2015 at 4:08 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka wrote: > >> > Juergen Schoenwaelder writes: > >> > > >> >> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: > >> >>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: > >> >>> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder > >> >>> > wrote: > >> >>> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: > >> >>> >>> Hi, > >> >>> >>> > >> >>> >>> Juergen Schoenwaelder wrote: > >> >>> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. > >> >>> >>> > >> >>> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add > >> >>> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') > >> >>> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as > >> >>> >>> 'anydata' with the constraint that it only can hande top-level nodes. > >> >>> >>> > >> >>> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml > >> >>> >>> with non-top-level nodes. It would not be possible to use 'root' in > >> >>> >>> this case. 'anydata' would be a better match. > >> >>> >>> > >> >>> >> > >> >>> >> Andy, > >> >>> >> > >> >>> >> can you please respond to this since you created Y34-04? I now hear > >> >>> >> two people in favour of Y34-02 and we had this back in July 2014: > >> >>> >> > >> >>> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out > >> >>> >> a concrete proposal. > >> >>> >> > >> >>> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional > >> >>> >> text (the three list items) or (ii) additional restrictions of "root" > >> >>> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known > >> >>> >> to everybody.) > >> >>> >> > >> >>> > > >> >>> > > >> >>> > There are corner cases like YANG Patch edit value that need to be > >> >>> > anyxml. > >> >>> > > >> >>> >> Would adoption of Y34-02 with the additional text (the three list > >> >>> >> items) of Y34-04 be a workable solution? > >> >>> >> > >> >>> > >> >>> > >> >>> The discussion in the last VI meeting seemed to favor this solution > >> >>> but there is still this issue of JSON -> XML -> JSON round-trip > >> >>> conversion of anydata (unstructured data). > >> >>> > >> >>> IMO the loss of JSON typing through the XML conversion > >> >>> is not an issue because the only schema that matters is > >> >>> the YANG anydata. E.g., booleans and numbers are > >> >>> just strings. null is not supported. All simple nodes are > >> >>> strings. There are no keys so there are no real arrays. > >> >>> The server may return multiple containers that could > >> >>> have been encoded as an array. > >> >>> > >> >> > >> >> Yes, the JSON I-D must be updated to define how anydata is encoded. > >> >> > >> >> In general, I believe a JSON receiver must be able to do conversions > >> >> if needed, that is, if the JSON type does not match the type of the > >> >> YANG data model, the receiver must convert as needed instead of > >> >> throwing an error. I believe the YANG type is authoritative, not the > >> >> type used in the encoding. Lada may not like this but since the two > >> > > >> > Well, I fully agree that YANG types should be authoritative but, > >> > strangely enough, it leads me to a completely different conclusion: If a > >> > leaf is defined as uint8, and both parties are supposed to know that, > >> > why should the sender want to encode it as string? > >> > > >> > >> Because we are talking about anyxml, not uint8. > >> The entire point of anyxml is that is carries absolultely > >> no YANG schema information whatsoever. > >> The peer parsing the node has no way to associate > >> uint8 with any sub-node of the anyxml blob. > > > > In the generic case this is true. > > > > But for example in YANG PATCH, the target node is known from the > > context, so the anydata blob can/will be parsed according to the > > schema. > > > > This is a corner-case full of implementation details. > e.g., all the data can be passed before all the resource > offsets that identify the schema. There is nothing except > description-stmt text to associate the target leaf with > the anyxml blob. Not sure how an off-the-shelf tool could > ever implement YANG Patch correctly. Agreed. But I think that this case might be pretty common - i.e., from some context the schema of the anydata blob will eventually be known. For example, we could do: list logged-notification { key id; leaf id { ... } leaf device-address { ... } // more meta-data here anydata notification; } The implementation of the logged-notification list doesn't have to know all the notifications, but a consumer that knows the schema of some or all notifications can use this info to parse the data. /martin From nobody Fri Jan 23 05:14:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1271A90AF for ; Fri, 23 Jan 2015 05:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUTYT28Mqepw for ; Fri, 23 Jan 2015 05:14:10 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAE81A90AE for ; Fri, 23 Jan 2015 05:14:10 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EA9F31CC05F5; Fri, 23 Jan 2015 14:14:11 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20150123121204.GA39438@elstar.local> References: <20150107145943.GE13482@elstar.local> <20150108.103728.1499085884469962335.mbj@tail-f.com> <20150121102144.GE32055@elstar.local> <20150123075651.GA37850@elstar.local> <20150123121204.GA39438@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 23 Jan 2015 14:14:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:14:16 -0000 Juergen Schoenwaelder writes: > On Fri, Jan 23, 2015 at 11:14:07AM +0100, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >> >> > On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >> >> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman wrote: >> >> > On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >> >> > wrote: >> >> >> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wrote: >> >> >>> Hi, >> >> >>> >> >> >>> Juergen Schoenwaelder wrote: >> >> >>> > The 2014-12-03 virtual interim meeting proposal is to adopt Y34-04. >> >> >>> >> >> >>> I don't think Y34-04 is sufficient. If I understand Y34-04 (add >> >> >>> 'root) correctly, the difference between it and Y34-02 (add 'anydata') >> >> >>> is that 'root' is a special case of 'anydata'; i.e., 'root' behaves as >> >> >>> 'anydata' with the constraint that it only can hande top-level nodes. >> >> >>> >> >> >>> As an example of why this is not sufficient, YANG PATCH uses anyxml >> >> >>> with non-top-level nodes. It would not be possible to use 'root' in >> >> >>> this case. 'anydata' would be a better match. >> >> >>> >> >> >> >> >> >> Andy, >> >> >> >> >> >> can you please respond to this since you created Y34-04? I now hear >> >> >> two people in favour of Y34-02 and we had this back in July 2014: >> >> >> >> >> >> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out >> >> >> a concrete proposal. >> >> >> >> >> >> So is the main delta of Y34-04 compared to Y34-02 (i) the additional >> >> >> text (the three list items) or (ii) additional restrictions of "root" >> >> >> to top-level nodes. (The Y34-04 referes to ncx:root which is not known >> >> >> to everybody.) >> >> >> >> >> > >> >> > >> >> > There are corner cases like YANG Patch edit value that need to be >> >> > anyxml. >> >> > >> >> >> Would adoption of Y34-02 with the additional text (the three list >> >> >> items) of Y34-04 be a workable solution? >> >> >> >> >> >> >> >> >> The discussion in the last VI meeting seemed to favor this solution >> >> but there is still this issue of JSON -> XML -> JSON round-trip >> >> conversion of anydata (unstructured data). >> >> >> >> IMO the loss of JSON typing through the XML conversion >> >> is not an issue because the only schema that matters is >> >> the YANG anydata. E.g., booleans and numbers are >> >> just strings. null is not supported. All simple nodes are >> >> strings. There are no keys so there are no real arrays. >> >> The server may return multiple containers that could >> >> have been encoded as an array. >> >> >> > >> > Yes, the JSON I-D must be updated to define how anydata is encoded. >> > >> > In general, I believe a JSON receiver must be able to do conversions >> > if needed, that is, if the JSON type does not match the type of the >> > YANG data model, the receiver must convert as needed instead of >> > throwing an error. I believe the YANG type is authoritative, not the >> > type used in the encoding. Lada may not like this but since the two >> >> Well, I fully agree that YANG types should be authoritative but, >> strangely enough, it leads me to a completely different conclusion: If a >> leaf is defined as uint8, and both parties are supposed to know that, >> why should the sender want to encode it as string? > > a) In the context of anydata, the sender may simply not have the type > information. You mentioned YANG types first, and YANG types have nothing to do with anyxml/anydata. > > b) In other contexts, there might be translators involved or encoding > layers that have not access to the type information. Yes, I understand that: there is software that's primarily developed for XML and the developers want to minimize the impact of a new encoding on their code. However, for someone who starts a new JSON-only implementation in anything else than Javascript, the idea of converting JSON numbers to strings must look really weird. > > And there is always conversion since we will send 64-bit ints as > strings etc. The JSON type in the encoding simply is not authoritative Yes, unfortunately. Note that even in the JSON WG not everybody is happy with this I-JSON restriction: http://www.ietf.org/mail-archive/web/json/current/msg03577.html > and dropping messages because someone did send 5 instead of "5" or > "False" instead of False in JSON seems counter productive if our goal > is interoperability. The same can be said about sending "42.0" instead of "42". I think the correct solution for the JSON encoding spec is to require that JSON encoding be in accordance with the YANG type (again, this is not about anydata). If the receiving side wants to be liberal and tolerate type violations, it's fine with me. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 05:43:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF5C1A90C5 for ; Fri, 23 Jan 2015 05:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehs2fwzeoR0y for ; Fri, 23 Jan 2015 05:43:55 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92501A90C4 for ; Fri, 23 Jan 2015 05:43:54 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4b0:625d:f229:d528] (unknown [IPv6:2001:718:1a02:1:4b0:625d:f229:d528]) by mail.nic.cz (Postfix) with ESMTPSA id 1453C140A81; Fri, 23 Jan 2015 14:43:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422020632; bh=12ggDCz6BOhhaAnJoVKBkJvjR8jCQCizXxQ7d/TmBc4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Fyk/Yxg7H9C9CeTy+o3Qd4s2U73lgRaFEuKQmFfuITqRY6g76R2wVWZX8kbTHa2uY 7uOFCvTj36LQ50QPc0CCfSl2NznPLZtTd8CAnXPJWWYJfusg6UikvsqxXGmN3WiIhU N+Mxye87bWhWAcmQskg+B3Ioyr5TEd6wHunVqqHE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150123.132214.879268627000276944.mbj@tail-f.com> Date: Fri, 23 Jan 2015 14:43:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53FBA571-4E1A-4B13-A98D-D5AB5C073E93@nic.cz> References: <20150123.130814.797514719780233079.mbj@tail-f.com> <20150123.132214.879268627000276944.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:43:56 -0000 > On 23 Jan 2015, at 13:22, Martin Bjorklund wrote: >=20 > Andy Bierman wrote: >> On Fri, Jan 23, 2015 at 4:08 AM, Martin Bjorklund = wrote: >>> Andy Bierman wrote: >>>> On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka = wrote: >>>>> Juergen Schoenwaelder = writes: >>>>>=20 >>>>>> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >>>>>>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman = wrote: >>>>>>>> On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >>>>>>>> wrote: >>>>>>>>> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund = wrote: >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> Juergen Schoenwaelder = wrote: >>>>>>>>>>> The 2014-12-03 virtual interim meeting proposal is to adopt = Y34-04. >>>>>>>>>>=20 >>>>>>>>>> I don't think Y34-04 is sufficient. If I understand Y34-04 = (add >>>>>>>>>> 'root) correctly, the difference between it and Y34-02 (add = 'anydata') >>>>>>>>>> is that 'root' is a special case of 'anydata'; i.e., 'root' = behaves as >>>>>>>>>> 'anydata' with the constraint that it only can hande = top-level nodes. >>>>>>>>>>=20 >>>>>>>>>> As an example of why this is not sufficient, YANG PATCH uses = anyxml >>>>>>>>>> with non-top-level nodes. It would not be possible to use = 'root' in >>>>>>>>>> this case. 'anydata' would be a better match. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Andy, >>>>>>>>>=20 >>>>>>>>> can you please respond to this since you created Y34-04? I now = hear >>>>>>>>> two people in favour of Y34-02 and we had this back in July = 2014: >>>>>>>>>=20 >>>>>>>>> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to = work out >>>>>>>>> a concrete proposal. >>>>>>>>>=20 >>>>>>>>> So is the main delta of Y34-04 compared to Y34-02 (i) the = additional >>>>>>>>> text (the three list items) or (ii) additional restrictions of = "root" >>>>>>>>> to top-level nodes. (The Y34-04 referes to ncx:root which is = not known >>>>>>>>> to everybody.) >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> There are corner cases like YANG Patch edit value that need to = be >>>>>>>> anyxml. >>>>>>>>=20 >>>>>>>>> Would adoption of Y34-02 with the additional text (the three = list >>>>>>>>> items) of Y34-04 be a workable solution? >>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The discussion in the last VI meeting seemed to favor this = solution >>>>>>> but there is still this issue of JSON -> XML -> JSON round-trip >>>>>>> conversion of anydata (unstructured data). >>>>>>>=20 >>>>>>> IMO the loss of JSON typing through the XML conversion >>>>>>> is not an issue because the only schema that matters is >>>>>>> the YANG anydata. E.g., booleans and numbers are >>>>>>> just strings. null is not supported. All simple nodes are >>>>>>> strings. There are no keys so there are no real arrays. >>>>>>> The server may return multiple containers that could >>>>>>> have been encoded as an array. >>>>>>>=20 >>>>>>=20 >>>>>> Yes, the JSON I-D must be updated to define how anydata is = encoded. >>>>>>=20 >>>>>> In general, I believe a JSON receiver must be able to do = conversions >>>>>> if needed, that is, if the JSON type does not match the type of = the >>>>>> YANG data model, the receiver must convert as needed instead of >>>>>> throwing an error. I believe the YANG type is authoritative, not = the >>>>>> type used in the encoding. Lada may not like this but since the = two >>>>>=20 >>>>> Well, I fully agree that YANG types should be authoritative but, >>>>> strangely enough, it leads me to a completely different = conclusion: If a >>>>> leaf is defined as uint8, and both parties are supposed to know = that, >>>>> why should the sender want to encode it as string? >>>>>=20 >>>>=20 >>>> Because we are talking about anyxml, not uint8. >>>> The entire point of anyxml is that is carries absolultely >>>> no YANG schema information whatsoever. >>>> The peer parsing the node has no way to associate >>>> uint8 with any sub-node of the anyxml blob. >>>=20 >>> In the generic case this is true. >>>=20 >>> But for example in YANG PATCH, the target node is known from the >>> context, so the anydata blob can/will be parsed according to the >>> schema. >>>=20 >>=20 >> This is a corner-case full of implementation details. >> e.g., all the data can be passed before all the resource >> offsets that identify the schema. There is nothing except >> description-stmt text to associate the target leaf with >> the anyxml blob. Not sure how an off-the-shelf tool could >> ever implement YANG Patch correctly. >=20 > Agreed. >=20 > But I think that this case might be pretty common - i.e., from some > context the schema of the anydata blob will eventually be known. For > example, we could do: >=20 > list logged-notification { > key id; > leaf id { ... } > leaf device-address { ... } > // more meta-data here > anydata notification; > } >=20 > The implementation of the logged-notification list doesn't have to > know all the notifications, but a consumer that knows the schema of > some or all notifications can use this info to parse the data. Exactly, and that=E2=80=99s why I want to leave it open whether what=E2=80= =99s received in anydata as 42 will be sent in JSON encoding = as "foo": "42" or "foo": 42. Lada >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 05:47:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0573C1A90D7 for ; Fri, 23 Jan 2015 05:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4kyL4eK-b7r for ; Fri, 23 Jan 2015 05:47:23 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 77EA11A90C8 for ; Fri, 23 Jan 2015 05:47:18 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B7E6D1280052; Fri, 23 Jan 2015 14:47:17 +0100 (CET) Date: Fri, 23 Jan 2015 14:47:17 +0100 (CET) Message-Id: <20150123.144717.1429377458665700984.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <53FBA571-4E1A-4B13-A98D-D5AB5C073E93@nic.cz> References: <20150123.132214.879268627000276944.mbj@tail-f.com> <53FBA571-4E1A-4B13-A98D-D5AB5C073E93@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:47:25 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjMgSmFu IDIwMTUsIGF0IDEzOjIyLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+ PiBPbiBGcmksIEphbiAyMywgMjAxNSBhdCA0OjA4IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpA dGFpbC1mLmNvbT4NCj4gPj4gd3JvdGU6DQo+ID4+PiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT4gd3JvdGU6DQo+ID4+Pj4gT24gRnJpLCBKYW4gMjMsIDIwMTUgYXQgMjoxNCBBTSwg TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6Pg0KPiA+Pj4+IHdyb3RlOg0KPiA+Pj4+PiBK dWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k ZT4gd3JpdGVzOg0KPiA+Pj4+PiANCj4gPj4+Pj4+IE9uIFRodSwgSmFuIDIyLCAyMDE1IGF0IDAz OjU3OjM2UE0gLTA4MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPj4+Pj4+PiBPbiBXZWQsIEph biAyMSwgMjAxNSBhdCA3OjA1IEFNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4N Cj4gPj4+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4gT24gV2VkLCBKYW4gMjEsIDIwMTUgYXQgMjoy MSBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ID4+Pj4+Pj4+IDxqLnNjaG9lbndhZWxkZXJA amFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4gT24gVGh1LCBKYW4gMDgs IDIwMTUgYXQgMTA6Mzc6MjhBTSArMDEwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPj4+ Pj4+Pj4+PiBIaSwNCj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+ Pj4+Pj4+Pj4+IFRoZSAyMDE0LTEyLTAzIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIHByb3Bvc2Fs IGlzIHRvIGFkb3B0DQo+ID4+Pj4+Pj4+Pj4+IFkzNC0wNC4NCj4gPj4+Pj4+Pj4+PiANCj4gPj4+ Pj4+Pj4+PiBJIGRvbid0IHRoaW5rIFkzNC0wNCBpcyBzdWZmaWNpZW50LiAgSWYgSSB1bmRlcnN0 YW5kIFkzNC0wNCAoYWRkDQo+ID4+Pj4+Pj4+Pj4gJ3Jvb3QpIGNvcnJlY3RseSwgdGhlIGRpZmZl cmVuY2UgYmV0d2VlbiBpdCBhbmQgWTM0LTAyIChhZGQNCj4gPj4+Pj4+Pj4+PiAnYW55ZGF0YScp DQo+ID4+Pj4+Pj4+Pj4gaXMgdGhhdCAncm9vdCcgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgJ2FueWRh dGEnOyBpLmUuLCAncm9vdCcgYmVoYXZlcw0KPiA+Pj4+Pj4+Pj4+IGFzDQo+ID4+Pj4+Pj4+Pj4g J2FueWRhdGEnIHdpdGggdGhlIGNvbnN0cmFpbnQgdGhhdCBpdCBvbmx5IGNhbiBoYW5kZSB0b3At bGV2ZWwNCj4gPj4+Pj4+Pj4+PiBub2Rlcy4NCj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBB cyBhbiBleGFtcGxlIG9mIHdoeSB0aGlzIGlzIG5vdCBzdWZmaWNpZW50LCBZQU5HIFBBVENIIHVz ZXMgYW55eG1sDQo+ID4+Pj4+Pj4+Pj4gd2l0aCBub24tdG9wLWxldmVsIG5vZGVzLiAgSXQgd291 bGQgbm90IGJlIHBvc3NpYmxlIHRvIHVzZSAncm9vdCcNCj4gPj4+Pj4+Pj4+PiBpbg0KPiA+Pj4+ Pj4+Pj4+IHRoaXMgY2FzZS4gICdhbnlkYXRhJyB3b3VsZCBiZSBhIGJldHRlciBtYXRjaC4NCj4g Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4gQW5keSwNCj4gPj4+Pj4+Pj4+ IA0KPiA+Pj4+Pj4+Pj4gY2FuIHlvdSBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIHNpbmNlIHlvdSBj cmVhdGVkIFkzNC0wND8gSSBub3cgaGVhcg0KPiA+Pj4+Pj4+Pj4gdHdvIHBlb3BsZSBpbiBmYXZv dXIgb2YgWTM0LTAyIGFuZCB3ZSBoYWQgdGhpcyBiYWNrIGluIEp1bHkgMjAxNDoNCj4gPj4+Pj4+ Pj4+IA0KPiA+Pj4+Pj4+Pj4gICAyMDE0LTA3LTIxIG1lZXRpbmcgcHJvcG9zYWwgYW5kIGFjdGlv bjogYWRvcHQgWTM0LTAyLCBBQiB0byB3b3JrDQo+ID4+Pj4+Pj4+PiAgIG91dA0KPiA+Pj4+Pj4+ Pj4gICBhIGNvbmNyZXRlIHByb3Bvc2FsLg0KPiA+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+PiBTbyBp cyB0aGUgbWFpbiBkZWx0YSBvZiBZMzQtMDQgY29tcGFyZWQgdG8gWTM0LTAyIChpKSB0aGUgYWRk aXRpb25hbA0KPiA+Pj4+Pj4+Pj4gdGV4dCAodGhlIHRocmVlIGxpc3QgaXRlbXMpIG9yIChpaSkg YWRkaXRpb25hbCByZXN0cmljdGlvbnMgb2YNCj4gPj4+Pj4+Pj4+ICJyb290Ig0KPiA+Pj4+Pj4+ Pj4gdG8gdG9wLWxldmVsIG5vZGVzLiAoVGhlIFkzNC0wNCByZWZlcmVzIHRvIG5jeDpyb290IHdo aWNoIGlzIG5vdA0KPiA+Pj4+Pj4+Pj4ga25vd24NCj4gPj4+Pj4+Pj4+IHRvIGV2ZXJ5Ym9keS4p DQo+ID4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+PiBUaGVy ZSBhcmUgY29ybmVyIGNhc2VzIGxpa2UgWUFORyBQYXRjaCBlZGl0IHZhbHVlIHRoYXQgbmVlZCB0 byBiZQ0KPiA+Pj4+Pj4+PiBhbnl4bWwuDQo+ID4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4gV291bGQg YWRvcHRpb24gb2YgWTM0LTAyIHdpdGggdGhlIGFkZGl0aW9uYWwgdGV4dCAodGhlIHRocmVlIGxp c3QNCj4gPj4+Pj4+Pj4+IGl0ZW1zKSBvZiBZMzQtMDQgYmUgYSB3b3JrYWJsZSBzb2x1dGlvbj8N Cj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+IA0KPiA+Pj4+Pj4+IA0KPiA+Pj4+Pj4+IFRoZSBkaXNj dXNzaW9uIGluIHRoZSBsYXN0IFZJIG1lZXRpbmcgc2VlbWVkIHRvIGZhdm9yIHRoaXMgc29sdXRp b24NCj4gPj4+Pj4+PiBidXQgdGhlcmUgaXMgc3RpbGwgdGhpcyBpc3N1ZSBvZiBKU09OIC0+IFhN TCAtPiBKU09OIHJvdW5kLXRyaXANCj4gPj4+Pj4+PiBjb252ZXJzaW9uIG9mIGFueWRhdGEgKHVu c3RydWN0dXJlZCBkYXRhKS4NCj4gPj4+Pj4+PiANCj4gPj4+Pj4+PiBJTU8gdGhlIGxvc3Mgb2Yg SlNPTiB0eXBpbmcgdGhyb3VnaCB0aGUgWE1MIGNvbnZlcnNpb24NCj4gPj4+Pj4+PiBpcyBub3Qg YW4gaXNzdWUgYmVjYXVzZSB0aGUgb25seSBzY2hlbWEgdGhhdCBtYXR0ZXJzIGlzDQo+ID4+Pj4+ Pj4gdGhlIFlBTkcgYW55ZGF0YS4gIEUuZy4sICBib29sZWFucyBhbmQgbnVtYmVycyBhcmUNCj4g Pj4+Pj4+PiBqdXN0IHN0cmluZ3MuIG51bGwgaXMgbm90IHN1cHBvcnRlZC4gIEFsbCBzaW1wbGUg bm9kZXMgYXJlDQo+ID4+Pj4+Pj4gc3RyaW5ncy4gIFRoZXJlIGFyZSBubyBrZXlzIHNvIHRoZXJl IGFyZSBubyByZWFsIGFycmF5cy4NCj4gPj4+Pj4+PiBUaGUgc2VydmVyIG1heSByZXR1cm4gbXVs dGlwbGUgY29udGFpbmVycyB0aGF0IGNvdWxkDQo+ID4+Pj4+Pj4gaGF2ZSBiZWVuIGVuY29kZWQg YXMgYW4gYXJyYXkuDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+PiANCj4gPj4+Pj4+IFllcywgdGhlIEpT T04gSS1EIG11c3QgYmUgdXBkYXRlZCB0byBkZWZpbmUgaG93IGFueWRhdGEgaXMgZW5jb2RlZC4N Cj4gPj4+Pj4+IA0KPiA+Pj4+Pj4gSW4gZ2VuZXJhbCwgSSBiZWxpZXZlIGEgSlNPTiByZWNlaXZl ciBtdXN0IGJlIGFibGUgdG8gZG8gY29udmVyc2lvbnMNCj4gPj4+Pj4+IGlmIG5lZWRlZCwgdGhh dCBpcywgaWYgdGhlIEpTT04gdHlwZSBkb2VzIG5vdCBtYXRjaCB0aGUgdHlwZSBvZiB0aGUNCj4g Pj4+Pj4+IFlBTkcgZGF0YSBtb2RlbCwgdGhlIHJlY2VpdmVyIG11c3QgY29udmVydCBhcyBuZWVk ZWQgaW5zdGVhZCBvZg0KPiA+Pj4+Pj4gdGhyb3dpbmcgYW4gZXJyb3IuIEkgYmVsaWV2ZSB0aGUg WUFORyB0eXBlIGlzIGF1dGhvcml0YXRpdmUsIG5vdCB0aGUNCj4gPj4+Pj4+IHR5cGUgdXNlZCBp biB0aGUgZW5jb2RpbmcuIExhZGEgbWF5IG5vdCBsaWtlIHRoaXMgYnV0IHNpbmNlIHRoZSB0d28N Cj4gPj4+Pj4gDQo+ID4+Pj4+IFdlbGwsIEkgZnVsbHkgYWdyZWUgdGhhdCBZQU5HIHR5cGVzIHNo b3VsZCBiZSBhdXRob3JpdGF0aXZlIGJ1dCwNCj4gPj4+Pj4gc3RyYW5nZWx5IGVub3VnaCwgaXQg bGVhZHMgbWUgdG8gYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBjb25jbHVzaW9uOiBJZg0KPiA+Pj4+ PiBhDQo+ID4+Pj4+IGxlYWYgaXMgZGVmaW5lZCBhcyB1aW50OCwgYW5kIGJvdGggcGFydGllcyBh cmUgc3VwcG9zZWQgdG8ga25vdyB0aGF0LA0KPiA+Pj4+PiB3aHkgc2hvdWxkIHRoZSBzZW5kZXIg d2FudCB0byBlbmNvZGUgaXQgYXMgc3RyaW5nPw0KPiA+Pj4+PiANCj4gPj4+PiANCj4gPj4+PiBC ZWNhdXNlIHdlIGFyZSB0YWxraW5nIGFib3V0IGFueXhtbCwgbm90IHVpbnQ4Lg0KPiA+Pj4+IFRo ZSBlbnRpcmUgcG9pbnQgb2YgYW55eG1sIGlzIHRoYXQgaXMgY2FycmllcyBhYnNvbHVsdGVseQ0K PiA+Pj4+IG5vIFlBTkcgc2NoZW1hIGluZm9ybWF0aW9uIHdoYXRzb2V2ZXIuDQo+ID4+Pj4gVGhl IHBlZXIgcGFyc2luZyB0aGUgbm9kZSBoYXMgbm8gd2F5IHRvIGFzc29jaWF0ZQ0KPiA+Pj4+IHVp bnQ4IHdpdGggYW55IHN1Yi1ub2RlIG9mIHRoZSBhbnl4bWwgYmxvYi4NCj4gPj4+IA0KPiA+Pj4g SW4gdGhlIGdlbmVyaWMgY2FzZSB0aGlzIGlzIHRydWUuDQo+ID4+PiANCj4gPj4+IEJ1dCBmb3Ig ZXhhbXBsZSBpbiBZQU5HIFBBVENILCB0aGUgdGFyZ2V0IG5vZGUgaXMga25vd24gZnJvbSB0aGUN Cj4gPj4+IGNvbnRleHQsIHNvIHRoZSBhbnlkYXRhIGJsb2IgY2FuL3dpbGwgYmUgcGFyc2VkIGFj Y29yZGluZyB0byB0aGUNCj4gPj4+IHNjaGVtYS4NCj4gPj4+IA0KPiA+PiANCj4gPj4gVGhpcyBp cyBhIGNvcm5lci1jYXNlIGZ1bGwgb2YgaW1wbGVtZW50YXRpb24gZGV0YWlscy4NCj4gPj4gZS5n LiwgYWxsIHRoZSBkYXRhIGNhbiBiZSBwYXNzZWQgYmVmb3JlIGFsbCB0aGUgcmVzb3VyY2UNCj4g Pj4gb2Zmc2V0cyB0aGF0IGlkZW50aWZ5IHRoZSBzY2hlbWEuICBUaGVyZSBpcyBub3RoaW5nIGV4 Y2VwdA0KPiA+PiBkZXNjcmlwdGlvbi1zdG10IHRleHQgdG8gYXNzb2NpYXRlIHRoZSB0YXJnZXQg bGVhZiB3aXRoDQo+ID4+IHRoZSBhbnl4bWwgYmxvYi4gIE5vdCBzdXJlIGhvdyBhbiBvZmYtdGhl LXNoZWxmIHRvb2wgY291bGQNCj4gPj4gZXZlciBpbXBsZW1lbnQgWUFORyBQYXRjaCBjb3JyZWN0 bHkuDQo+ID4gDQo+ID4gQWdyZWVkLg0KPiA+IA0KPiA+IEJ1dCBJIHRoaW5rIHRoYXQgdGhpcyBj YXNlIG1pZ2h0IGJlIHByZXR0eSBjb21tb24gLSBpLmUuLCBmcm9tIHNvbWUNCj4gPiBjb250ZXh0 IHRoZSBzY2hlbWEgb2YgdGhlIGFueWRhdGEgYmxvYiB3aWxsIGV2ZW50dWFsbHkgYmUga25vd24u ICBGb3INCj4gPiBleGFtcGxlLCB3ZSBjb3VsZCBkbzoNCj4gPiANCj4gPiBsaXN0IGxvZ2dlZC1u b3RpZmljYXRpb24gew0KPiA+ICAga2V5IGlkOw0KPiA+ICAgbGVhZiBpZCB7IC4uLiB9DQo+ID4g ICBsZWFmIGRldmljZS1hZGRyZXNzIHsgLi4uIH0NCj4gPiAgIC8vIG1vcmUgbWV0YS1kYXRhIGhl cmUNCj4gPiAgIGFueWRhdGEgbm90aWZpY2F0aW9uOw0KPiA+IH0NCj4gPiANCj4gPiBUaGUgaW1w bGVtZW50YXRpb24gb2YgdGhlIGxvZ2dlZC1ub3RpZmljYXRpb24gbGlzdCBkb2Vzbid0IGhhdmUg dG8NCj4gPiBrbm93IGFsbCB0aGUgbm90aWZpY2F0aW9ucywgYnV0IGEgY29uc3VtZXIgdGhhdCBr bm93cyB0aGUgc2NoZW1hIG9mDQo+ID4gc29tZSBvciBhbGwgbm90aWZpY2F0aW9ucyBjYW4gdXNl IHRoaXMgaW5mbyB0byBwYXJzZSB0aGUgZGF0YS4NCj4gDQo+IEV4YWN0bHksIGFuZCB0aGF04oCZ cyB3aHkgSSB3YW50IHRvIGxlYXZlIGl0IG9wZW4gd2hldGhlciB3aGF04oCZcw0KPiByZWNlaXZl ZCBpbiBhbnlkYXRhIGFzIDxmb28+NDI8L2Zvbz4gd2lsbCBiZSBzZW50IGluIEpTT04gZW5jb2Rp bmcgYXMNCj4gDQo+ICJmb28iOiAiNDIiDQo+IA0KPiBvcg0KPiANCj4gImZvbyI6IDQyLg0KDQpJ c24ndCB0aGlzIHdoYXQgSnVlcmdlbiBhbHNvIHByb3Bvc2VkPyAgQmFzaWNhbGx5IGFsbG93IGJv dGggYQ0Kc2NoZW1hLWZhaXRoZnVsIGVuY29kaW5nLCBhbmQgYSBnZW5lcmljLCAic3RyaW5nIi1i YXNlZCBlbmNvZGluZy4gIChpdA0KYWZmZWN0cyBtb3JlIHRoYW4ganVzdCBsZWFmIHR5cGVzIHRo b3VnaCkuICBBIHJlY2VpdmVyIE1VU1QgKD8pIGJlDQphYmxlIHRvIGhhbmRsZSBib3RoIHN0eWxl cyBvZiBlbmNvZGluZ3MuDQoNCg0KL21hcnRpbg0K From nobody Fri Jan 23 06:01:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304151A8733 for ; Fri, 23 Jan 2015 06:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDU5H6HqQ5VO for ; Fri, 23 Jan 2015 06:01:25 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FFD1A8FD6 for ; Fri, 23 Jan 2015 06:01:25 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id BB68513F9D7; Fri, 23 Jan 2015 15:01:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422021683; bh=0zPtlxPBHQnyrpQ/IZSpUXaM8b9CSyTEy3qI9rZ6KOk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FkvTRMR1P4EOf39Akn+moETHKPM/DbHZJ+5741Vg+Ycs/+AdA/mTX1Z0VB3YoCXPV xhdZLkc6CilU6ibMeqvU6Jhc7P/NOvZGR5XNjGxtrnqClkBdIJTgzsvNcVcRpmeHgy 3OYA0rNXMDTPMvnhEWv3kVggmwYZBR+Jy2d5KKjE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150123.144717.1429377458665700984.mbj@tail-f.com> Date: Fri, 23 Jan 2015 15:01:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57143D9C-4C4F-43BF-A6AD-C2BDF6778B6D@nic.cz> References: <20150123.132214.879268627000276944.mbj@tail-f.com> <53FBA571-4E1A-4B13-A98D-D5AB5C073E93@nic.cz> <20150123.144717.1429377458665700984.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 14:01:27 -0000 > On 23 Jan 2015, at 14:47, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 23 Jan 2015, at 13:22, Martin Bjorklund wrote: >>>=20 >>> Andy Bierman wrote: >>>> On Fri, Jan 23, 2015 at 4:08 AM, Martin Bjorklund >>>> wrote: >>>>> Andy Bierman wrote: >>>>>> On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka >>>>>> wrote: >>>>>>> Juergen Schoenwaelder = writes: >>>>>>>=20 >>>>>>>> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >>>>>>>>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman = >>>>>>>>> wrote: >>>>>>>>>> On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >>>>>>>>>> wrote: >>>>>>>>>>> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund = wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> Juergen Schoenwaelder = wrote: >>>>>>>>>>>>> The 2014-12-03 virtual interim meeting proposal is to = adopt >>>>>>>>>>>>> Y34-04. >>>>>>>>>>>>=20 >>>>>>>>>>>> I don't think Y34-04 is sufficient. If I understand Y34-04 = (add >>>>>>>>>>>> 'root) correctly, the difference between it and Y34-02 (add >>>>>>>>>>>> 'anydata') >>>>>>>>>>>> is that 'root' is a special case of 'anydata'; i.e., 'root' = behaves >>>>>>>>>>>> as >>>>>>>>>>>> 'anydata' with the constraint that it only can hande = top-level >>>>>>>>>>>> nodes. >>>>>>>>>>>>=20 >>>>>>>>>>>> As an example of why this is not sufficient, YANG PATCH = uses anyxml >>>>>>>>>>>> with non-top-level nodes. It would not be possible to use = 'root' >>>>>>>>>>>> in >>>>>>>>>>>> this case. 'anydata' would be a better match. >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Andy, >>>>>>>>>>>=20 >>>>>>>>>>> can you please respond to this since you created Y34-04? I = now hear >>>>>>>>>>> two people in favour of Y34-02 and we had this back in July = 2014: >>>>>>>>>>>=20 >>>>>>>>>>> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to = work >>>>>>>>>>> out >>>>>>>>>>> a concrete proposal. >>>>>>>>>>>=20 >>>>>>>>>>> So is the main delta of Y34-04 compared to Y34-02 (i) the = additional >>>>>>>>>>> text (the three list items) or (ii) additional restrictions = of >>>>>>>>>>> "root" >>>>>>>>>>> to top-level nodes. (The Y34-04 referes to ncx:root which is = not >>>>>>>>>>> known >>>>>>>>>>> to everybody.) >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> There are corner cases like YANG Patch edit value that need = to be >>>>>>>>>> anyxml. >>>>>>>>>>=20 >>>>>>>>>>> Would adoption of Y34-02 with the additional text (the three = list >>>>>>>>>>> items) of Y34-04 be a workable solution? >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The discussion in the last VI meeting seemed to favor this = solution >>>>>>>>> but there is still this issue of JSON -> XML -> JSON = round-trip >>>>>>>>> conversion of anydata (unstructured data). >>>>>>>>>=20 >>>>>>>>> IMO the loss of JSON typing through the XML conversion >>>>>>>>> is not an issue because the only schema that matters is >>>>>>>>> the YANG anydata. E.g., booleans and numbers are >>>>>>>>> just strings. null is not supported. All simple nodes are >>>>>>>>> strings. There are no keys so there are no real arrays. >>>>>>>>> The server may return multiple containers that could >>>>>>>>> have been encoded as an array. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Yes, the JSON I-D must be updated to define how anydata is = encoded. >>>>>>>>=20 >>>>>>>> In general, I believe a JSON receiver must be able to do = conversions >>>>>>>> if needed, that is, if the JSON type does not match the type of = the >>>>>>>> YANG data model, the receiver must convert as needed instead of >>>>>>>> throwing an error. I believe the YANG type is authoritative, = not the >>>>>>>> type used in the encoding. Lada may not like this but since the = two >>>>>>>=20 >>>>>>> Well, I fully agree that YANG types should be authoritative but, >>>>>>> strangely enough, it leads me to a completely different = conclusion: If >>>>>>> a >>>>>>> leaf is defined as uint8, and both parties are supposed to know = that, >>>>>>> why should the sender want to encode it as string? >>>>>>>=20 >>>>>>=20 >>>>>> Because we are talking about anyxml, not uint8. >>>>>> The entire point of anyxml is that is carries absolultely >>>>>> no YANG schema information whatsoever. >>>>>> The peer parsing the node has no way to associate >>>>>> uint8 with any sub-node of the anyxml blob. >>>>>=20 >>>>> In the generic case this is true. >>>>>=20 >>>>> But for example in YANG PATCH, the target node is known from the >>>>> context, so the anydata blob can/will be parsed according to the >>>>> schema. >>>>>=20 >>>>=20 >>>> This is a corner-case full of implementation details. >>>> e.g., all the data can be passed before all the resource >>>> offsets that identify the schema. There is nothing except >>>> description-stmt text to associate the target leaf with >>>> the anyxml blob. Not sure how an off-the-shelf tool could >>>> ever implement YANG Patch correctly. >>>=20 >>> Agreed. >>>=20 >>> But I think that this case might be pretty common - i.e., from some >>> context the schema of the anydata blob will eventually be known. = For >>> example, we could do: >>>=20 >>> list logged-notification { >>> key id; >>> leaf id { ... } >>> leaf device-address { ... } >>> // more meta-data here >>> anydata notification; >>> } >>>=20 >>> The implementation of the logged-notification list doesn't have to >>> know all the notifications, but a consumer that knows the schema of >>> some or all notifications can use this info to parse the data. >>=20 >> Exactly, and that=E2=80=99s why I want to leave it open whether = what=E2=80=99s >> received in anydata as 42 will be sent in JSON encoding as >>=20 >> "foo": "42" >>=20 >> or >>=20 >> "foo": 42. >=20 > Isn't this what Juergen also proposed? Basically allow both a In a previous discussion Juergen didn=E2=80=99t seem to be happy with = this approach: http://www.ietf.org/mail-archive/web/netmod/current/msg10473.html > schema-faithful encoding, and a generic, "string"-based encoding. (it > affects more than just leaf types though). A receiver MUST (?) be > able to handle both styles of encodings. I don=E2=80=99t think it is necessary. Any use of anydata probably = requires that both parties are aware of what the contents are. How they = behave is then IMO outside the scope of YANG. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 08:44:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EDE1A9164 for ; Fri, 23 Jan 2015 08:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm08rqMdRVp1 for ; Fri, 23 Jan 2015 08:44:12 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 899411A930A for ; Fri, 23 Jan 2015 08:43:54 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so8297650lab.10 for ; Fri, 23 Jan 2015 08:43:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9Qsedj+0r+SoA5hLddDj8QOCKO5P9Mc5T1xuk0oy1P0=; b=lKk20SFhIS6kmnUjU/DaWkDZRkBrD8ZPiplRXxpa47c8lhl7wp5Aonyp9gC91fSDgH WxIJ4g6ngOMu7xOLSuM9nEOY2Ay1VgoTZMv29myd/EuH+vcGx65FHwxLsPte0xUw2HzS lGwX8crEyslzsH3QtRuBenqMxTxPV9z1ZeEtak5mPbZtIXx/Who+Qd3x10ulSv0cteij Wmohc+pqDjDACx1UFidK9Cuv0kHoi1DstJqTsBUciahQ58rYe3bxgDH8O6wkQSP7wNTq LbMV9gL3b6lO8jaUEe5kzVQt8kDYRml1QPsOYcoEZCU9NTWVz7ECvT8Zukf/8dWBGKia CSRg== X-Gm-Message-State: ALoCoQkpSN9dU6fc7j85FKHtIgNafdhtUIVNtqEfWOuLrWhlefjAjT5dG0U0NUh0NOEOmxBbTvs+ MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr8487714laf.82.1422031432929; Fri, 23 Jan 2015 08:43:52 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 08:43:52 -0800 (PST) In-Reply-To: <57143D9C-4C4F-43BF-A6AD-C2BDF6778B6D@nic.cz> References: <20150123.132214.879268627000276944.mbj@tail-f.com> <53FBA571-4E1A-4B13-A98D-D5AB5C073E93@nic.cz> <20150123.144717.1429377458665700984.mbj@tail-f.com> <57143D9C-4C4F-43BF-A6AD-C2BDF6778B6D@nic.cz> Date: Fri, 23 Jan 2015 08:43:52 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 16:44:14 -0000 On Fri, Jan 23, 2015 at 6:01 AM, Ladislav Lhotka wrote: > >> On 23 Jan 2015, at 14:47, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> >>>> On 23 Jan 2015, at 13:22, Martin Bjorklund wrote: >>>> >>>> Andy Bierman wrote: >>>>> On Fri, Jan 23, 2015 at 4:08 AM, Martin Bjorklund >>>>> wrote: >>>>>> Andy Bierman wrote: >>>>>>> On Fri, Jan 23, 2015 at 2:14 AM, Ladislav Lhotka >>>>>>> wrote: >>>>>>>> Juergen Schoenwaelder write= s: >>>>>>>> >>>>>>>>> On Thu, Jan 22, 2015 at 03:57:36PM -0800, Andy Bierman wrote: >>>>>>>>>> On Wed, Jan 21, 2015 at 7:05 AM, Andy Bierman >>>>>>>>>> wrote: >>>>>>>>>>> On Wed, Jan 21, 2015 at 2:21 AM, Juergen Schoenwaelder >>>>>>>>>>> wrote: >>>>>>>>>>>> On Thu, Jan 08, 2015 at 10:37:28AM +0100, Martin Bjorklund wro= te: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Juergen Schoenwaelder = wrote: >>>>>>>>>>>>>> The 2014-12-03 virtual interim meeting proposal is to adopt >>>>>>>>>>>>>> Y34-04. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think Y34-04 is sufficient. If I understand Y34-04 (= add >>>>>>>>>>>>> 'root) correctly, the difference between it and Y34-02 (add >>>>>>>>>>>>> 'anydata') >>>>>>>>>>>>> is that 'root' is a special case of 'anydata'; i.e., 'root' b= ehaves >>>>>>>>>>>>> as >>>>>>>>>>>>> 'anydata' with the constraint that it only can hande top-leve= l >>>>>>>>>>>>> nodes. >>>>>>>>>>>>> >>>>>>>>>>>>> As an example of why this is not sufficient, YANG PATCH uses = anyxml >>>>>>>>>>>>> with non-top-level nodes. It would not be possible to use 'r= oot' >>>>>>>>>>>>> in >>>>>>>>>>>>> this case. 'anydata' would be a better match. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Andy, >>>>>>>>>>>> >>>>>>>>>>>> can you please respond to this since you created Y34-04? I now= hear >>>>>>>>>>>> two people in favour of Y34-02 and we had this back in July 20= 14: >>>>>>>>>>>> >>>>>>>>>>>> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to w= ork >>>>>>>>>>>> out >>>>>>>>>>>> a concrete proposal. >>>>>>>>>>>> >>>>>>>>>>>> So is the main delta of Y34-04 compared to Y34-02 (i) the addi= tional >>>>>>>>>>>> text (the three list items) or (ii) additional restrictions of >>>>>>>>>>>> "root" >>>>>>>>>>>> to top-level nodes. (The Y34-04 referes to ncx:root which is n= ot >>>>>>>>>>>> known >>>>>>>>>>>> to everybody.) >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There are corner cases like YANG Patch edit value that need to = be >>>>>>>>>>> anyxml. >>>>>>>>>>> >>>>>>>>>>>> Would adoption of Y34-02 with the additional text (the three l= ist >>>>>>>>>>>> items) of Y34-04 be a workable solution? >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The discussion in the last VI meeting seemed to favor this solut= ion >>>>>>>>>> but there is still this issue of JSON -> XML -> JSON round-trip >>>>>>>>>> conversion of anydata (unstructured data). >>>>>>>>>> >>>>>>>>>> IMO the loss of JSON typing through the XML conversion >>>>>>>>>> is not an issue because the only schema that matters is >>>>>>>>>> the YANG anydata. E.g., booleans and numbers are >>>>>>>>>> just strings. null is not supported. All simple nodes are >>>>>>>>>> strings. There are no keys so there are no real arrays. >>>>>>>>>> The server may return multiple containers that could >>>>>>>>>> have been encoded as an array. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, the JSON I-D must be updated to define how anydata is encode= d. >>>>>>>>> >>>>>>>>> In general, I believe a JSON receiver must be able to do conversi= ons >>>>>>>>> if needed, that is, if the JSON type does not match the type of t= he >>>>>>>>> YANG data model, the receiver must convert as needed instead of >>>>>>>>> throwing an error. I believe the YANG type is authoritative, not = the >>>>>>>>> type used in the encoding. Lada may not like this but since the t= wo >>>>>>>> >>>>>>>> Well, I fully agree that YANG types should be authoritative but, >>>>>>>> strangely enough, it leads me to a completely different conclusion= : If >>>>>>>> a >>>>>>>> leaf is defined as uint8, and both parties are supposed to know th= at, >>>>>>>> why should the sender want to encode it as string? >>>>>>>> >>>>>>> >>>>>>> Because we are talking about anyxml, not uint8. >>>>>>> The entire point of anyxml is that is carries absolultely >>>>>>> no YANG schema information whatsoever. >>>>>>> The peer parsing the node has no way to associate >>>>>>> uint8 with any sub-node of the anyxml blob. >>>>>> >>>>>> In the generic case this is true. >>>>>> >>>>>> But for example in YANG PATCH, the target node is known from the >>>>>> context, so the anydata blob can/will be parsed according to the >>>>>> schema. >>>>>> >>>>> >>>>> This is a corner-case full of implementation details. >>>>> e.g., all the data can be passed before all the resource >>>>> offsets that identify the schema. There is nothing except >>>>> description-stmt text to associate the target leaf with >>>>> the anyxml blob. Not sure how an off-the-shelf tool could >>>>> ever implement YANG Patch correctly. >>>> >>>> Agreed. >>>> >>>> But I think that this case might be pretty common - i.e., from some >>>> context the schema of the anydata blob will eventually be known. For >>>> example, we could do: >>>> >>>> list logged-notification { >>>> key id; >>>> leaf id { ... } >>>> leaf device-address { ... } >>>> // more meta-data here >>>> anydata notification; >>>> } >>>> >>>> The implementation of the logged-notification list doesn't have to >>>> know all the notifications, but a consumer that knows the schema of >>>> some or all notifications can use this info to parse the data. >>> >>> Exactly, and that=E2=80=99s why I want to leave it open whether what=E2= =80=99s >>> received in anydata as 42 will be sent in JSON encoding as >>> >>> "foo": "42" >>> >>> or >>> >>> "foo": 42. >> >> Isn't this what Juergen also proposed? Basically allow both a > > In a previous discussion Juergen didn=E2=80=99t seem to be happy with thi= s approach: > > http://www.ietf.org/mail-archive/web/netmod/current/msg10473.html > You mean this example: (1) { "x": { "y": " 4668 " } } This is a strange corner-case that does not exactly survive a round-trip. Of course the "y" string content will be rendered in XML with character entities. (2) <a xmlns:foo=3D'urn:foo'> <foo:b>4668</foo:b> </a> The return JSON is changed: (3) { "x": { "y": "<a xmlns:foo=3D'urn:foo'> <foo:b>4668</foo:b> </a>" } } What use-case does this serve? I have never seen a real operation do something like this. Supposedly this conversion can happen if the node /x is configuration data. Client A sets /x in JSON. (1) Client B does a GET /x in XML and then a PUT /x in XML. (2) Client A reads /x in JSON (3) >> schema-faithful encoding, and a generic, "string"-based encoding. (it >> affects more than just leaf types though). A receiver MUST (?) be >> able to handle both styles of encodings. > > I don=E2=80=99t think it is necessary. Any use of anydata probably requir= es that both parties are aware of what the contents are. How they behave is= then IMO outside the scope of YANG. > Our implementation would never generate anything like (1). Instead, the structure would be passed in JSON, not encoded as a string: (4) { "x": { "y": { "foo:a" : { "b": "4668" } } } } > Lada > >> >> >> /martin > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jan 23 09:11:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AB31A1AD0 for ; Fri, 23 Jan 2015 09:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoT9Q_T_OOTk for ; Fri, 23 Jan 2015 09:11:10 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 774A91A1AC9 for ; Fri, 23 Jan 2015 09:11:09 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ms9so12276lab.1 for ; Fri, 23 Jan 2015 09:11:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oQbBIhfTU8tBwkToODbSDHA+yiuPZmM1l/uozuoiv8k=; b=dSEZmlwX+tdi4rVsKXw4S5wkulMe9ZfjEVCNDZdYxeQaEMJjS7zLJq48SThNe/IKpQ 7Yu3oZuF4XnMSCtY7PauB5o/svAwWOezYv6DWis0uvkuoQhPXIjbh/GP+RIDwQb+gNZF Vv76qtcpV6M8IZDAJYkikMxnFpDNDRLZYcZIIleZv5l2Mrm7Mu3LULaoifHQ6L3DvePa eEK/mB7BoYoyPR7JGB+MPLkhAcokwEKM8YjpJ2g9R8SjpOA7lsY3sC6z5OmRflCLmvjU isK6Eo6R/Kucjp5g42uagLN/PhXLd4INT50udvPi+84y4gO0bH7kDxX6YUpAOx2AgDki +nww== X-Gm-Message-State: ALoCoQnkOV5u2fYoPMv1CqIg/b7APmD1hQyO1EhsSfJwUmapnBVdi5I1zKBLujolZHhBfDnN3HBl MIME-Version: 1.0 X-Received: by 10.152.204.40 with SMTP id kv8mr8082299lac.42.1422033068006; Fri, 23 Jan 2015 09:11:08 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 09:11:07 -0800 (PST) Date: Fri, 23 Jan 2015 09:11:07 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 17:11:11 -0000 Hi, Sometimes it helps to agree on the actual problems that need to be solved, before we endlessly debate solutions. I can only think of 4 use case classes for anydata. Use case 1: root ----------------------- Description: The anydata node MUST be a container (JSON object) and the child nodes MUST be top-level YANG data nodes supported by the server (i.e., TL-nodes defined in the YANG modules advertised by the server) Context: rpc/input and rpc/output Examples: edit-config node, get-config node Use case 2: fixed unknown schema node ------------------------------------------------------- Description: The anydata node MUST be a container (JSON object) and the child nodes MUST be instances of a specific YANG. data-def-stmt, which does not have to be a TL-node. The specific YANG object is not known to the server. Context: data-model dependent; could be abstract data structure, notification, operational data Examples: A pass-through application such as a logger Use case 3: fixed known schema node ----------------------------------------------------- Description: The anydata node MUST be a container (JSON object) and the child nodes MUST be instances of a specific YANG. data-def-stmt, which does not have to be a TL-node. The specific YANG object is known to the server in some ad-hoc out-of-band manner. No machine-readable base YANG statements indicate the actual schema node. Context: data-model dependent; could be abstract data structure, notification, operational data Examples: YANG Mount Use case 4: dynamic schema node ------------------------------------------------- Description: The anydata node MUST be a container (JSON object) and the child nodes MUST be instances of any YANG. data-def-stmt, which does not have to be a TL-node. The specific YANG object may be known to the server in some ad-hoc out-of-band manner. No machine-readable base YANG statements indicate the actual schema node. Context: rpc/input, rpc/output, ??? Examples: YANG Patch Summary -------------- In each case, it should be OK to encode simple nodes as strings and complex nodes as containers. The end consumer that is expected to know the correct schema can convert from the string to the correct YANG type. There are corner cases such as instance-identifier and QNames (e.g., identityref), but I think these can also be handled correctly if specified in the netmod-yang-json (and metadata) drafts in enough detail. Andy From nobody Fri Jan 23 09:23:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72691A8873 for ; Fri, 23 Jan 2015 09:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhREF93-fiM2 for ; Fri, 23 Jan 2015 09:23:20 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 F22081A8878 for ; Fri, 23 Jan 2015 09:23:00 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u10so8158105lbd.12 for ; Fri, 23 Jan 2015 09:22:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BDvxE3/qn8S+BhSeoXQzWm38cLBbjiwO45zaH9b9M2Y=; b=IPNLWKxmQQz5h2QflyAqOEph9sT4s48KZqr6ENsV97nR0xET55A0HzVCJ6dLatDxi3 bIOFzww/uOcxRQ6VRufKhSl4eKaNL0SUooaFvlKpLiiVFUmxG8E7FHvY+gHfLRqkjTbp RoyaFZKiARqFidd2op3LcBolmvoLF1XTlKRLedb89r2x8se2ZTJwoWGnIugEsfB15xqz NqqncfpSCEVeUzPSKABFudQ4cZpJ006KbfsJyHhltAdtUSRAB1BNuNcfAjlJFA5kojOg mGpKzzNwHjWmeJCjvmexIuIaZ72UqaE2LsXeeD51/E2ZI64da+FLW3IsMfGTY0VuUKrB 3yNA== X-Gm-Message-State: ALoCoQmgytI8U9f+3ByVQvhoe1DZwmN7Yql51cV8L3KCSE2uHuDrpivcb9ZKJ/+kKybOJrD2RUY3 MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr8578247lab.1.1422033779493; Fri, 23 Jan 2015 09:22:59 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 09:22:59 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 09:22:59 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 17:23:23 -0000 Hi, Actually, YANG Mount is use case (4) so maybe there are only 3 types of anydata use-cases. Andy On Fri, Jan 23, 2015 at 9:11 AM, Andy Bierman wrote: > Hi, > > Sometimes it helps to agree on the actual problems that > need to be solved, before we endlessly debate solutions. > I can only think of 4 use case classes for anydata. > > > Use case 1: root > ----------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be top-level YANG data nodes > supported by the server (i.e., TL-nodes defined in the YANG modules > advertised by the server) > > Context: rpc/input and rpc/output > > Examples: edit-config node, get-config node > > > Use case 2: fixed unknown schema node > ------------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of a specific YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object is not known to the server. > > Context: data-model dependent; could be abstract data structure, > notification, operational data > > Examples: A pass-through application such as a logger > > > Use case 3: fixed known schema node > ----------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of a specific YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object is known to the server > in some ad-hoc out-of-band manner. No machine-readable > base YANG statements indicate the actual schema node. > > Context: data-model dependent; could be abstract data structure, > notification, operational data > > Examples: YANG Mount > > > Use case 4: dynamic schema node > ------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of any YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object may be known to the server > in some ad-hoc out-of-band manner. No machine-readable > base YANG statements indicate the actual schema node. > > Context: rpc/input, rpc/output, ??? > > Examples: YANG Patch > > > Summary > -------------- > In each case, it should be OK to encode simple nodes as strings > and complex nodes as containers. The end consumer that is > expected to know the correct schema can convert from the > string to the correct YANG type. There are corner cases > such as instance-identifier and QNames (e.g., identityref), > but I think these can also be handled correctly if specified > in the netmod-yang-json (and metadata) drafts in enough detail. > > > > Andy From nobody Fri Jan 23 10:43:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4A1ACDF4 for ; Fri, 23 Jan 2015 10:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4Y8GMFkjSMN for ; Fri, 23 Jan 2015 10:43:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id AF7F11A8793 for ; Fri, 23 Jan 2015 10:43:09 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 983C71280982; Fri, 23 Jan 2015 19:43:08 +0100 (CET) Date: Fri, 23 Jan 2015 19:44:55 +0100 (CET) Message-Id: <20150123.194455.1602556268535849900.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 18:43:11 -0000 Andy Bierman wrote: > Hi, > > Sometimes it helps to agree on the actual problems that > need to be solved, before we endlessly debate solutions. > I can only think of 4 use case classes for anydata. *only* 4? (or maybe 3). I think these 3 use cases provide a pretty strong argument in favor of adding anydata. Re. use case 3 or 4, I would argue that in both YANG patch and mount, the server knows the schema. So I'd scratch use case 4. /martin > Use case 1: root > ----------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be top-level YANG data nodes > supported by the server (i.e., TL-nodes defined in the YANG modules > advertised by the server) > > Context: rpc/input and rpc/output > > Examples: edit-config node, get-config node > > > Use case 2: fixed unknown schema node > ------------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of a specific YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object is not known to the server. > > Context: data-model dependent; could be abstract data structure, > notification, operational data > > Examples: A pass-through application such as a logger > > > Use case 3: fixed known schema node > ----------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of a specific YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object is known to the server > in some ad-hoc out-of-band manner. No machine-readable > base YANG statements indicate the actual schema node. > > Context: data-model dependent; could be abstract data structure, > notification, operational data > > Examples: YANG Mount > > > Use case 4: dynamic schema node > ------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of any YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object may be known to the server > in some ad-hoc out-of-band manner. No machine-readable > base YANG statements indicate the actual schema node. > > Context: rpc/input, rpc/output, ??? > > Examples: YANG Patch > > > Summary > -------------- > In each case, it should be OK to encode simple nodes as strings > and complex nodes as containers. The end consumer that is > expected to know the correct schema can convert from the > string to the correct YANG type. There are corner cases > such as instance-identifier and QNames (e.g., identityref), > but I think these can also be handled correctly if specified > in the netmod-yang-json (and metadata) drafts in enough detail. > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Jan 23 11:29:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1421ACEFD for ; Fri, 23 Jan 2015 11:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utfYiwMiSYf2 for ; Fri, 23 Jan 2015 11:29:02 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 C3B431ACEE3 for ; Fri, 23 Jan 2015 11:29:01 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so8762614lbi.1 for ; Fri, 23 Jan 2015 11:29:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sE12unLctlbPZFhsuUcRR6J8jjW1iF5ZKWirJMJyv9U=; b=nBQv1TqIIcmJxmuBw/RwTUawjgCAtSauGd+UEM1erH2poHgt8o8bD62EAtne8h79N3 2qxlfxJvbgi50bhwoa8NwoD5ynsv2km5FgdP7TpAde1rp7ElUfj1E5olkpg+d8+FOCT9 X/oZWAAChRxjyjY2j+p6VBZiB2KYXOHZbtJb84t/w62OAkdqc+XzgMaK4POs4wyZByiL sUOhLYUITV69NStJO63QVXH/5aNUjO/1Z9VaxWufy0PKynSwzpz/q1nyxVfRnjYbJLGe MKkFxmtEDpXLSv2SmpXqkhntvtUBqNnOrzOkXCopc+wae4l+qUONPJG0tPkz0aA4//g/ urxw== X-Gm-Message-State: ALoCoQmoXKjgpv7egSaepm6JYRTPateJloFm9ezzmvzL3505VSf8M07wQazGvJVYksn2emxENxpi MIME-Version: 1.0 X-Received: by 10.112.156.132 with SMTP id we4mr9006178lbb.59.1422041340297; Fri, 23 Jan 2015 11:29:00 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 11:29:00 -0800 (PST) In-Reply-To: <20150123.194455.1602556268535849900.mbj@tail-f.com> References: <20150123.194455.1602556268535849900.mbj@tail-f.com> Date: Fri, 23 Jan 2015 11:29:00 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 19:29:04 -0000 On Fri, Jan 23, 2015 at 10:44 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Sometimes it helps to agree on the actual problems that >> need to be solved, before we endlessly debate solutions. >> I can only think of 4 use case classes for anydata. > > *only* 4? (or maybe 3). I think these 3 use cases provide a pretty > strong argument in favor of adding anydata. > The solution could be clarification of anyxml. IMO that would be better that having a new keyword. > Re. use case 3 or 4, I would argue that in both YANG patch and mount, > the server knows the schema. So I'd scratch use case 4. > The parser may not know the specific description-stmt requirements of every YANG module implemented by the server. Read my text. The server knows the schema in some manner not machine-readable with base YANG statements. YANG Mount and Patch are both (4) because the specific node is not fixed. It can be different for each instance, depending on the which schema node is selected by the client for the target of the anyxml. > > /martin > Andy > >> Use case 1: root >> ----------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be top-level YANG data nodes >> supported by the server (i.e., TL-nodes defined in the YANG modules >> advertised by the server) >> >> Context: rpc/input and rpc/output >> >> Examples: edit-config node, get-config node >> >> >> Use case 2: fixed unknown schema node >> ------------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of a specific YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object is not known to the server. >> >> Context: data-model dependent; could be abstract data structure, >> notification, operational data >> >> Examples: A pass-through application such as a logger >> >> >> Use case 3: fixed known schema node >> ----------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of a specific YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object is known to the server >> in some ad-hoc out-of-band manner. No machine-readable >> base YANG statements indicate the actual schema node. >> >> Context: data-model dependent; could be abstract data structure, >> notification, operational data >> >> Examples: YANG Mount >> >> >> Use case 4: dynamic schema node >> ------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of any YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object may be known to the server >> in some ad-hoc out-of-band manner. No machine-readable >> base YANG statements indicate the actual schema node. >> >> Context: rpc/input, rpc/output, ??? >> >> Examples: YANG Patch >> >> >> Summary >> -------------- >> In each case, it should be OK to encode simple nodes as strings >> and complex nodes as containers. The end consumer that is >> expected to know the correct schema can convert from the >> string to the correct YANG type. There are corner cases >> such as instance-identifier and QNames (e.g., identityref), >> but I think these can also be handled correctly if specified >> in the netmod-yang-json (and metadata) drafts in enough detail. >> >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From nobody Fri Jan 23 12:11:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568BD1A0396 for ; Fri, 23 Jan 2015 12:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEQtXk8KalT3 for ; Fri, 23 Jan 2015 12:11:14 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 2F5D01A0379 for ; Fri, 23 Jan 2015 12:11:14 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id gm9so9282738lab.0 for ; Fri, 23 Jan 2015 12:11:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0kiyAwQ5uID+4gFclHTiA9vZIEJFW7xj+BFby9IRHao=; b=ZRJo7J7/J5477PFgLauVwQcogkoCQM06iS/kMD9R/BrX5X3DwBedwOc9vJ2prmHjyb W+9V1ZJmyTMSS+axHML3rxOgnKjgoMeL/D0P/ovGSF++ueTPGwShGqH1+AysKg9nBMcx GebG9bzThvj8zXvd3LRVWFo1cXbv3sqKChfRlIkHnU349OX8u4DjNn2mmNNE5fo1c2A9 ZEkiR5klWfYpg/iOqEYcu7Tb7SLSh8CeOm7xfcx9vEXi4tDIbJZnKknSgCOqcGtnjKRP bDbThTc8XPyJkIKe+kkmTWO48AivsD0Tjw8xXKgKfQBMI6mCf+R+ueEZBa+tfgk7G2Ec xlug== X-Gm-Message-State: ALoCoQm5QTeRiQ9emyEhqG3sbkq2bXhRcauE18MqwdwSF3AZm31WIvVhiwRR+oeWs7yLrrj19hmr MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr9120537lbv.21.1422043872657; Fri, 23 Jan 2015 12:11:12 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 12:11:12 -0800 (PST) In-Reply-To: <20150123.194455.1602556268535849900.mbj@tail-f.com> References: <20150123.194455.1602556268535849900.mbj@tail-f.com> Date: Fri, 23 Jan 2015 12:11:12 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 20:11:16 -0000 On Fri, Jan 23, 2015 at 10:44 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> Sometimes it helps to agree on the actual problems that >> need to be solved, before we endlessly debate solutions. >> I can only think of 4 use case classes for anydata. > > *only* 4? (or maybe 3). I think these 3 use cases provide a pretty > strong argument in favor of adding anydata. > > Re. use case 3 or 4, I would argue that in both YANG patch and mount, > the server knows the schema. So I'd scratch use case 4. > use case (3) is the restconf-resource extension proposed for RESTCONF #15. I do not strongly object to solution Y34-02 but it is confusing. Is anyxml deprecated with this solution? And anydata is just the clarified version of anyxml? So text that could just be clarified for anyxml will be left untouched and new text for anydata will be added that says basically the same thing except that PIs and mixed content are not allowed in XML? And anywhere anyxml is mentioned it will be changed to say anyxml and anydata? > > /martin Andy > > >> Use case 1: root >> ----------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be top-level YANG data nodes >> supported by the server (i.e., TL-nodes defined in the YANG modules >> advertised by the server) >> >> Context: rpc/input and rpc/output >> >> Examples: edit-config node, get-config node >> >> >> Use case 2: fixed unknown schema node >> ------------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of a specific YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object is not known to the server. >> >> Context: data-model dependent; could be abstract data structure, >> notification, operational data >> >> Examples: A pass-through application such as a logger >> >> >> Use case 3: fixed known schema node >> ----------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of a specific YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object is known to the server >> in some ad-hoc out-of-band manner. No machine-readable >> base YANG statements indicate the actual schema node. >> >> Context: data-model dependent; could be abstract data structure, >> notification, operational data >> >> Examples: YANG Mount >> >> >> Use case 4: dynamic schema node >> ------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of any YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object may be known to the server >> in some ad-hoc out-of-band manner. No machine-readable >> base YANG statements indicate the actual schema node. >> >> Context: rpc/input, rpc/output, ??? >> >> Examples: YANG Patch >> >> >> Summary >> -------------- >> In each case, it should be OK to encode simple nodes as strings >> and complex nodes as containers. The end consumer that is >> expected to know the correct schema can convert from the >> string to the correct YANG type. There are corner cases >> such as instance-identifier and QNames (e.g., identityref), >> but I think these can also be handled correctly if specified >> in the netmod-yang-json (and metadata) drafts in enough detail. >> >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From nobody Fri Jan 23 12:38:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654051A1E0E for ; Fri, 23 Jan 2015 12:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYexd3DDBD36 for ; Fri, 23 Jan 2015 12:38:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C7C911A1BF6 for ; Fri, 23 Jan 2015 12:38:20 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 8AE8E1280052; Fri, 23 Jan 2015 21:38:19 +0100 (CET) Date: Fri, 23 Jan 2015 21:40:07 +0100 (CET) Message-Id: <20150123.214007.1417708630534954309.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150123.194455.1602556268535849900.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 20:38:24 -0000 Andy Bierman wrote: > On Fri, Jan 23, 2015 at 10:44 AM, Martin Bjorklund wrote: > > Re. use case 3 or 4, I would argue that in both YANG patch and mount, > > the server knows the schema. So I'd scratch use case 4. > > > > > The parser may not know the specific description-stmt requirements > of every YANG module implemented by the server. Read my text. > The server knows the schema in some manner not machine-readable with > base YANG statements. The difference between 3 and 4, the way I read your description, is that in 3 the server *knows* the schema, but in 4 the server may or may not know the schema. I think that in both YANG patch and mount, the server knows the schema, thus they fall into category 3. > YANG Mount and Patch are both (4) because the specific node is > not fixed. It can be different for each instance, depending on the > which schema node is selected by the client for the target of > the anyxml. Right. I thought this was 3. /martin From nobody Fri Jan 23 12:43:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8711A1EF8 for ; Fri, 23 Jan 2015 12:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtYwTuN0-2m5 for ; Fri, 23 Jan 2015 12:43:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id D167D1A3BA2 for ; Fri, 23 Jan 2015 12:43:11 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 276B11280052; Fri, 23 Jan 2015 21:43:11 +0100 (CET) Date: Fri, 23 Jan 2015 21:44:59 +0100 (CET) Message-Id: <20150123.214459.2059337850692219652.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150123.194455.1602556268535849900.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 20:43:28 -0000 Andy Bierman wrote: > On Fri, Jan 23, 2015 at 10:44 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Hi, > >> > >> Sometimes it helps to agree on the actual problems that > >> need to be solved, before we endlessly debate solutions. > >> I can only think of 4 use case classes for anydata. > > > > *only* 4? (or maybe 3). I think these 3 use cases provide a pretty > > strong argument in favor of adding anydata. > > > > Re. use case 3 or 4, I would argue that in both YANG patch and mount, > > the server knows the schema. So I'd scratch use case 4. > > > > use case (3) is the restconf-resource extension proposed for RESTCONF #15. But there is no anydata involved in this extension? > I do not strongly object to solution Y34-02 but it is confusing. > Is anyxml deprecated with this solution? I think it would still be needed in edit-config, since NETCONF is not tied to YANG. > And anydata is just the clarified version of anyxml? > > So text that could just be clarified for anyxml will be left untouched > and new text for anydata will be added that says basically the > same thing except that PIs and mixed content are not allowed in XML? Either we say that anydata represents a structure that *could* be modelled in YANG, or we say that it represents a structure that *is* modelled in YANG. > And anywhere anyxml is mentioned it will be changed to say anyxml and anydata? I need to check the details, but basically yes, that's what needs to be done. /martin From nobody Fri Jan 23 12:48:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8241A6F05 for ; Fri, 23 Jan 2015 12:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCapkyKOXscp for ; Fri, 23 Jan 2015 12:47:58 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 BDA3C1A6FFF for ; Fri, 23 Jan 2015 12:47:47 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id hv19so9335543lab.13 for ; Fri, 23 Jan 2015 12:47:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5tMBU1LTe/QfuJXWC52ntY0E6nB8av43z3fwuiTjQUw=; b=jZb8MMVW9t2hGPlnggzSqtepFco73DVx5YfHNcocgQ9O+XrorVQ76HrEnY4GZ43bup S7GCL9ulS0GlmZUXx+1qpxUXzDzs45ABLtGS4bZ76a6gcY656PUOZ7Eu9FST2o60pI10 Cn3jw67j9gB8hEJkje5D2uT+zHs296LDaERoY/rxbk8DykXXhJo45ff515+Qd33aEaPe Q3baCyE/HbnD3zL2qlqxFc+LfYmkCSQrZr79k1CVJngSw/PZasg63oxm6EQVTg3uW4qa V61B4EXn9D2jbNMqmu0yY20GCF2tm86BC3R5rvbWbFD2tLDAo88TJSHI/BP78iAj/Nho UyaQ== X-Gm-Message-State: ALoCoQl01La8jF/TWXWCeQ4Jo3ICzk77R8hWwEeWANVl/Z0P5Kj00f1VcH/XiSr6EIblVc7S8dBM MIME-Version: 1.0 X-Received: by 10.112.217.68 with SMTP id ow4mr9276668lbc.97.1422046066116; Fri, 23 Jan 2015 12:47:46 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 12:47:46 -0800 (PST) In-Reply-To: <20150123.214007.1417708630534954309.mbj@tail-f.com> References: <20150123.194455.1602556268535849900.mbj@tail-f.com> <20150123.214007.1417708630534954309.mbj@tail-f.com> Date: Fri, 23 Jan 2015 12:47:46 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 20:48:00 -0000 On Fri, Jan 23, 2015 at 12:40 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Fri, Jan 23, 2015 at 10:44 AM, Martin Bjorklund wrote: > >> > Re. use case 3 or 4, I would argue that in both YANG patch and mount, >> > the server knows the schema. So I'd scratch use case 4. >> > >> >> >> The parser may not know the specific description-stmt requirements >> of every YANG module implemented by the server. Read my text. >> The server knows the schema in some manner not machine-readable with >> base YANG statements. > > The difference between 3 and 4, the way I read your description, is > that in 3 the server *knows* the schema, but in 4 the server may or > may not know the schema. I think that in both YANG patch and mount, > the server knows the schema, thus they fall into category 3. > >> YANG Mount and Patch are both (4) because the specific node is >> not fixed. It can be different for each instance, depending on the >> which schema node is selected by the client for the target of >> the anyxml. > > Right. I thought this was 3. > > #3 is where the schema is always the same, like the content always has to match the /restconf entry point schema. #4 is configurable. The exact schema will depend on other content in the YANG Mount or Patch requests. > > /martin Andy From nobody Fri Jan 23 12:59:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F231A1B40 for ; Fri, 23 Jan 2015 12:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zet0EM0WaB8Q for ; Fri, 23 Jan 2015 12:58:26 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 3E7F71A7030 for ; Fri, 23 Jan 2015 12:58:25 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u10so9062273lbd.12 for ; Fri, 23 Jan 2015 12:58:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B4jxSGO8jCX1E3acshMCkmNIMhNY/laO4v0R3mViPa4=; b=lvckNXf0sIk9bAHyIVerG8QguOpv8rKut15DtlTgz8RofTwV52bQRJJ21R5lJmCC8J wygjXt9ouQ0fW5DF7snkZNHgc0DZrs4N33unskejMf5edSRXH0TEUrH3npKa0sxXc4EA YxqPHrx+4lkGNfgic6bMx2d49a904j8kd03uno+6sNoer3gQ5ljtJyjITGbvVvT8PGmi rJizPWMq168W4bfcIMALYfwMulcT1tNJeamVtrzZFmU/tLGgE2S5p1Kndgw0Z6OHHWaL 2gMvYAuxPpVmOrd+OCfdWBUI5tLbRwsE5bh6W3CkWk9rkoSsEKNF4MAy84aafENgnzVu dEgA== X-Gm-Message-State: ALoCoQnb2WPU5T0rsHOw7cO1JDonoQyqMG2CkuVqyGuI+fMvkPNJoTxreig3QD7hT5XlKbe2Q8OM MIME-Version: 1.0 X-Received: by 10.112.25.7 with SMTP id y7mr9357505lbf.94.1422046703809; Fri, 23 Jan 2015 12:58:23 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 12:58:23 -0800 (PST) In-Reply-To: <20150123.214459.2059337850692219652.mbj@tail-f.com> References: <20150123.194455.1602556268535849900.mbj@tail-f.com> <20150123.214459.2059337850692219652.mbj@tail-f.com> Date: Fri, 23 Jan 2015 12:58:23 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 20:58:32 -0000 On Fri, Jan 23, 2015 at 12:44 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Fri, Jan 23, 2015 at 10:44 AM, Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> Hi, >> >> >> >> Sometimes it helps to agree on the actual problems that >> >> need to be solved, before we endlessly debate solutions. >> >> I can only think of 4 use case classes for anydata. >> > >> > *only* 4? (or maybe 3). I think these 3 use cases provide a pretty >> > strong argument in favor of adding anydata. >> > >> > Re. use case 3 or 4, I would argue that in both YANG patch and mount, >> > the server knows the schema. So I'd scratch use case 4. >> > >> >> use case (3) is the restconf-resource extension proposed for RESTCONF #15. > > But there is no anydata involved in this extension? > >> I do not strongly object to solution Y34-02 but it is confusing. >> Is anyxml deprecated with this solution? > > I think it would still be needed in edit-config, since NETCONF is not > tied to YANG. > >> And anydata is just the clarified version of anyxml? >> >> So text that could just be clarified for anyxml will be left untouched >> and new text for anydata will be added that says basically the >> same thing except that PIs and mixed content are not allowed in XML? > > Either we say that anydata represents a structure that *could* be > modelled in YANG, or we say that it represents a structure that *is* > modelled in YANG. > No, we say anydata is YANG. So tools are supposed to support anyxml and anydata now? anyxml can be any XML the server accepts and anydata has to be constrained (details TBD). So is anyxml deprecated or not in this proposal? >> And anywhere anyxml is mentioned it will be changed to say anyxml and anydata? > > I need to check the details, but basically yes, that's what needs to > be done. > > > /martin Andy From nobody Fri Jan 23 21:07:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AAF1A00FA for ; Fri, 23 Jan 2015 21:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_9A-GfQpXaa for ; Fri, 23 Jan 2015 21:07:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CB01A00F9 for ; Fri, 23 Jan 2015 21:07:37 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:a059:32c0:4a38:a6b0] (unknown [IPv6:2a01:5e0:29:ffff:a059:32c0:4a38:a6b0]) by mail.nic.cz (Postfix) with ESMTPSA id 6E3DA140EEC; Sat, 24 Jan 2015 06:07:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422076054; bh=CNT7JSFMsQXBwqKcGfSP46XgWtgVokf2lcNTrIvDKgY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=adiNAsGGaaWJ1vBIzPn3NRFm5nbLk6vLswJ6l8w5OpyOKLzn+OneHtKDticFG4yc4 pUtxjXC8LJPkJFr1hisdH1FgV4ImvPC0BCQr+d9nQp8aoIxP8wIOK7kNisnU3LYVEA zsXKWJWO/vlHFq+0edpTd1K4KeVNxKk+A0R+/DGQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 24 Jan 2015 06:07:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <61553BA2-5DFD-4D17-8118-6CDD1B9A03D3@nic.cz> References: <20150123.132214.879268627000276944.mbj@tail-f.com> <53FBA571-4E1A-4B13-A98D-D5AB5C073E93@nic.cz> <20150123.144717.1429377458665700984.mbj@tail-f.com> <57143D9C-4C4F-43BF-A6AD-C2BDF6778B6D@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 05:07:43 -0000 > On 23 Jan 2015, at 17:43, Andy Bierman wrote: =E2=80=A6 >=20 >>>> Exactly, and that=E2=80=99s why I want to leave it open whether = what=E2=80=99s >>>> received in anydata as 42 will be sent in JSON encoding = as >>>>=20 >>>> "foo": "42" >>>>=20 >>>> or >>>>=20 >>>> "foo": 42. >>>=20 >>> Isn't this what Juergen also proposed? Basically allow both a >>=20 >> In a previous discussion Juergen didn=E2=80=99t seem to be happy with = this approach: >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg10473.html >>=20 >=20 >=20 > You mean this example: No, not only this particular example. Throughout the discussion, Juergen = always wanted (or at least so I understood him) to have a fixed mapping = between XML- and JSON-encoded anyxml content, i.e. one that=E2=80=99s = the same for all anyxml nodes. My preference has been to be able to = handle each anyxml in a specific way - sometimes a schema is available, = sometimes isn=E2=80=99t. Lada >=20 > (1) > { > "x": { > "y": " 4668 " > } > } >=20 >=20 > This is a strange corner-case that does not exactly survive a = round-trip. >=20 > Of course the "y" string content will be rendered in XML with > character entities. >=20 > (2) > <a xmlns:foo=3D'urn:foo'> <foo:b>4668</foo:b> > </a> >=20 > The return JSON is changed: >=20 > (3) > { > "x": { > "y": "<a xmlns:foo=3D'urn:foo'> > <foo:b>4668</foo:b> </a>" > } > } >=20 > What use-case does this serve? > I have never seen a real operation do something like this. >=20 > Supposedly this conversion can happen if the node /x is configuration = data. > Client A sets /x in JSON. (1) > Client B does a GET /x in XML and then a PUT /x in XML. (2) > Client A reads /x in JSON (3) >=20 >=20 >>> schema-faithful encoding, and a generic, "string"-based encoding. = (it >>> affects more than just leaf types though). A receiver MUST (?) be >>> able to handle both styles of encodings. >>=20 >> I don=E2=80=99t think it is necessary. Any use of anydata probably = requires that both parties are aware of what the contents are. How they = behave is then IMO outside the scope of YANG. >>=20 >=20 > Our implementation would never generate anything like (1). > Instead, the structure would be passed in JSON, not encoded as a = string: >=20 > (4) > { > "x": { > "y": { > "foo:a" : { > "b": "4668" > } > } > } > } >=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>=20 >=20 >=20 > Andy >=20 >=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 21:20:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF39A1A00FD for ; Fri, 23 Jan 2015 21:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm-Igba8ksdB for ; Fri, 23 Jan 2015 21:20:24 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC7A1A00FA for ; Fri, 23 Jan 2015 21:20:24 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:a059:32c0:4a38:a6b0] (unknown [IPv6:2a01:5e0:29:ffff:a059:32c0:4a38:a6b0]) by mail.nic.cz (Postfix) with ESMTPSA id B2DCB140940; Sat, 24 Jan 2015 06:20:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422076822; bh=D72xMnZUlWZhP0duq4nqt76XO2MI2f9Ou88nY09WYd0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LFEMZY1bhK6C7tYYJzEtlYqx7ABzH4W9yU/iEvZ9mDmIkbAsHz+9ThfU1p+Xla1rE AyNKS0KqF9GRKqWiKQ8b6PAe2pQQtja8fYQtiuJsMMOJyYsxynwBpTYcKPEFRfMWQA YgckUXo1uGoRE7vvvQCIJ2QxJKz8ETTVJdODR+Vk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 24 Jan 2015 06:20:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 05:20:26 -0000 Hi, I think there is also a use case where anydata conveys information that = has some non-YANG schema. One example might be an Internet kiosk whose = web pages can be edited through NETCONF. For this purpose it would = actually be best to simply rename anyxml to anydata. Lada =20 > On 23 Jan 2015, at 18:11, Andy Bierman wrote: >=20 > Hi, >=20 > Sometimes it helps to agree on the actual problems that > need to be solved, before we endlessly debate solutions. > I can only think of 4 use case classes for anydata. >=20 >=20 > Use case 1: root > ----------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be top-level YANG data nodes > supported by the server (i.e., TL-nodes defined in the YANG modules > advertised by the server) >=20 > Context: rpc/input and rpc/output >=20 > Examples: edit-config node, get-config node >=20 >=20 > Use case 2: fixed unknown schema node > ------------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of a specific YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object is not known to the server. >=20 > Context: data-model dependent; could be abstract data structure, > notification, operational data >=20 > Examples: A pass-through application such as a logger >=20 >=20 > Use case 3: fixed known schema node > ----------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of a specific YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object is known to the server > in some ad-hoc out-of-band manner. No machine-readable > base YANG statements indicate the actual schema node. >=20 > Context: data-model dependent; could be abstract data structure, > notification, operational data >=20 > Examples: YANG Mount >=20 >=20 > Use case 4: dynamic schema node > ------------------------------------------------- > Description: The anydata node MUST be a container (JSON object) > and the child nodes MUST be instances of any YANG. > data-def-stmt, which does not have to be a TL-node. > The specific YANG object may be known to the server > in some ad-hoc out-of-band manner. No machine-readable > base YANG statements indicate the actual schema node. >=20 > Context: rpc/input, rpc/output, ??? >=20 > Examples: YANG Patch >=20 >=20 > Summary > -------------- > In each case, it should be OK to encode simple nodes as strings > and complex nodes as containers. The end consumer that is > expected to know the correct schema can convert from the > string to the correct YANG type. There are corner cases > such as instance-identifier and QNames (e.g., identityref), > but I think these can also be handled correctly if specified > in the netmod-yang-json (and metadata) drafts in enough detail. >=20 >=20 >=20 > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 23 21:54:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377321A0101 for ; Fri, 23 Jan 2015 21:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8hywxhHomyI for ; Fri, 23 Jan 2015 21:53:56 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534FE1A010C for ; Fri, 23 Jan 2015 21:53:56 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u10so885507lbd.12 for ; Fri, 23 Jan 2015 21:53:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ig+uHDtI/+yBzvfL+4MWRr+qSIh4UMUKl9Fs8jXC1Y0=; b=jWjpAdMZQdYNJeWLEhshS80XN6fJfaBQIk3b7O5JZkYKogRvEazwDrc2/6yAaLPuyV ijxs8TnbgdIZqfGKGTqx5M1xty1jQCsdcPD+4ZYL8+SjcMYsbEjIzftuDPo5geoaEnbc U0uSo1REwzSOdYtfECGAv1r86lLbVv6YTeLGY6prnO5DuXF25akS2kt0hs2FrJg1LCW1 te/fBrr8MP9b1+JKIt130xrYPVaZHW59OkVCwNlzKVIRPp22HUep1zVCVflhsyNfXgKq Jg6gcxzbgW0RLaO6DT46/7uKniSWZ2pJyyU2pFWpSvkoPgWMYuCroMWx6sa/lFuOCTBj NpaA== X-Gm-Message-State: ALoCoQkBaQBHCwvAEVNd5/85VZa3eo+gsXhg5MAdkvNz15Sxd0zwqxfJnfWopIq3wFsZa69EVRP9 MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr10993398lbz.100.1422078834566; Fri, 23 Jan 2015 21:53:54 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 21:53:54 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 21:53:54 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 05:53:59 -0000 On Fri, Jan 23, 2015 at 9:20 PM, Ladislav Lhotka wrote: > Hi, > > I think there is also a use case where anydata conveys information that h= as some non-YANG schema. One example might be an Internet kiosk whose web p= ages can be edited through NETCONF. For this purpose it would actually be b= est to simply rename anyxml to anydata. > I do not agree with this use-case. It does not exist in real implementations. Mixed mode XML is complicated and standard translation to JSON is not really worth the effort it would take. IMO mixed mode should not be supported by anydata. > Lada Andy > >> On 23 Jan 2015, at 18:11, Andy Bierman wrote: >> >> Hi, >> >> Sometimes it helps to agree on the actual problems that >> need to be solved, before we endlessly debate solutions. >> I can only think of 4 use case classes for anydata. >> >> >> Use case 1: root >> ----------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be top-level YANG data nodes >> supported by the server (i.e., TL-nodes defined in the YANG modules >> advertised by the server) >> >> Context: rpc/input and rpc/output >> >> Examples: edit-config node, get-config node >> >> >> Use case 2: fixed unknown schema node >> ------------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of a specific YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object is not known to the server. >> >> Context: data-model dependent; could be abstract data structure, >> notification, operational data >> >> Examples: A pass-through application such as a logger >> >> >> Use case 3: fixed known schema node >> ----------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of a specific YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object is known to the server >> in some ad-hoc out-of-band manner. No machine-readable >> base YANG statements indicate the actual schema node. >> >> Context: data-model dependent; could be abstract data structure, >> notification, operational data >> >> Examples: YANG Mount >> >> >> Use case 4: dynamic schema node >> ------------------------------------------------- >> Description: The anydata node MUST be a container (JSON object) >> and the child nodes MUST be instances of any YANG. >> data-def-stmt, which does not have to be a TL-node. >> The specific YANG object may be known to the server >> in some ad-hoc out-of-band manner. No machine-readable >> base YANG statements indicate the actual schema node. >> >> Context: rpc/input, rpc/output, ??? >> >> Examples: YANG Patch >> >> >> Summary >> -------------- >> In each case, it should be OK to encode simple nodes as strings >> and complex nodes as containers. The end consumer that is >> expected to know the correct schema can convert from the >> string to the correct YANG type. There are corner cases >> such as instance-identifier and QNames (e.g., identityref), >> but I think these can also be handled correctly if specified >> in the netmod-yang-json (and metadata) drafts in enough detail. >> >> >> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Sat Jan 24 00:25:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67C81A0154 for ; Sat, 24 Jan 2015 00:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CjoHJPMh3KI for ; Sat, 24 Jan 2015 00:25:51 -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 7D57F1A0119 for ; Sat, 24 Jan 2015 00:25:51 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 00172AC8; Sat, 24 Jan 2015 09:25:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zPP4LCjzSA08; Sat, 24 Jan 2015 09:25:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 24 Jan 2015 09:25:49 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 660EB20036; Sat, 24 Jan 2015 09:25:49 +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 hruv4YzTRYFB; Sat, 24 Jan 2015 09:17:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1CC120035; Sat, 24 Jan 2015 09:25:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2DC3830E7F3A; Sat, 24 Jan 2015 09:25:46 +0100 (CET) Date: Sat, 24 Jan 2015 09:25:45 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150124082543.GA43523@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 08:25:54 -0000 On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: > Hi, > > I think there is also a use case where anydata conveys information that has some non-YANG schema. One example might be an Internet kiosk whose web pages can be edited through NETCONF. For this purpose it would actually be best to simply rename anyxml to anydata. > My understanding is this: anyxml = any XML (including mixed content, PIs, whatever, not necessarily interoperable) anydata = anything that conforms to the YANG restrictions on XML (no mixed content, no PIs, interoperable) For me (as technical contributor), it seems sensible to have both and it seem sensible to discourage usage of anyxml (at least withing IETF data models). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Jan 24 01:04:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B351A0377 for ; Sat, 24 Jan 2015 01:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOQsu0KBr3bF for ; Sat, 24 Jan 2015 01:04:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31AA1A1A3D for ; Sat, 24 Jan 2015 01:04:03 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:19dd:91e:43b8:d796] (unknown [IPv6:2a01:5e0:29:ffff:19dd:91e:43b8:d796]) by mail.nic.cz (Postfix) with ESMTPSA id 357861403D3; Sat, 24 Jan 2015 10:04:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422090241; bh=i6118IJwELdetWJq6ELsEsv50ti3asa5dZeBLXDwrhk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tkFNdu0oL4Yjr9cmC6FQl2ittd1UCz1ll05n6K0aPOl9CUqg9nA31eZiCrrLREn5s GYtD1ukrQnVowa9d84CYovNtJj4PyFTwvWn3bnaLPE+YEZdSKL00jp3CYqRzoH9zwG AFG+uWTxVqqn+KR5s99tPGk0VvsVAzyvzsJk3xr4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150124082543.GA43523@elstar.local> Date: Sat, 24 Jan 2015 10:04:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150124082543.GA43523@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 09:04:09 -0000 > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder = wrote: >=20 > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> I think there is also a use case where anydata conveys information = that has some non-YANG schema. One example might be an Internet kiosk = whose web pages can be edited through NETCONF. For this purpose it would = actually be best to simply rename anyxml to anydata. >>=20 >=20 > My understanding is this: >=20 > anyxml =3D any XML (including mixed content, PIs, whatever, not > necessarily interoperable) Yes, but I=E2=80=99d also like to have a symmetric rule for JSON = encoding, i. e. any valid JSON value.=20 > =20 > anydata =3D anything that conforms to the YANG restrictions on XML > (no mixed content, no PIs, interoperable) >=20 > For me (as technical contributor), it seems sensible to have both and > it seem sensible to discourage usage of anyxml (at least withing IETF > data models). I can agree with that, with the above caveat. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Jan 24 01:19:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E6E1A1A47 for ; Sat, 24 Jan 2015 01:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YDbuF4ZxPeR for ; Sat, 24 Jan 2015 01:19:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0EAE1A1A3D for ; Sat, 24 Jan 2015 01:19:38 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:19dd:91e:43b8:d796] (unknown [IPv6:2a01:5e0:29:ffff:19dd:91e:43b8:d796]) by mail.nic.cz (Postfix) with ESMTPSA id 5C8781403D3; Sat, 24 Jan 2015 10:19:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422091177; bh=ONNL977K2z1Nc4Oc79lLT5Vy7+ie3m83andjUMJNVW8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XZBT5tY0n1+akiqBkX6n81mNxcmHBfqqrcIYwEJxONmHEP0atPVhW3MiQNLg6AOJn ydzleIycqKUEw/JpinWMWC8aIOhmrY6e+9gTiFwlFYuZ+LeGgSsQ0bJUGVQhlF1Svn 9mCssISYW6xd4esxUC5r5RS814uCtvuprGxBsrDI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 24 Jan 2015 10:19:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F111C42-5842-434B-92BD-8FB461521560@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 09:19:43 -0000 > On 24 Jan 2015, at 06:53, Andy Bierman wrote: >=20 > On Fri, Jan 23, 2015 at 9:20 PM, Ladislav Lhotka = wrote: >> Hi, >>=20 >> I think there is also a use case where anydata conveys information = that has some non-YANG schema. One example might be an Internet kiosk = whose web pages can be edited through NETCONF. For this purpose it would = actually be best to simply rename anyxml to anydata. >>=20 >=20 > I do not agree with this use-case. > It does not exist in real implementations. We won=E2=80=99t get very far if we limit ourselves to things that = already exist in real implementations. > Mixed mode XML is complicated and standard translation > to JSON is not really worth the effort it would take. Any XML parser is able to parse mixed content. It is not our business to = define translations of anyxml content from XML to JSON or vice versa. >=20 > IMO mixed mode should not be supported by anydata. It is already supported by anyxml. And it=E2=80=99s not only about mixed = content. There is a lot of XML stuff around and some cannot be modelled = with YANG. As another example, one might want to use anyxml for = transporting OS X plist files.=20 Lada >=20 >> Lada >=20 > Andy >=20 >>=20 >>> On 23 Jan 2015, at 18:11, Andy Bierman wrote: >>>=20 >>> Hi, >>>=20 >>> Sometimes it helps to agree on the actual problems that >>> need to be solved, before we endlessly debate solutions. >>> I can only think of 4 use case classes for anydata. >>>=20 >>>=20 >>> Use case 1: root >>> ----------------------- >>> Description: The anydata node MUST be a container (JSON object) >>> and the child nodes MUST be top-level YANG data nodes >>> supported by the server (i.e., TL-nodes defined in the YANG modules >>> advertised by the server) >>>=20 >>> Context: rpc/input and rpc/output >>>=20 >>> Examples: edit-config node, get-config node >>>=20 >>>=20 >>> Use case 2: fixed unknown schema node >>> ------------------------------------------------------- >>> Description: The anydata node MUST be a container (JSON object) >>> and the child nodes MUST be instances of a specific YANG. >>> data-def-stmt, which does not have to be a TL-node. >>> The specific YANG object is not known to the server. >>>=20 >>> Context: data-model dependent; could be abstract data structure, >>> notification, operational data >>>=20 >>> Examples: A pass-through application such as a logger >>>=20 >>>=20 >>> Use case 3: fixed known schema node >>> ----------------------------------------------------- >>> Description: The anydata node MUST be a container (JSON object) >>> and the child nodes MUST be instances of a specific YANG. >>> data-def-stmt, which does not have to be a TL-node. >>> The specific YANG object is known to the server >>> in some ad-hoc out-of-band manner. No machine-readable >>> base YANG statements indicate the actual schema node. >>>=20 >>> Context: data-model dependent; could be abstract data structure, >>> notification, operational data >>>=20 >>> Examples: YANG Mount >>>=20 >>>=20 >>> Use case 4: dynamic schema node >>> ------------------------------------------------- >>> Description: The anydata node MUST be a container (JSON object) >>> and the child nodes MUST be instances of any YANG. >>> data-def-stmt, which does not have to be a TL-node. >>> The specific YANG object may be known to the server >>> in some ad-hoc out-of-band manner. No machine-readable >>> base YANG statements indicate the actual schema node. >>>=20 >>> Context: rpc/input, rpc/output, ??? >>>=20 >>> Examples: YANG Patch >>>=20 >>>=20 >>> Summary >>> -------------- >>> In each case, it should be OK to encode simple nodes as strings >>> and complex nodes as containers. The end consumer that is >>> expected to know the correct schema can convert from the >>> string to the correct YANG type. There are corner cases >>> such as instance-identifier and QNames (e.g., identityref), >>> but I think these can also be handled correctly if specified >>> in the netmod-yang-json (and metadata) drafts in enough detail. >>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Jan 24 09:25:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007901A6F01 for ; Sat, 24 Jan 2015 09:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF_kNGlJQS9t for ; Sat, 24 Jan 2015 09:25:52 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442CD1A1B5D for ; Sat, 24 Jan 2015 09:25:52 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id f15so2245222lbj.5 for ; Sat, 24 Jan 2015 09:25:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=3Qeplukpa5YUO2oUMgCvLb0hPzEVzkM4DKE6z4xyjog=; b=OH7UTAW/MpwDB2HPF6dWngBhvB/gysfaGUSp5mM53i5p5w1p9sEqFAW4cl66V7Q9dY D7Xh3FHWJ2vg4VqIg5WHkFv6y7YrfRqEJXPHT1WtF18knBmDshiHbiPFvodYiHa5Zl3Z shkcYlXlw+P4sxdQwdGZ5lreoyPYq1LQfjF3UTFwPJAddSiKsL0wUQTs+wMas5UY41PT VyFpn892NiBqfoOw+GHfY2yCiaoZhPRKhAT6GKoqKtcnptr7HveVcqcAmxvZvnF3obJR RarzGnKbNMbZmlzn0oJYJa+gocZRR4o0JYpP96lA/rFrGvCbJ6/77TSBun//L5/jaxYy cGtA== X-Gm-Message-State: ALoCoQkVCJwLMbTUaS5UeJcScim5WYP32GrtXd7TaFVJuqCIAYUnoN2hFaplcQyoguCpBQQmTG4m MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr12979208lbv.21.1422120350560; Sat, 24 Jan 2015 09:25:50 -0800 (PST) Received: by 10.112.160.41 with HTTP; Sat, 24 Jan 2015 09:25:50 -0800 (PST) In-Reply-To: <20150124082543.GA43523@elstar.local> References: <20150124082543.GA43523@elstar.local> Date: Sat, 24 Jan 2015 09:25:50 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 17:25:54 -0000 On Sat, Jan 24, 2015 at 12:25 AM, Juergen Schoenwaelder wrote: > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >> Hi, >> >> I think there is also a use case where anydata conveys information that = has some non-YANG schema. One example might be an Internet kiosk whose web = pages can be edited through NETCONF. For this purpose it would actually be = best to simply rename anyxml to anydata. >> > > My understanding is this: > > anyxml =3D any XML (including mixed content, PIs, whatever, not > necessarily interoperable) Will "anyxml" be deprecated or not? If YANG had a real conformance model like SMIv2, this would matter. > > anydata =3D anything that conforms to the YANG restrictions on XML > (no mixed content, no PIs, interoperable) > > For me (as technical contributor), it seems sensible to have both and > it seem sensible to discourage usage of anyxml (at least withing IETF > data models). > +1 The modules have to get past YANG Doctors to get published in RFCs. I am not likely to ever approve the use of anyxml, or the use of anydata instead of a real data node definition. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From nobody Sun Jan 25 03:31:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51D41A0318 for ; Sun, 25 Jan 2015 03:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50zykIhBiRAX for ; Sun, 25 Jan 2015 03:31:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E78E01A0396 for ; Sun, 25 Jan 2015 03:31:21 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id F38781280453 for ; Sun, 25 Jan 2015 12:31:20 +0100 (CET) Date: Sun, 25 Jan 2015 12:33:24 +0100 (CET) Message-Id: <20150125.123324.274444767614266011.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] conformance problem X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 11:31:24 -0000 Hi, I had an action point from the virtual interim 2014-12-17 to write down some conformance axioms and use cases, so that we have something to validate proposed solutions against. This is now done in draft-bjorklund-yang-conformance-problem-00, also available in html format at https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/draft-bjorklund-yang-conformance-problem.html /martin From nobody Mon Jan 26 01:17:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF581A87E4 for ; Mon, 26 Jan 2015 01:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZuAY7LWV-nF for ; Mon, 26 Jan 2015 01:17:32 -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 93CDD1A8773 for ; Mon, 26 Jan 2015 01:17:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOK75147; Mon, 26 Jan 2015 09:17:30 +0000 (GMT) Received: from SZXEML428-HUB.china.huawei.com (10.82.67.183) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 09:17:24 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.136]) by szxeml428-hub.china.huawei.com ([10.82.67.183]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 17:16:56 +0800 From: wangzitao To: "netmod@ietf.org" Thread-Topic: [Netmod] A new version of I-D, draft-wang-netmod-yang-policy-dm-00.txt Thread-Index: AdA5SNO0Ji+sgR3nSNGidYAgPVay8Q== Date: Mon, 26 Jan 2015 09:16:55 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EABE72E5szxeml501mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] [Netmod] A new version of I-D, draft-wang-netmod-yang-policy-dm-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 09:17:34 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EABE72E5szxeml501mbxchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, All: We have submitted a new draft to present a common core YANG data model for = network policies. Please help review and comment on this draft. Thanks in advance. Best Regard! -Michael A new version of I-D, draft-wang-netmod-yang-policy-dm-00.txt has been successfully submitted by Zitao Wang and posted to the IETF reposi= tory. Name: draft-wang-netmod-yang-policy-dm Revision: 00 Title: Network Policy YANG Data Model Document date: 2015-01-26 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-wang-netmod-yang-= policy-dm-00.txt Status: https://datatracker.ietf.org/doc/draft-wang-netmod-yang-pol= icy-dm/ Htmlized: http://tools.ietf.org/html/draft-wang-netmod-yang-policy-dm= -00 Abstract: This document describes a common core YANG data model for network policies. The common core model can be augmented by additional YANG modules defining data models for policy related protocols and functions to support various different network applications (such as Constraint based Routing, Network QoS, Traffic engineering, network management etc). The core policy data model provides common building blocks for such extensions - policy information bases, policy related protocols. --_000_E6BC9BBCBCACC246846FC685F9FF41EABE72E5szxeml501mbxchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, All:

We have submitted a new draft t= o present a common core YANG data model for network policies.

Please help review and comment = on this draft.

Thanks in advance.

Best Regard!<= /p>

-Michael

 

 

 

A new version of I-D, draft-= wang-netmod-yang-policy-dm-00.txt

has been successfully submit= ted by Zitao Wang and posted to the IETF repository.

 

Name:    = ;           draft-wang-ne= tmod-yang-policy-dm

Revision:  00

Title:   &nbs= p;            &= nbsp; Network Policy YANG Data Model

Document date:  &n= bsp;    2015-01-26

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           19

URL:    =         http://www.ietf.org/internet-drafts/draft-wang-netmod-yang-policy-dm-00.txt=

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/=

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-wang-netmod-yang-policy-dm-00

 

 

Abstract:<= /p>

   This document d= escribes a common core YANG data model for network

   policies. = The common core model can be augmented by additional YANG

   modules definin= g data models for policy related protocols and

   functions to su= pport various different network applications (such as

   Constraint base= d Routing, Network QoS, Traffic engineering, network

   management etc)= .  The core policy data model provides common building

   blocks for such= extensions - policy information bases, policy related

   protocols.=

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EABE72E5szxeml501mbxchina_-- From nobody Mon Jan 26 04:49:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0DE1A8A86 for ; Mon, 26 Jan 2015 04:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJoAmX-b7oiB for ; Mon, 26 Jan 2015 04:49: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 312A21A8A81 for ; Mon, 26 Jan 2015 04:49: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 02B3F1046; Mon, 26 Jan 2015 13:49:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rv_GEbahbft0; Mon, 26 Jan 2015 13:49:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jan 2015 13:49:51 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5A4820036; Mon, 26 Jan 2015 13:49:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id swLqIwfqDazW; Mon, 26 Jan 2015 13:49:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C36C420035; Mon, 26 Jan 2015 13:49:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E10C230EEFAB; Mon, 26 Jan 2015 13:49:47 +0100 (CET) Date: Mon, 26 Jan 2015 13:49:46 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150126124944.GB49835@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20150124082543.GA43523@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 12:49:55 -0000 On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: > > > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder wrote: > > > > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: > >> Hi, > >> > >> I think there is also a use case where anydata conveys information that has some non-YANG schema. One example might be an Internet kiosk whose web pages can be edited through NETCONF. For this purpose it would actually be best to simply rename anyxml to anydata. > >> > > > > My understanding is this: > > > > anyxml = any XML (including mixed content, PIs, whatever, not > > necessarily interoperable) > > Yes, but I’d also like to have a symmetric rule for JSON encoding, i. e. any valid JSON value. > I am strongly against adding statements for every encoding that comes along. We kind of learned that anyxml is problematic and hence it was suggested to have an anydata type since it is restricted to anything that can be defined in YANG. This is a sensible type from the perspective of YANG. Having any is in my view not helpful since it is by definition not interoperable (and for me it is a layering violation as well). During this discussion, we did also touch on the JSON I-D. Perhaps a few things to clarify: 1) I am fine with encoding values into I-JSON taking YANG schema information into account. (I do not insist everything has to be encoded as a string.) 2) I am not fine with receivers failing because of a JSON type mismatch. I believe receivers MUST do any conversion necessary should the received JSON type not match the YANG type. (That is "42" must be interpreted as 42 if YANG says it is an int and "False" must be interpreted as False if YANG says the leaf is of type boolean. 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON document saying the encoding of anyxml is implementation dependent (because we would say clearly in YANG 1.1 that anyxml is in the general case non-interoperable). 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON document needs to specify how anydata is encoded in an interoperable way. And it needs to clarify how 2) applies, that is, at the point in time where anydata content is matched against a datamodel, conversions MUST be applied as necessary. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 06:58:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619041A8BBE for ; Mon, 26 Jan 2015 06:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC-JwEUU7e54 for ; Mon, 26 Jan 2015 06:58:47 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 034041A8BB2 for ; Mon, 26 Jan 2015 06:58:47 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 740111CC048F; Mon, 26 Jan 2015 15:58:50 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20150126124944.GB49835@elstar.local> References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 26 Jan 2015 15:58:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 14:58:49 -0000 Juergen Schoenwaelder writes: > On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: >>=20 >> > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder wrote: >> >=20 >> > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >> >> Hi, >> >>=20 >> >> I think there is also a use case where anydata conveys information th= at has some non-YANG schema. One example might be an Internet kiosk whose w= eb pages can be edited through NETCONF. For this purpose it would actually = be best to simply rename anyxml to anydata. >> >>=20 >> >=20 >> > My understanding is this: >> >=20 >> > anyxml =3D any XML (including mixed content, PIs, whatever, not >> > necessarily interoperable) >>=20 >> Yes, but I=E2=80=99d also like to have a symmetric rule for JSON encodin= g, i. e. any valid JSON value.=20 >> > > I am strongly against adding statements for every encoding that comes > along. We kind of learned that anyxml is problematic and hence it was I didn't say that. My proposal is to have the same rule for all encodings, including XML: anyxml value is any content that's well-formed for the given encoding. > suggested to have an anydata type since it is restricted to anything > that can be defined in YANG. This is a sensible type from the > perspective of YANG. Having any is in my view not > helpful since it is by definition not interoperable (and for me it is > a layering violation as well). > > During this discussion, we did also touch on the JSON I-D. Perhaps a few > things to clarify: > > 1) I am fine with encoding values into I-JSON taking YANG schema > information into account. (I do not insist everything has to be > encoded as a string.) OK. > > 2) I am not fine with receivers failing because of a JSON type > mismatch. I believe receivers MUST do any conversion necessary > should the received JSON type not match the YANG type. (That is > "42" must be interpreted as 42 if YANG says it is an int and > "False" must be interpreted as False if YANG says the leaf is of > type boolean. I disagree. The Postel principle you referred to asks senders to be strict, but a sender that's aware of the YANG data model (and therefore knows 42 is an integer) has no good reason for *not encoding* it as a number. You seem to be catering for senders that produce valid XML and then apply YANG-unaware XML->JSON conversion. But this won't work anyway, e.g. for single-entry lists and leaf-lists. > > 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON > document saying the encoding of anyxml is implementation dependent > (because we would say clearly in YANG 1.1 that anyxml is in the > general case non-interoperable). OK. > > 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON > document needs to specify how anydata is encoded in an > interoperable way. And it needs to clarify how 2) applies, that is, > at the point in time where anydata content is matched against a > datamodel, conversions MUST be applied as necessary. The JSON encoding spec *could* define a default schema-less XML<->JSON conv= ersion to be applied to an anydata node that doesn't define anything specific.=20 I think 2) doesn't apply at all for an anydata node - it's outside the scope for YANG. Lada > > /js > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 26 07:08:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070B91A9025 for ; Mon, 26 Jan 2015 07:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_BACKHAIR_34=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmUFm1YitUmd for ; Mon, 26 Jan 2015 07:08:25 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8C71A8918 for ; Mon, 26 Jan 2015 07:08:24 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id ge10so8121381lab.11 for ; Mon, 26 Jan 2015 07:08:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VRxD6xJ4Nuxa6d0jrdBJBeItzKDQcncIP5gSy40K2Ec=; b=UvjAw8Uq8ug79uP5t/dmUtZYst52YjjXsLDU4keaFJ1aj/u5ywSGO8jR3Uwuanzw+Z xZCYzt8iho2uBPP8ohBu5CWJw3GmIrJjAi31uyvrXnChs+vTMy5WEBVl+BLJfbMHRs7H nSh1FFEHUahEmnzMHCGaI3T5LDiJTzwkG+LLqX5oM2C6L6vgsEis28SageBAPcb6/lZz LSjl9vlNKsrVJ6pw0lLvDB2z+mB48icvvWi1EjHyRevN5SXXjQEAk3+QWR6krZ0lvI87 BkndlV3PDJxYTcMTdSsFMLooWOi8k5mODJQKYgzMqUEGvScyOng6V7xqT/O8tIN2/yO5 IqEA== X-Gm-Message-State: ALoCoQnqjRPI3FeIXnupi+uSZ8Wzht5zO/3FNGapAGmliLu3Iaqv17wR3fvaKP0JVcJbFDyDxaHZ MIME-Version: 1.0 X-Received: by 10.152.42.164 with SMTP id p4mr13786000lal.45.1422284903277; Mon, 26 Jan 2015 07:08:23 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 26 Jan 2015 07:08:23 -0800 (PST) In-Reply-To: References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> Date: Mon, 26 Jan 2015 07:08:23 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:08:28 -0000 On Mon, Jan 26, 2015 at 6:58 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > >> On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: >>> >>> > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder wrote: >>> > >>> > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >>> >> Hi, >>> >> >>> >> I think there is also a use case where anydata conveys information t= hat has some non-YANG schema. One example might be an Internet kiosk whose = web pages can be edited through NETCONF. For this purpose it would actually= be best to simply rename anyxml to anydata. >>> >> >>> > >>> > My understanding is this: >>> > >>> > anyxml =3D any XML (including mixed content, PIs, whatever, not >>> > necessarily interoperable) >>> >>> Yes, but I=E2=80=99d also like to have a symmetric rule for JSON encodi= ng, i. e. any valid JSON value. >>> >> >> I am strongly against adding statements for every encoding that comes >> along. We kind of learned that anyxml is problematic and hence it was > > I didn't say that. My proposal is to have the same rule for all > encodings, including XML: anyxml value is any content that's well-formed > for the given encoding. > >> suggested to have an anydata type since it is restricted to anything >> that can be defined in YANG. This is a sensible type from the >> perspective of YANG. Having any is in my view not >> helpful since it is by definition not interoperable (and for me it is >> a layering violation as well). >> >> During this discussion, we did also touch on the JSON I-D. Perhaps a few >> things to clarify: >> >> 1) I am fine with encoding values into I-JSON taking YANG schema >> information into account. (I do not insist everything has to be >> encoded as a string.) > > OK. > >> >> 2) I am not fine with receivers failing because of a JSON type >> mismatch. I believe receivers MUST do any conversion necessary >> should the received JSON type not match the YANG type. (That is >> "42" must be interpreted as 42 if YANG says it is an int and >> "False" must be interpreted as False if YANG says the leaf is of >> type boolean. > > I disagree. The Postel principle you referred to asks senders to be > strict, but a sender that's aware of the YANG data model (and therefore > knows 42 is an integer) has no good reason for *not encoding* it as a > number. > The YANG type is anyxml, which means there is no YANG type. It makes no sense to say "the server knows this is an int". The YANG schema says "anyxml". Period. > You seem to be catering for senders that produce valid XML and then > apply YANG-unaware XML->JSON conversion. But this won't work anyway, > e.g. for single-entry lists and leaf-lists. > I read this quite differently. The Postel Principle says be liberal in what you accept. It is quite trivial for the receiver to convert to a string which can then be parsed by the end-user and converted to a YANG type. >> >> 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON >> document saying the encoding of anyxml is implementation dependent >> (because we would say clearly in YANG 1.1 that anyxml is in the >> general case non-interoperable). > > OK. > >> >> 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON >> document needs to specify how anydata is encoded in an >> interoperable way. And it needs to clarify how 2) applies, that is, >> at the point in time where anydata content is matched against a >> datamodel, conversions MUST be applied as necessary. > > The JSON encoding spec *could* define a default schema-less XML<->JSON co= nversion > to be applied to an anydata node that doesn't define anything specific. > > I think 2) doesn't apply at all for an anydata node - it's outside the > scope for YANG. > > Lada > >> >> /js >> Andy >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jan 26 07:32:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D844B1A9064 for ; Mon, 26 Jan 2015 07:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_BACKHAIR_34=1, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlgYggpYSxX2 for ; Mon, 26 Jan 2015 07:32:35 -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 86ED61A902F for ; Mon, 26 Jan 2015 07:32:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8F5E4A9B; Mon, 26 Jan 2015 16:32:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id a3PO5UEW13Cj; Mon, 26 Jan 2015 16:32:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jan 2015 16:32:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70D6220037; Mon, 26 Jan 2015 16:32:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jlukPsaqMTG1; Mon, 26 Jan 2015 16:32:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1688F20036; Mon, 26 Jan 2015 16:32:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 514D430EF605; Mon, 26 Jan 2015 16:32:26 +0100 (CET) Date: Mon, 26 Jan 2015 16:32:26 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150126153224.GA50403@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:32:38 -0000 On Mon, Jan 26, 2015 at 03:58:45PM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: > >> > >> > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder wrote: > >> > > >> > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: > >> >> Hi, > >> >> > >> >> I think there is also a use case where anydata conveys information that has some non-YANG schema. One example might be an Internet kiosk whose web pages can be edited through NETCONF. For this purpose it would actually be best to simply rename anyxml to anydata. > >> >> > >> > > >> > My understanding is this: > >> > > >> > anyxml = any XML (including mixed content, PIs, whatever, not > >> > necessarily interoperable) > >> > >> Yes, but I’d also like to have a symmetric rule for JSON encoding, i. e. any valid JSON value. > >> > > > > I am strongly against adding statements for every encoding that comes > > along. We kind of learned that anyxml is problematic and hence it was > > I didn't say that. My proposal is to have the same rule for all > encodings, including XML: anyxml value is any content that's well-formed > for the given encoding. Maybe, it is non-interoperable, so it is something I do not care about much. > > suggested to have an anydata type since it is restricted to anything > > that can be defined in YANG. This is a sensible type from the > > perspective of YANG. Having any is in my view not > > helpful since it is by definition not interoperable (and for me it is > > a layering violation as well). > > > > During this discussion, we did also touch on the JSON I-D. Perhaps a few > > things to clarify: > > > > 1) I am fine with encoding values into I-JSON taking YANG schema > > information into account. (I do not insist everything has to be > > encoded as a string.) > > OK. > > > > > 2) I am not fine with receivers failing because of a JSON type > > mismatch. I believe receivers MUST do any conversion necessary > > should the received JSON type not match the YANG type. (That is > > "42" must be interpreted as 42 if YANG says it is an int and > > "False" must be interpreted as False if YANG says the leaf is of > > type boolean. > > I disagree. The Postel principle you referred to asks senders to be > strict, but a sender that's aware of the YANG data model (and therefore > knows 42 is an integer) has no good reason for *not encoding* it as a > number. > > You seem to be catering for senders that produce valid XML and then > apply YANG-unaware XML->JSON conversion. But this won't work anyway, > e.g. for single-entry lists and leaf-lists. Yes, I do forsee situations where the _encoder_ does not know the YANG type. There were a couple mentioned in the thread I think. Yes, the receiver likely also has to be lenient with one element arrays that map to a container or vice versa. > > 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON > > document saying the encoding of anyxml is implementation dependent > > (because we would say clearly in YANG 1.1 that anyxml is in the > > general case non-interoperable). > > OK. > > > > > 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON > > document needs to specify how anydata is encoded in an > > interoperable way. And it needs to clarify how 2) applies, that is, > > at the point in time where anydata content is matched against a > > datamodel, conversions MUST be applied as necessary. > > The JSON encoding spec *could* define a default schema-less XML<->JSON conversion > to be applied to an anydata node that doesn't define anything specific. > > I think 2) doesn't apply at all for an anydata node - it's outside the > scope for YANG. Why is anydata outside the scope of YANG? I guess I disagree with this statement. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 27 01:09:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29C1A8739 for ; Tue, 27 Jan 2015 01:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GXhoo-9oI9U for ; Tue, 27 Jan 2015 01:09:47 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56AC1A1DE2 for ; Tue, 27 Jan 2015 01:09:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 87A05736 for ; Tue, 27 Jan 2015 10:09:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Y7WV6ozMjBKU for ; Tue, 27 Jan 2015 10:09:37 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 27 Jan 2015 10:09:44 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4569820036 for ; Tue, 27 Jan 2015 10:09:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Wua-d79Z2kxt; Tue, 27 Jan 2015 10:09:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9BA620035; Tue, 27 Jan 2015 10:09:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 089CF30FD26B; Tue, 27 Jan 2015 10:09:40 +0100 (CET) Date: Tue, 27 Jan 2015 10:09:39 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150127090937.GA77252@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] minutes of the NETMOD 2015-01-21 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 09:09:49 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2015-01-21 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2015-01-21-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 11th YANG 1.1 Virtual Interim Wednesday, January 21, 2015, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants AB = Andy Bierman IB = Ignas Bagdonas JS = Juergen Schoenwaelder KW = Kent Watsen LL = Lada Lhotka MB = Martin Bjoerklund PO = Peyman Owladi * Agenda Items - VRFY Y09 (no consensus) - VRFY Y16 (netconf-capability-change notification) - VRFY Y34 (difference between Y34-02 and Y34-04) - OPEN Y18 (MB action done) - OPEN Y57 - OPEN Y58 (move to EDIT once NETCONF signals OK for NACM update?) - OPEN Y45 (factor conformance and update rules out of 6020bis?) - OPEN Y26 (can we assign someone to this?) * Y09 introduce optional keys MB: I do not understand how default values solve a problem, are defaults always included in the instance identifier? AB: Yes, every key has to have value in an instance identifier. AB: You may leave out key values in a create request. AB: Y09-03 is a way of documenting that a certain value acts as a special value. KW: How does this map to SQL? PO: In SQL, the compound key must be unique. MB: Y09-03 requires you to invent this special value, just to indicate that no value is there. AB: We have done this for years in SMIv2. AB: I think this change falls out of the scope of the 1.1 update. PO: Default values are a way to not expose the special NULL value used by implementations. AB: Changing the instance-identifier type has ripple effects. JS: We have three choices: declare Y09 dead or find agreement on either Y09-02 or Y09-03 (with a default to declare this dead if we do not find agreement) PO: What is the value of Y09-03 despite that you can leave out a key in a create message? PO: Can I leave out default key values or does an instance identifier always contain all key components? PO: How does with work with filtering? LL: If you leave out a key in a subtree filter, you will get all not just the default. MB: How will Y09-03 interact with defaults basic mode? It works fine with explicit mode, but will it work with report-all or trim mode? JS: I am concerned about changing the value set of a base type. I do not see consensus developing for Y09-02. So we either see whether we can find consensus on Y09-03 or if do not see the value of it, we simply declare Y09 dead. PO: I do not see the value in Y09-03, but it does not seem to hurt either. MB: Note that NACM does not use instance-identifier literally. MB: Is this not the same as extending the range? AB: But this is a base type. PO: Can you go from an int32 to an int64? MB: No, you can not. KW: Is it worth solving this problem at all? LL: This is really important for routing modules since we may resort to artificial keys. Proposal: Declare Y09 dead since the goal (optional keys) results in changes that reach beyond the scope of the YANG 1.1 effort. * Y60 yang 1.1 upgrade and YANG 1.0 coexistence KW: What happens if you load a YANG 1.1 module into a server? MB: We need to have text concerning coexistence, should we track this as a separate issue? JS: The interesting case might be a NETCONF server supporting YANG 1.1 hitting a NETCONF 1.0-only client. But ideally, clients upgrade quickly and this is a corner case in practice. KW: We may also have to talk about module update rules. Proposal: Create a new issue Y60 in order to track this. * Y16 module advertisement optimization JS: We have three options: 1) add a more specific notification 2) augment a module-set-id into the existing netconf-capability-change notification 3) simply give advice that once a client receives a netconf-capability-change notification, it should retrieve and check the module-set-id AB: Why would a client treat a module change different than any other capability change? AB: Are we only suppressing module advertisements in the hello? MB: Yes, we are only caching module advertisements. Proposal: Augment module-set-id into the existing notification. * Y34 remove/deprecate/replace the 'anyxml' statement AB: The main difference is that root is restricted to top-level data nodes while anydata is not. MB: The non-restricted version is needed for YANG patch. AB: There are three cases: 1) fixed top-level data nodes, 2) fixed arbitrary data nodes, 3) compile-time decided data nodes (this is what YANG patch uses). JS: What is the benefit of restricting this to the root node? MB: It makes it easier to parse the XML since the server knows that it is a root node. AB: We only allow ncx:root in RPCs, not in datastores. MB: I am not sure which problem Y34-04 solves. AB: I could also live with dropping Y34. MB: In practice, you often use anydata when you write anyxml. AB: YANG patch will continue to use anyxml. MB: How does that work with JSON encoding? AB: Dynamic type conversion as needed. MB: If we use anyxml in YANG patch, is the result interoperable over JSON? MB: The current JSON mapping is silent how anyxml is encoded. MB: We could use anyxml in YANG patch and then detail there how this is encoded using JSON. JS: This may be fine until we hit the usage of this kind and several anyxml usage today are already anydata. We did run out of time, hopefully we can discuss this further on the mailing list and resolve it before the next meeting (so we can get back to OPEN issues.) --UugvWAfsgieZRqgk-- From nobody Tue Jan 27 06:46:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C421B1A8765 for ; Tue, 27 Jan 2015 06:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLc-a5F30BcW for ; Tue, 27 Jan 2015 06:46:29 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 320F71A876C for ; Tue, 27 Jan 2015 06:46:29 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 840131CC03BB; Tue, 27 Jan 2015 15:46:33 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 27 Jan 2015 15:46:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 14:46:32 -0000 Andy Bierman writes: > On Mon, Jan 26, 2015 at 6:58 AM, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >> >>> On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: >>>> >>>> > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder wrote: >>>> > >>>> > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >>>> >> Hi, >>>> >> >>>> >> I think there is also a use case where anydata conveys information = that has some non-YANG schema. One example might be an Internet kiosk whose= web pages can be edited through NETCONF. For this purpose it would actuall= y be best to simply rename anyxml to anydata. >>>> >> >>>> > >>>> > My understanding is this: >>>> > >>>> > anyxml =3D any XML (including mixed content, PIs, whatever, not >>>> > necessarily interoperable) >>>> >>>> Yes, but I=E2=80=99d also like to have a symmetric rule for JSON encod= ing, i. e. any valid JSON value. >>>> >>> >>> I am strongly against adding statements for every encoding that comes >>> along. We kind of learned that anyxml is problematic and hence it was >> >> I didn't say that. My proposal is to have the same rule for all >> encodings, including XML: anyxml value is any content that's well-formed >> for the given encoding. >> >>> suggested to have an anydata type since it is restricted to anything >>> that can be defined in YANG. This is a sensible type from the >>> perspective of YANG. Having any is in my view not >>> helpful since it is by definition not interoperable (and for me it is >>> a layering violation as well). >>> >>> During this discussion, we did also touch on the JSON I-D. Perhaps a few >>> things to clarify: >>> >>> 1) I am fine with encoding values into I-JSON taking YANG schema >>> information into account. (I do not insist everything has to be >>> encoded as a string.) >> >> OK. >> >>> >>> 2) I am not fine with receivers failing because of a JSON type >>> mismatch. I believe receivers MUST do any conversion necessary >>> should the received JSON type not match the YANG type. (That is >>> "42" must be interpreted as 42 if YANG says it is an int and >>> "False" must be interpreted as False if YANG says the leaf is of >>> type boolean. >> >> I disagree. The Postel principle you referred to asks senders to be >> strict, but a sender that's aware of the YANG data model (and therefore >> knows 42 is an integer) has no good reason for *not encoding* it as a >> number. >> > > The YANG type is anyxml, which means there is no YANG type. > It makes no sense to say "the server knows this is an int". > The YANG schema says "anyxml". Period. Juergen's item #2 above clearly talks about other nodes than anyxml. > > >> You seem to be catering for senders that produce valid XML and then >> apply YANG-unaware XML->JSON conversion. But this won't work anyway, >> e.g. for single-entry lists and leaf-lists. >> > > > I read this quite differently. > The Postel Principle says be liberal in what you accept. No, it says this: "Be conservative in what you send, be liberal in what you accept." In fact, it's not meant as a guideline for protocol designers but rather for protocol users: the sender should comply with the protocol, and the receiver should reasonably tolerate protocol violations. > It is quite trivial for the receiver to convert to a string which > can then be parsed by the end-user and converted to a YANG type. It's equally trivial, e.g., to convert a received value of 42.0 to an integer and I don't mind if a receiver follows the Postel principle and performs this conversion - despite the fact that 42.0 is not a valid value for a YANG integer. Lada > > >>> >>> 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON >>> document saying the encoding of anyxml is implementation dependent >>> (because we would say clearly in YANG 1.1 that anyxml is in the >>> general case non-interoperable). >> >> OK. >> >>> >>> 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON >>> document needs to specify how anydata is encoded in an >>> interoperable way. And it needs to clarify how 2) applies, that is, >>> at the point in time where anydata content is matched against a >>> datamodel, conversions MUST be applied as necessary. >> >> The JSON encoding spec *could* define a default schema-less XML<->JSON c= onversion >> to be applied to an anydata node that doesn't define anything specific. >> >> I think 2) doesn't apply at all for an anydata node - it's outside the >> scope for YANG. >> >> Lada >> >>> >>> /js >>> > > > Andy > >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 27 06:57:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21ED1A8771 for ; Tue, 27 Jan 2015 06:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5NsOsfZ_u9q for ; Tue, 27 Jan 2015 06:57:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EA2FB1A6F2D for ; Tue, 27 Jan 2015 06:57:42 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 272B81CC03BB; Tue, 27 Jan 2015 15:57:48 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20150126153224.GA50403@elstar.local> References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> <20150126153224.GA50403@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 27 Jan 2015 15:57:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 14:57:45 -0000 Juergen Schoenwaelder writes: > On Mon, Jan 26, 2015 at 03:58:45PM +0100, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >> > On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: >> >>=20 >> >> > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder wrote: >> >> >=20 >> >> > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >> >> >> Hi, >> >> >>=20 >> >> >> I think there is also a use case where anydata conveys information= that has some non-YANG schema. One example might be an Internet kiosk whos= e web pages can be edited through NETCONF. For this purpose it would actual= ly be best to simply rename anyxml to anydata. >> >> >>=20 >> >> >=20 >> >> > My understanding is this: >> >> >=20 >> >> > anyxml =3D any XML (including mixed content, PIs, whatever, not >> >> > necessarily interoperable) >> >>=20 >> >> Yes, but I=E2=80=99d also like to have a symmetric rule for JSON enco= ding, i. e. any valid JSON value.=20 >> >> >> > >> > I am strongly against adding statements for every encoding that comes >> > along. We kind of learned that anyxml is problematic and hence it was >>=20 >> I didn't say that. My proposal is to have the same rule for all >> encodings, including XML: anyxml value is any content that's well-formed >> for the given encoding. > > Maybe, it is non-interoperable, so it is something I do not care about > much. > >> > suggested to have an anydata type since it is restricted to anything >> > that can be defined in YANG. This is a sensible type from the >> > perspective of YANG. Having any is in my view not >> > helpful since it is by definition not interoperable (and for me it is >> > a layering violation as well). >> > >> > During this discussion, we did also touch on the JSON I-D. Perhaps a f= ew >> > things to clarify: >> > >> > 1) I am fine with encoding values into I-JSON taking YANG schema >> > information into account. (I do not insist everything has to be >> > encoded as a string.) >>=20 >> OK. >>=20 >> > >> > 2) I am not fine with receivers failing because of a JSON type >> > mismatch. I believe receivers MUST do any conversion necessary >> > should the received JSON type not match the YANG type. (That is >> > "42" must be interpreted as 42 if YANG says it is an int and >> > "False" must be interpreted as False if YANG says the leaf is of >> > type boolean. >>=20 >> I disagree. The Postel principle you referred to asks senders to be >> strict, but a sender that's aware of the YANG data model (and therefore >> knows 42 is an integer) has no good reason for *not encoding* it as a >> number. >>=20 >> You seem to be catering for senders that produce valid XML and then >> apply YANG-unaware XML->JSON conversion. But this won't work anyway, >> e.g. for single-entry lists and leaf-lists. > > Yes, I do forsee situations where the _encoder_ does not know the YANG > type. There were a couple mentioned in the thread I think. Yes, the > receiver likely also has to be lenient with one element arrays that > map to a container or vice versa. I don't agree, this would be S-JSON (sloppy JSON) rather than I-JSON. Using the same logic, one could also require that receivers fix the namespace of a received XML element if the namespace doesn't match the namespace of the YANG node. > >> > 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON >> > document saying the encoding of anyxml is implementation dependent >> > (because we would say clearly in YANG 1.1 that anyxml is in the >> > general case non-interoperable). >>=20 >> OK. >>=20 >> > >> > 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON >> > document needs to specify how anydata is encoded in an >> > interoperable way. And it needs to clarify how 2) applies, that is, >> > at the point in time where anydata content is matched against a >> > datamodel, conversions MUST be applied as necessary. >>=20 >> The JSON encoding spec *could* define a default schema-less XML<->JSON c= onversion >> to be applied to an anydata node that doesn't define anything specific.= =20 >>=20 >> I think 2) doesn't apply at all for an anydata node - it's outside the >> scope for YANG. > > Why is anydata outside the scope of YANG? I guess I disagree with this > statement. Talking about your item #2 in the context of anyxml/anydata is outside the scope of YANG because anyxml/anydata contents have no YANG types. Lada > > /js > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 27 07:09:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69C61A8745 for ; Tue, 27 Jan 2015 07:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_BACKHAIR_34=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0D2Ra4EfIjQA for ; Tue, 27 Jan 2015 07:09:07 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F561A8746 for ; Tue, 27 Jan 2015 07:09:05 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id ge10so13802221lab.11 for ; Tue, 27 Jan 2015 07:09:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pa2TrJkigcQ/GUA3fw+OqI5LCW6zAkUcip2c7+Ns4N4=; b=B8nkLcWWxrsDeMIfnO30PRENsm3eLtGyBJnz0uR85dasoVB83k/VM0EZrSGcstikxf a28Iay3vDUTd3YG21C8hEQCYcsuIUVe5Tw7lP3c2W6fBslOrxQXbOxNSrWDK+EOoC/8b MtAfa/2N5ZefaUE2xXLbkTA9a06kmouRJDri3+qy6O48O6+q4Hclu9jqhfpQDieUEbGR HyJcztYKBNQooZiMGI2wAjnGQn5E65d52l0DMG5WTvlKUYGU3cm+mR7wpvN7zqJFM5w+ 7aMlFrTFA4Bi36AzCwb2pYH/45iB9YNQVKmpUpBWr/OIpacvQe6smatY16c/7f9zHHNh 53Ag== X-Gm-Message-State: ALoCoQlelJNbxKkiVWw93on9KdgEquuaD4FBMbXnIicUhucu6FfOZkr2eFZSgTtlnlz7kHpSKHRp MIME-Version: 1.0 X-Received: by 10.152.87.210 with SMTP id ba18mr2232437lab.3.1422371343862; Tue, 27 Jan 2015 07:09:03 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 27 Jan 2015 07:09:03 -0800 (PST) In-Reply-To: References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> Date: Tue, 27 Jan 2015 07:09:03 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 15:09:09 -0000 On Tue, Jan 27, 2015 at 6:46 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> On Mon, Jan 26, 2015 at 6:58 AM, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder writes: >>> >>>> On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: >>>>> >>>>> > On 24 Jan 2015, at 09:25, Juergen Schoenwaelder wrote: >>>>> > >>>>> > On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >>>>> >> Hi, >>>>> >> >>>>> >> I think there is also a use case where anydata conveys information= that has some non-YANG schema. One example might be an Internet kiosk whos= e web pages can be edited through NETCONF. For this purpose it would actual= ly be best to simply rename anyxml to anydata. >>>>> >> >>>>> > >>>>> > My understanding is this: >>>>> > >>>>> > anyxml =3D any XML (including mixed content, PIs, whatever, not >>>>> > necessarily interoperable) >>>>> >>>>> Yes, but I=E2=80=99d also like to have a symmetric rule for JSON enco= ding, i. e. any valid JSON value. >>>>> >>>> >>>> I am strongly against adding statements for every encoding that comes >>>> along. We kind of learned that anyxml is problematic and hence it was >>> >>> I didn't say that. My proposal is to have the same rule for all >>> encodings, including XML: anyxml value is any content that's well-forme= d >>> for the given encoding. >>> >>>> suggested to have an anydata type since it is restricted to anything >>>> that can be defined in YANG. This is a sensible type from the >>>> perspective of YANG. Having any is in my view not >>>> helpful since it is by definition not interoperable (and for me it is >>>> a layering violation as well). >>>> >>>> During this discussion, we did also touch on the JSON I-D. Perhaps a f= ew >>>> things to clarify: >>>> >>>> 1) I am fine with encoding values into I-JSON taking YANG schema >>>> information into account. (I do not insist everything has to be >>>> encoded as a string.) >>> >>> OK. >>> >>>> >>>> 2) I am not fine with receivers failing because of a JSON type >>>> mismatch. I believe receivers MUST do any conversion necessary >>>> should the received JSON type not match the YANG type. (That is >>>> "42" must be interpreted as 42 if YANG says it is an int and >>>> "False" must be interpreted as False if YANG says the leaf is of >>>> type boolean. >>> >>> I disagree. The Postel principle you referred to asks senders to be >>> strict, but a sender that's aware of the YANG data model (and therefore >>> knows 42 is an integer) has no good reason for *not encoding* it as a >>> number. >>> >> >> The YANG type is anyxml, which means there is no YANG type. >> It makes no sense to say "the server knows this is an int". >> The YANG schema says "anyxml". Period. > > Juergen's item #2 above clearly talks about other nodes than anyxml. > Not sure what this means. If the sender encodes "42" as a string and the final receiver that knows YANG thinks it is an int32, then the receiver will convert the string "42" to the YANG type int32, even though the JSON type was a string instead of a number. This seems clear and hard to interpret as a requirement on the sender. >> >> >>> You seem to be catering for senders that produce valid XML and then >>> apply YANG-unaware XML->JSON conversion. But this won't work anyway, >>> e.g. for single-entry lists and leaf-lists. >>> >> >> >> I read this quite differently. >> The Postel Principle says be liberal in what you accept. > > No, it says this: > > "Be conservative in what you send, be liberal in what you accept." > both parts, yes. > In fact, it's not meant as a guideline for protocol designers but rather > for protocol users: the sender should comply with the protocol, and the > receiver should reasonably tolerate protocol violations. > I disagree >> It is quite trivial for the receiver to convert to a string which >> can then be parsed by the end-user and converted to a YANG type. > > It's equally trivial, e.g., to convert a received value of 42.0 to an > integer and I don't mind if a receiver follows the Postel principle and > performs this conversion - despite the fact that 42.0 is not a valid > value for a YANG integer. But "42.0" does not follow the rules for an int32 so this is a strawman argument. The sender will encode "42" and everything works fine. Even if the sender encodes a JSON number, everything works fine. It is not difficult to convert any JSON type to a YANG type (or reject it instead). > > Lada > Andy >> >> >>>> >>>> 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the JSON >>>> document saying the encoding of anyxml is implementation dependent >>>> (because we would say clearly in YANG 1.1 that anyxml is in the >>>> general case non-interoperable). >>> >>> OK. >>> >>>> >>>> 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON >>>> document needs to specify how anydata is encoded in an >>>> interoperable way. And it needs to clarify how 2) applies, that is, >>>> at the point in time where anydata content is matched against a >>>> datamodel, conversions MUST be applied as necessary. >>> >>> The JSON encoding spec *could* define a default schema-less XML<->JSON = conversion >>> to be applied to an anydata node that doesn't define anything specific. >>> >>> I think 2) doesn't apply at all for an anydata node - it's outside the >>> scope for YANG. >>> >>> Lada >>> >>>> >>>> /js >>>> >> >> >> Andy >> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>>> Fax: +49 421 200 3103 >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Tue Jan 27 07:12:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E661A876C for ; Tue, 27 Jan 2015 07:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_BACKHAIR_34=1, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbtwWvlzbZkV for ; Tue, 27 Jan 2015 07:12:11 -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 88C941A6FFF for ; Tue, 27 Jan 2015 07:12:11 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0B3DEA7F; Tue, 27 Jan 2015 16:12:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cxPDwUayXWkh; Tue, 27 Jan 2015 16:12:00 +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; Tue, 27 Jan 2015 16:12:09 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01EC020037; Tue, 27 Jan 2015 16:12:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UptUnRQTz5QF; Tue, 27 Jan 2015 16:12:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07FF920036; Tue, 27 Jan 2015 16:12:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 58BF03110F46; Tue, 27 Jan 2015 16:12:05 +0100 (CET) Date: Tue, 27 Jan 2015 16:12:04 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150127151202.GA89027@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> <20150126153224.GA50403@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 15:12:14 -0000 On Tue, Jan 27, 2015 at 03:57:41PM +0100, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Mon, Jan 26, 2015 at 03:58:45PM +0100, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder writes: > >> > 2) I am not fine with receivers failing because of a JSON type > >> > mismatch. I believe receivers MUST do any conversion necessary > >> > should the received JSON type not match the YANG type. (That is > >> > "42" must be interpreted as 42 if YANG says it is an int and > >> > "False" must be interpreted as False if YANG says the leaf is of > >> > type boolean. > >> > >> I disagree. The Postel principle you referred to asks senders to be > >> strict, but a sender that's aware of the YANG data model (and therefore > >> knows 42 is an integer) has no good reason for *not encoding* it as a > >> number. > >> > >> You seem to be catering for senders that produce valid XML and then > >> apply YANG-unaware XML->JSON conversion. But this won't work anyway, > >> e.g. for single-entry lists and leaf-lists. > > > > Yes, I do forsee situations where the _encoder_ does not know the YANG > > type. There were a couple mentioned in the thread I think. Yes, the > > receiver likely also has to be lenient with one element arrays that > > map to a container or vice versa. > > I don't agree, this would be S-JSON (sloppy JSON) rather than > I-JSON. Using the same logic, one could also require that receivers fix > the namespace of a received XML element if the namespace doesn't match > the namespace of the YANG node. Sorry Lada, I can't follow your logic. > >> > 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON > >> > document needs to specify how anydata is encoded in an > >> > interoperable way. And it needs to clarify how 2) applies, that is, > >> > at the point in time where anydata content is matched against a > >> > datamodel, conversions MUST be applied as necessary. > >> > >> The JSON encoding spec *could* define a default schema-less XML<->JSON conversion > >> to be applied to an anydata node that doesn't define anything specific. > >> > >> I think 2) doesn't apply at all for an anydata node - it's outside the > >> scope for YANG. > > > > Why is anydata outside the scope of YANG? I guess I disagree with this > > statement. > > Talking about your item #2 in the context of anyxml/anydata is outside > the scope of YANG because anyxml/anydata contents have no YANG types. My statement was that anydata is different from anyxml because we can make it interoperable. #2 applies since anydata may _eventually_ be matched against a data model, but not necessarily at the time the data is encoded. Please go back in this thread to find examples related to mounts etc. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 27 07:58:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B941A883C for ; Tue, 27 Jan 2015 07:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_BACKHAIR_34=1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uisLa9FZObOK for ; Tue, 27 Jan 2015 07:58:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938661A8893 for ; Tue, 27 Jan 2015 07:56:01 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id E1A0B13F7BA; Tue, 27 Jan 2015 16:55:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422374159; bh=cgYCyp1ZJ4tDpOO7OASQ7dJ1YJJubDjsUWOKjktvsM4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=B86tUK5kH6S7CJbeMjvc5R/oO3r8iNRUzkWvVpVkSOxOxpOlSh4JEf/pzsT+9X9pi PSkwTatJzEEYvHqkqbl8TbG/lBB6oD7F6NycER6cqfKTilG5FdOtY8BFskf6osEP+F NLRdUhUoAuW8P9BVfCUOcKmmitFEJ8XJPZazKGWo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150127151202.GA89027@elstar.local> Date: Tue, 27 Jan 2015 16:55:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> <20150126153224.GA50403@elstar.local> <20150127151202.GA89027@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 15:58:49 -0000 > On 27 Jan 2015, at 16:12, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 27, 2015 at 03:57:41PM +0100, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Mon, Jan 26, 2015 at 03:58:45PM +0100, Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder = writes: >=20 >>>>> 2) I am not fine with receivers failing because of a JSON type >>>>> mismatch. I believe receivers MUST do any conversion necessary >>>>> should the received JSON type not match the YANG type. (That is >>>>> "42" must be interpreted as 42 if YANG says it is an int and >>>>> "False" must be interpreted as False if YANG says the leaf is of >>>>> type boolean. >>>>=20 >>>> I disagree. The Postel principle you referred to asks senders to be >>>> strict, but a sender that's aware of the YANG data model (and = therefore >>>> knows 42 is an integer) has no good reason for *not encoding* it as = a >>>> number. >>>>=20 >>>> You seem to be catering for senders that produce valid XML and then >>>> apply YANG-unaware XML->JSON conversion. But this won't work = anyway, >>>> e.g. for single-entry lists and leaf-lists. >>>=20 >>> Yes, I do forsee situations where the _encoder_ does not know the = YANG >>> type. There were a couple mentioned in the thread I think. Yes, the >>> receiver likely also has to be lenient with one element arrays that >>> map to a container or vice versa. >>=20 >> I don't agree, this would be S-JSON (sloppy JSON) rather than >> I-JSON. Using the same logic, one could also require that receivers = fix >> the namespace of a received XML element if the namespace doesn't = match >> the namespace of the YANG node. >=20 > Sorry Lada, I can't follow your logic. I could have an XML encoder that doesn=E2=80=99t know YANG namespace = URIs, so it just encodes all instances as XML elements with null = namespace. Rules for XML encoding could state that the receiver MUST fix = this -but they don=E2=80=99t. Is this really different from your = requirements on JSON encoding? It all comes down to the fact that all encodings are equal but the XML = encoding is more equal. The benefit of JSON is that one can encode = (typed) data structures directly into JSON, and vice versa. Anything = else means extra work. >=20 >>>>> 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON >>>>> document needs to specify how anydata is encoded in an >>>>> interoperable way. And it needs to clarify how 2) applies, that = is, >>>>> at the point in time where anydata content is matched against a >>>>> datamodel, conversions MUST be applied as necessary. >>>>=20 >>>> The JSON encoding spec *could* define a default schema-less = XML<->JSON conversion >>>> to be applied to an anydata node that doesn't define anything = specific.=20 >>>>=20 >>>> I think 2) doesn't apply at all for an anydata node - it's outside = the >>>> scope for YANG. >>>=20 >>> Why is anydata outside the scope of YANG? I guess I disagree with = this >>> statement. >>=20 >> Talking about your item #2 in the context of anyxml/anydata is = outside >> the scope of YANG because anyxml/anydata contents have no YANG types. >=20 > My statement was that anydata is different from anyxml because we can > make it interoperable. #2 applies since anydata may _eventually_ be > matched against a data model, but not necessarily at the time the data > is encoded. Please go back in this thread to find examples related to > mounts etc. As soon as the data are extracted and matched against a new YANG data = model, it=E2=80=99s no more anydata and standard YANG rules apply. = However, I assume two other cases are possible: - some schema or protocol exists for the anydata content but it is not = expressed in YANG, - there is no schema. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 27 08:14:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282F61A8831 for ; Tue, 27 Jan 2015 08:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_BACKHAIR_34=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhFqo_lRouJg for ; Tue, 27 Jan 2015 08:14:03 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B76F1A8874 for ; Tue, 27 Jan 2015 08:13:57 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so14169902lab.10 for ; Tue, 27 Jan 2015 08:13:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PD4KpNQR8SNul1pLt8iXU0mFteNGun1UyGVFHMCBCIE=; b=AGdqiE2b1vFU/HEJUIEOZK2ondDenL4ejkz/Yf9PDvlo/JTMy3ASSc/B9rodU6D7oq 34Q+kWfSkB2qcfaiK0srT/yEiYpPS67LW+DLX0V3i4EzYFaTWntAJRI6nYkbsShX6I33 P0/lZW72dK2D1u6Y/M5Cex/u/nsEIL9hsBEiwnOerb3V6KAKE81/P8yfuFnMAeyaoesF DNXg42ERxZCAR6xxlRNFZQo252GXIKneciQRBF5k5mxcNA7X9TRRyS8a2q+uEy1XQW0m +BM2kDaN3LpmqH3rmUucs8rqD6rvu7kjXxMgPNpin+Ug3YcIGTbLBfguYnuFrMEvpg/l OBBw== X-Gm-Message-State: ALoCoQnEifJbjbrKG5v1ukr+U/WNDEkoa9cnjFZEwkdwGG6sAgxVHUAlQ4Dci+4VaTebljndktDb MIME-Version: 1.0 X-Received: by 10.112.148.34 with SMTP id tp2mr2672787lbb.94.1422375235703; Tue, 27 Jan 2015 08:13:55 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 27 Jan 2015 08:13:55 -0800 (PST) In-Reply-To: References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> <20150126153224.GA50403@elstar.local> <20150127151202.GA89027@elstar.local> Date: Tue, 27 Jan 2015 08:13:55 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 16:14:05 -0000 On Tue, Jan 27, 2015 at 7:55 AM, Ladislav Lhotka wrote: > >> On 27 Jan 2015, at 16:12, Juergen Schoenwaelder wrote: >> >> On Tue, Jan 27, 2015 at 03:57:41PM +0100, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder writes: >>> >>>> On Mon, Jan 26, 2015 at 03:58:45PM +0100, Ladislav Lhotka wrote: >>>>> Juergen Schoenwaelder writes: >> >>>>>> 2) I am not fine with receivers failing because of a JSON type >>>>>> mismatch. I believe receivers MUST do any conversion necessary >>>>>> should the received JSON type not match the YANG type. (That is >>>>>> "42" must be interpreted as 42 if YANG says it is an int and >>>>>> "False" must be interpreted as False if YANG says the leaf is of >>>>>> type boolean. >>>>> >>>>> I disagree. The Postel principle you referred to asks senders to be >>>>> strict, but a sender that's aware of the YANG data model (and therefo= re >>>>> knows 42 is an integer) has no good reason for *not encoding* it as a >>>>> number. >>>>> >>>>> You seem to be catering for senders that produce valid XML and then >>>>> apply YANG-unaware XML->JSON conversion. But this won't work anyway, >>>>> e.g. for single-entry lists and leaf-lists. >>>> >>>> Yes, I do forsee situations where the _encoder_ does not know the YANG >>>> type. There were a couple mentioned in the thread I think. Yes, the >>>> receiver likely also has to be lenient with one element arrays that >>>> map to a container or vice versa. >>> >>> I don't agree, this would be S-JSON (sloppy JSON) rather than >>> I-JSON. Using the same logic, one could also require that receivers fix >>> the namespace of a received XML element if the namespace doesn't match >>> the namespace of the YANG node. >> >> Sorry Lada, I can't follow your logic. > > I could have an XML encoder that doesn=E2=80=99t know YANG namespace URIs= , so it just encodes all instances as XML elements with null namespace. Rul= es for XML encoding could state that the receiver MUST fix this -but they d= on=E2=80=99t. Is this really different from your requirements on JSON encod= ing? > This is just an implementation detail. The sender is required to encode the XML namespace correctly for the anyxml node. NETCONF/RESTCONF requires the sub-nodes of this anyxml node to also be encoded correctly. > It all comes down to the fact that all encodings are equal but the XML en= coding is more equal. The benefit of JSON is that one can encode (typed) da= ta structures directly into JSON, and vice versa. Anything else means extra= work. > Only the YANG schema counts. JSON is just an encoding format. It is not being used to pass inline type information. Andy >> >>>>>> 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON >>>>>> document needs to specify how anydata is encoded in an >>>>>> interoperable way. And it needs to clarify how 2) applies, that is= , >>>>>> at the point in time where anydata content is matched against a >>>>>> datamodel, conversions MUST be applied as necessary. >>>>> >>>>> The JSON encoding spec *could* define a default schema-less XML<->JSO= N conversion >>>>> to be applied to an anydata node that doesn't define anything specifi= c. >>>>> >>>>> I think 2) doesn't apply at all for an anydata node - it's outside th= e >>>>> scope for YANG. >>>> >>>> Why is anydata outside the scope of YANG? I guess I disagree with this >>>> statement. >>> >>> Talking about your item #2 in the context of anyxml/anydata is outside >>> the scope of YANG because anyxml/anydata contents have no YANG types. >> >> My statement was that anydata is different from anyxml because we can >> make it interoperable. #2 applies since anydata may _eventually_ be >> matched against a data model, but not necessarily at the time the data >> is encoded. Please go back in this thread to find examples related to >> mounts etc. > > As soon as the data are extracted and matched against a new YANG data mod= el, it=E2=80=99s no more anydata and standard YANG rules apply. However, I = assume two other cases are possible: > > - some schema or protocol exists for the anydata content but it is not ex= pressed in YANG, > > - there is no schema. > > Lada > >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jan 27 08:18:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504331A888F for ; Tue, 27 Jan 2015 08:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_BACKHAIR_34=1, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqwJ46FETIYe for ; Tue, 27 Jan 2015 08:18:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36E11A8886 for ; Tue, 27 Jan 2015 08:18:46 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 7EA3713F9E6; Tue, 27 Jan 2015 17:18:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422375525; bh=GGNsyBfaAK/eDmCLSB4o+4+7Lxs8jwKrFxCEgOkUjCE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=os67uMesmW9X4Gtc/5m7T8eJFdfgAt2zpSeFpPNUj4C5BnUZdILJAqWCRK5kz3xIv 28YnIZNvCd+2SvH+UZrap22Lq8GdYJukGgEN/mgCmDdkltdgLfWDmJfvJsV8HzjqMP 2uhnGzYHnDdoDYzw9atNTf2lAd/SehpcF5bHxRJM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 27 Jan 2015 17:18:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 16:18:50 -0000 > On 27 Jan 2015, at 16:09, Andy Bierman wrote: >=20 > On Tue, Jan 27, 2015 at 6:46 AM, Ladislav Lhotka = wrote: >> Andy Bierman writes: >>=20 >>> On Mon, Jan 26, 2015 at 6:58 AM, Ladislav Lhotka = wrote: >>>> Juergen Schoenwaelder = writes: >>>>=20 >>>>> On Sat, Jan 24, 2015 at 10:04:00AM +0100, Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 24 Jan 2015, at 09:25, Juergen Schoenwaelder = wrote: >>>>>>>=20 >>>>>>> On Sat, Jan 24, 2015 at 06:20:22AM +0100, Ladislav Lhotka wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I think there is also a use case where anydata conveys = information that has some non-YANG schema. One example might be an = Internet kiosk whose web pages can be edited through NETCONF. For this = purpose it would actually be best to simply rename anyxml to anydata. >>>>>>>>=20 >>>>>>>=20 >>>>>>> My understanding is this: >>>>>>>=20 >>>>>>> anyxml =3D any XML (including mixed content, PIs, whatever, not >>>>>>> necessarily interoperable) >>>>>>=20 >>>>>> Yes, but I=E2=80=99d also like to have a symmetric rule for JSON = encoding, i. e. any valid JSON value. >>>>>>=20 >>>>>=20 >>>>> I am strongly against adding statements for every encoding that = comes >>>>> along. We kind of learned that anyxml is problematic and hence it = was >>>>=20 >>>> I didn't say that. My proposal is to have the same rule for all >>>> encodings, including XML: anyxml value is any content that's = well-formed >>>> for the given encoding. >>>>=20 >>>>> suggested to have an anydata type since it is restricted to = anything >>>>> that can be defined in YANG. This is a sensible type from the >>>>> perspective of YANG. Having any is in my view not >>>>> helpful since it is by definition not interoperable (and for me it = is >>>>> a layering violation as well). >>>>>=20 >>>>> During this discussion, we did also touch on the JSON I-D. Perhaps = a few >>>>> things to clarify: >>>>>=20 >>>>> 1) I am fine with encoding values into I-JSON taking YANG schema >>>>> information into account. (I do not insist everything has to be >>>>> encoded as a string.) >>>>=20 >>>> OK. >>>>=20 >>>>>=20 >>>>> 2) I am not fine with receivers failing because of a JSON type >>>>> mismatch. I believe receivers MUST do any conversion necessary >>>>> should the received JSON type not match the YANG type. (That is >>>>> "42" must be interpreted as 42 if YANG says it is an int and >>>>> "False" must be interpreted as False if YANG says the leaf is of >>>>> type boolean. >>>>=20 >>>> I disagree. The Postel principle you referred to asks senders to be >>>> strict, but a sender that's aware of the YANG data model (and = therefore >>>> knows 42 is an integer) has no good reason for *not encoding* it as = a >>>> number. >>>>=20 >>>=20 >>> The YANG type is anyxml, which means there is no YANG type. >>> It makes no sense to say "the server knows this is an int". >>> The YANG schema says "anyxml". Period. >>=20 >> Juergen's item #2 above clearly talks about other nodes than anyxml. >>=20 >=20 >=20 > Not sure what this means. > If the sender encodes "42" as a string and the final receiver that = knows > YANG thinks it is an int32, then the receiver will convert the string = "42" > to the YANG type int32, even though the JSON type was a string > instead of a number. The receiving side could in principle fix many other type or structure = violations, even in XML encoding. Another example: RFC 6020 requires = list keys to go first, before other siblings in the same entry. However, = it doesn=E2=80=99t require the receiver to silently fix the order if = this rule is violated. >=20 > This seems clear and hard to interpret as a requirement on the sender. I want to require the server to use its data model knowledge and encode = everything properly. >=20 >=20 >=20 >=20 >>>=20 >>>=20 >>>> You seem to be catering for senders that produce valid XML and then >>>> apply YANG-unaware XML->JSON conversion. But this won't work = anyway, >>>> e.g. for single-entry lists and leaf-lists. >>>>=20 >>>=20 >>>=20 >>> I read this quite differently. >>> The Postel Principle says be liberal in what you accept. >>=20 >> No, it says this: >>=20 >> "Be conservative in what you send, be liberal in what you accept." >>=20 >=20 > both parts, yes. >=20 >> In fact, it's not meant as a guideline for protocol designers but = rather >> for protocol users: the sender should comply with the protocol, and = the >> receiver should reasonably tolerate protocol violations. >>=20 >=20 > I disagree Then read RFC 1122. >=20 >>> It is quite trivial for the receiver to convert to a string which >>> can then be parsed by the end-user and converted to a YANG type. >>=20 >> It's equally trivial, e.g., to convert a received value of 42.0 to an >> integer and I don't mind if a receiver follows the Postel principle = and >> performs this conversion - despite the fact that 42.0 is not a valid >> value for a YANG integer. >=20 > But "42.0" does not follow the rules for an int32 so this is a > strawman argument. Likewise, the rule for encoding forty-two in JSON is to use a JSON = number. A sender encoding it as a string doesn=E2=80=99t follow this = rule. =20 > The sender will encode "42" and everything works fine. Even if the Yes, the sender encodes it as a JSON number 42 and everything works = fine. Lada > sender encodes a JSON number, everything works fine. It is not = difficult > to convert any JSON type to a YANG type (or reject it instead). >=20 >=20 >=20 >>=20 >> Lada >>=20 >=20 >=20 > Andy >=20 >>>=20 >>>=20 >>>>>=20 >>>>> 3) Assuming we adopt anydata in YANG 1.1, then I am fine with the = JSON >>>>> document saying the encoding of anyxml is implementation = dependent >>>>> (because we would say clearly in YANG 1.1 that anyxml is in the >>>>> general case non-interoperable). >>>>=20 >>>> OK. >>>>=20 >>>>>=20 >>>>> 4) Assuming we adopt anydata in YANG 1.1, then I think the JSON >>>>> document needs to specify how anydata is encoded in an >>>>> interoperable way. And it needs to clarify how 2) applies, that = is, >>>>> at the point in time where anydata content is matched against a >>>>> datamodel, conversions MUST be applied as necessary. >>>>=20 >>>> The JSON encoding spec *could* define a default schema-less = XML<->JSON conversion >>>> to be applied to an anydata node that doesn't define anything = specific. >>>>=20 >>>> I think 2) doesn't apply at all for an anydata node - it's outside = the >>>> scope for YANG. >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> /js >>>>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, = Germany >>>>> Fax: +49 421 200 3103 >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 27 09:09:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7B1A88A7 for ; Tue, 27 Jan 2015 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AquI0ze295jr for ; Tue, 27 Jan 2015 09:09:26 -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 C50981A88AF for ; Tue, 27 Jan 2015 09:09:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 907DD767; Tue, 27 Jan 2015 18:09:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HmilVfo-TVyv; Tue, 27 Jan 2015 18:09:05 +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; Tue, 27 Jan 2015 18:09:14 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BE3120036; Tue, 27 Jan 2015 18:09:14 +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 DqloKtDA34iU; Tue, 27 Jan 2015 18:09:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C60420035; Tue, 27 Jan 2015 18:09:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2E3AB311148A; Tue, 27 Jan 2015 18:09:09 +0100 (CET) Date: Tue, 27 Jan 2015 18:09:09 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150127170907.GB89308@elstar.local> Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> <20150126153224.GA50403@elstar.local> <20150127151202.GA89027@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 17:09:29 -0000 On Tue, Jan 27, 2015 at 04:55:59PM +0100, Ladislav Lhotka wrote: > > > On 27 Jan 2015, at 16:12, Juergen Schoenwaelder wrote: > > > > On Tue, Jan 27, 2015 at 03:57:41PM +0100, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder writes: > >> > >>> On Mon, Jan 26, 2015 at 03:58:45PM +0100, Ladislav Lhotka wrote: > >>>> Juergen Schoenwaelder writes: > > > >>>>> 2) I am not fine with receivers failing because of a JSON type > >>>>> mismatch. I believe receivers MUST do any conversion necessary > >>>>> should the received JSON type not match the YANG type. (That is > >>>>> "42" must be interpreted as 42 if YANG says it is an int and > >>>>> "False" must be interpreted as False if YANG says the leaf is of > >>>>> type boolean. > >>>> > >>>> I disagree. The Postel principle you referred to asks senders to be > >>>> strict, but a sender that's aware of the YANG data model (and therefore > >>>> knows 42 is an integer) has no good reason for *not encoding* it as a > >>>> number. > >>>> > >>>> You seem to be catering for senders that produce valid XML and then > >>>> apply YANG-unaware XML->JSON conversion. But this won't work anyway, > >>>> e.g. for single-entry lists and leaf-lists. > >>> > >>> Yes, I do forsee situations where the _encoder_ does not know the YANG > >>> type. There were a couple mentioned in the thread I think. Yes, the > >>> receiver likely also has to be lenient with one element arrays that > >>> map to a container or vice versa. > >> > >> I don't agree, this would be S-JSON (sloppy JSON) rather than > >> I-JSON. Using the same logic, one could also require that receivers fix > >> the namespace of a received XML element if the namespace doesn't match > >> the namespace of the YANG node. > > > > Sorry Lada, I can't follow your logic. > > I could have an XML encoder that doesn’t know YANG namespace URIs, so it just encodes all instances as XML elements with null namespace. Rules for XML encoding could state that the receiver MUST fix this -but they don’t. Is this really different from your requirements on JSON encoding? Yes, I can convert a string into an int and vice versa but I can't create a proper namespace out of nothing. I am surprised you do not see these differences. > It all comes down to the fact that all encodings are equal but the XML encoding is more equal. The benefit of JSON is that one can encode (typed) data structures directly into JSON, and vice versa. Anything else means extra work. First, XML encoding is indeed more equal because it is used by NETCONF and it will be mandatory to implement in RESTCONF as far as I can tell from following the NETCONF discussion. Second, I have nothing against encoding a YANG int32 into a JSON number. But: I do not assume that the YANG type is _always_ known by the encoder. Hence, I believe the YANG type must be considered authoritative and in case the data model aware piece of code detects a discrepancy, a conversion should be done rather than aborting with an error. And yes, contrary to you, I do foresee situations where the data model aware piece of code is not tightly integrated with the encoder/decoder. What drives me is interoperability. I personally happen to love all possible data serialization formats equally little. ;-) I do not think we make progress this way and we probably need to find a way to do a mailing list hum to figure out where the _WG_ stands on this issue and not just the two of us. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 27 23:44:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1DD1A00E9 for ; Tue, 27 Jan 2015 23:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEBZWIYc3zvm for ; Tue, 27 Jan 2015 23:44:11 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FA81A00E7 for ; Tue, 27 Jan 2015 23:44:10 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d] (unknown [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d]) by mail.nic.cz (Postfix) with ESMTPSA id 3B21E13F9CD; Wed, 28 Jan 2015 08:44:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422431049; bh=qwJvq6h+RQwH5iU641JVdOOMCdD4yvaWRbdg47BqBVY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=k9QZQSFjnTm1YICA58s6+PCIxmYWEabG6tTb8wF+GeyZaAIe6twZ4lSMburMlvZW8 Eu5o+CEyeX04Hj1sLWZyMyuGLU/g15yrLi5fF7uBC/K+djDLWEjJXzh2UBLe7pBlKW inkid9s049zkVSRpWg67whm4FbHMbsT5vYo4jinE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150127170907.GB89308@elstar.local> Date: Wed, 28 Jan 2015 08:44:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6789D0E5-74A6-465B-831C-742E44DEFAB4@nic.cz> References: <20150124082543.GA43523@elstar.local> <20150126124944.GB49835@elstar.local> <20150126153224.GA50403@elstar.local> <20150127151202.GA89027@elstar.local> <20150127170907.GB89308@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 07:44:13 -0000 > On 27 Jan 2015, at 18:09, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 27, 2015 at 04:55:59PM +0100, Ladislav Lhotka wrote: >>=20 >>> On 27 Jan 2015, at 16:12, Juergen Schoenwaelder = wrote: >>>=20 >>> On Tue, Jan 27, 2015 at 03:57:41PM +0100, Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder = writes: >>>>=20 >>>>> On Mon, Jan 26, 2015 at 03:58:45PM +0100, Ladislav Lhotka wrote: >>>>>> Juergen Schoenwaelder = writes: >>>=20 >>>>>>> 2) I am not fine with receivers failing because of a JSON type >>>>>>> mismatch. I believe receivers MUST do any conversion necessary >>>>>>> should the received JSON type not match the YANG type. (That is >>>>>>> "42" must be interpreted as 42 if YANG says it is an int and >>>>>>> "False" must be interpreted as False if YANG says the leaf is = of >>>>>>> type boolean. >>>>>>=20 >>>>>> I disagree. The Postel principle you referred to asks senders to = be >>>>>> strict, but a sender that's aware of the YANG data model (and = therefore >>>>>> knows 42 is an integer) has no good reason for *not encoding* it = as a >>>>>> number. >>>>>>=20 >>>>>> You seem to be catering for senders that produce valid XML and = then >>>>>> apply YANG-unaware XML->JSON conversion. But this won't work = anyway, >>>>>> e.g. for single-entry lists and leaf-lists. >>>>>=20 >>>>> Yes, I do forsee situations where the _encoder_ does not know the = YANG >>>>> type. There were a couple mentioned in the thread I think. Yes, = the >>>>> receiver likely also has to be lenient with one element arrays = that >>>>> map to a container or vice versa. >>>>=20 >>>> I don't agree, this would be S-JSON (sloppy JSON) rather than >>>> I-JSON. Using the same logic, one could also require that receivers = fix >>>> the namespace of a received XML element if the namespace doesn't = match >>>> the namespace of the YANG node. >>>=20 >>> Sorry Lada, I can't follow your logic. >>=20 >> I could have an XML encoder that doesn=E2=80=99t know YANG namespace = URIs, so it just encodes all instances as XML elements with null = namespace. Rules for XML encoding could state that the receiver MUST fix = this -but they don=E2=80=99t. Is this really different from your = requirements on JSON encoding? >=20 > Yes, I can convert a string into an int and vice versa but I can't > create a proper namespace out of nothing. I am surprised you do not > see these differences. That=E2=80=99s because I am retarded. But in fact a YANG-aware receiver = can figure out the proper namespace as nicely as the type of a leaf. >=20 >> It all comes down to the fact that all encodings are equal but the = XML encoding is more equal. The benefit of JSON is that one can encode = (typed) data structures directly into JSON, and vice versa. Anything = else means extra work. >=20 > First, XML encoding is indeed more equal because it is used by NETCONF > and it will be mandatory to implement in RESTCONF as far as I can tell > from following the NETCONF discussion. >=20 > Second, I have nothing against encoding a YANG int32 into a JSON > number. But: I do not assume that the YANG type is _always_ known by > the encoder. Hence, I believe the YANG type must be considered > authoritative and in case the data model aware piece of code detects a > discrepancy, a conversion should be done rather than aborting with an > error. And yes, contrary to you, I do foresee situations where the > data model aware piece of code is not tightly integrated with the > encoder/decoder. >=20 > What drives me is interoperability. I personally happen to love all > possible data serialization formats equally little. ;-) >=20 > I do not think we make progress this way and we probably need to find > a way to do a mailing list hum to figure out where the _WG_ stands on > this issue and not just the two of us. Agreed. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 28 00:08:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2E1A00E5 for ; Wed, 28 Jan 2015 00:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OBvORK6NS9I for ; Wed, 28 Jan 2015 00:08:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 40ED61A004C for ; Wed, 28 Jan 2015 00:08:27 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 38F1412801A6; Wed, 28 Jan 2015 09:08:26 +0100 (CET) Date: Wed, 28 Jan 2015 09:10:57 +0100 (CET) Message-Id: <20150128.091057.1523590536703844716.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150127170907.GB89308@elstar.local> References: <20150127151202.GA89027@elstar.local> <20150127170907.GB89308@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 08:08:33 -0000 Juergen Schoenwaelder wrote: > I do not think we make progress this way and we probably need to find > a way to do a mailing list hum to figure out where the _WG_ stands on > this issue and not just the two of us. At this point, I think it would be useful if you could take a step back and formulate the problem. I must I admit I got lost in the discussion. I *think* the issue now has to do with the json encoding of anydata and anyxml, if we decide to introduce anydata? /martin From nobody Wed Jan 28 00:28:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D861A00DF for ; Wed, 28 Jan 2015 00:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oQxIBNCl3KH for ; Wed, 28 Jan 2015 00:28:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1621A004C for ; Wed, 28 Jan 2015 00:28:06 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d] (unknown [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d]) by mail.nic.cz (Postfix) with ESMTPSA id AFC6813F9AF; Wed, 28 Jan 2015 09:28:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422433684; bh=RzWbRb7cnTWZAlMu1XCBw9G6aMis2H6pYf+Czx7S9+c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dqugKA7dAiUUQ5NoczXJ+thNJFS6NLSITRzFW05K4WL8sZBk7+rK3Y/Za+vsoJ3mk MEXt2cnKXXNcio1mMbyeowM+IONkUiqGYxU10iznwLawN7FjbxAFjOX4Z+yDvbwRzY yXavS2DiE0W+spgu6T5qnoN+77YZ/8wjKbf9m1cw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150128.091057.1523590536703844716.mbj@tail-f.com> Date: Wed, 28 Jan 2015 09:28:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150127151202.GA89027@elstar.local> <20150127170907.GB89308@elstar.local> <20150128.091057.1523590536703844716.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 08:28:07 -0000 > On 28 Jan 2015, at 09:10, Martin Bjorklund wrote: >=20 > Juergen Schoenwaelder wrote: >> I do not think we make progress this way and we probably need to find >> a way to do a mailing list hum to figure out where the _WG_ stands on >> this issue and not just the two of us. >=20 > At this point, I think it would be useful if you could take a step > back and formulate the problem. I must I admit I got lost in the > discussion. I *think* the issue now has to do with the json encoding > of anydata and anyxml, if we decide to introduce anydata? Yes, the discussion sometimes wandered into areas that are unrelated to = anyxml/anydata. As for anydata, I=E2=80=99d be happy with just renaming anyxml to = anydata, keeping the existing 6020 definition for XML encoding, and = using the definition of JSON encoding that=E2=80=99s currently in = draft-ietf-netmod-yang-json-02, sec. 5.5, and similarly for any future = encoding: anydata means any content that=E2=80=99s well-formed for the = given encoding (in the broader context of the entire = datastore/document). I understand that Andy wants to exclude XML mixed content, so I can also = agree with adding restrictions for anydata in the sense that the content = can *potentially* be modelled in YANG. The exact conditions are somewhat = tricky because, for example, this XML snippet cannot be modelled in = YANG: 42 hi Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 28 01:04:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2D1A01C6 for ; Wed, 28 Jan 2015 01:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXZtg9I52q7c for ; Wed, 28 Jan 2015 01:04:23 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 599471A0222 for ; Wed, 28 Jan 2015 01:04:15 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 86F0212801A6; Wed, 28 Jan 2015 10:04:14 +0100 (CET) Date: Wed, 28 Jan 2015 10:06:46 +0100 (CET) Message-Id: <20150128.100646.753961661897533382.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150127170907.GB89308@elstar.local> <20150128.091057.1523590536703844716.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 09:04:30 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjggSmFu IDIwMTUsIGF0IDA5OjEwLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+PiBJIGRvIG5vdCB0aGluayB3ZSBtYWtlIHByb2dy ZXNzIHRoaXMgd2F5IGFuZCB3ZSBwcm9iYWJseSBuZWVkIHRvIGZpbmQNCj4gPj4gYSB3YXkgdG8g ZG8gYSBtYWlsaW5nIGxpc3QgaHVtIHRvIGZpZ3VyZSBvdXQgd2hlcmUgdGhlIF9XR18gc3RhbmRz IG9uDQo+ID4+IHRoaXMgaXNzdWUgYW5kIG5vdCBqdXN0IHRoZSB0d28gb2YgdXMuDQo+ID4gDQo+ ID4gQXQgdGhpcyBwb2ludCwgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgaWYgeW91IGNvdWxk IHRha2UgYSBzdGVwDQo+ID4gYmFjayBhbmQgZm9ybXVsYXRlIHRoZSBwcm9ibGVtLiAgSSBtdXN0 IEkgYWRtaXQgSSBnb3QgbG9zdCBpbiB0aGUNCj4gPiBkaXNjdXNzaW9uLiAgSSAqdGhpbmsqIHRo ZSBpc3N1ZSBub3cgaGFzIHRvIGRvIHdpdGggdGhlIGpzb24gZW5jb2RpbmcNCj4gPiBvZiBhbnlk YXRhIGFuZCBhbnl4bWwsIGlmIHdlIGRlY2lkZSB0byBpbnRyb2R1Y2UgYW55ZGF0YT8NCj4gDQo+ IFllcywgdGhlIGRpc2N1c3Npb24gc29tZXRpbWVzIHdhbmRlcmVkIGludG8gYXJlYXMgdGhhdCBh cmUgdW5yZWxhdGVkDQo+IHRvIGFueXhtbC9hbnlkYXRhLg0KPiANCj4gQXMgZm9yIGFueWRhdGEs IEnigJlkIGJlIGhhcHB5IHdpdGgganVzdCByZW5hbWluZyBhbnl4bWwgdG8gYW55ZGF0YSwNCg0K SSBkb24ndCB0aGluayB3b3Jrcy4gIEl0IGlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZSwgYW5k IGl0IHdvdWxkDQpicmVhayB0aGUgZGVmaW5pdGlvbiBpbiA2MjQxLg0KDQpNeSBwcmVmZXJlbmNl IHdvdWxkIGJlIFkzNC0wMiAoa2VlcCBhbnl4bWwsIGFkZCBhbnlkYXRhKSwgd2l0aCB0aGUNCmNs YXJpZmljYXRpb25zIHN1Z2dlc3RlZCBieSBKdWVyZ2VuIChkaXNjb3VyYWdlIHRoZSB1c2FnZSBv ZiBhbnl4bWwpLg0KDQo+IEkgdW5kZXJzdGFuZCB0aGF0IEFuZHkgd2FudHMgdG8gZXhjbHVkZSBY TUwgbWl4ZWQgY29udGVudCwgc28gSSBjYW4NCj4gYWxzbyBhZ3JlZSB3aXRoIGFkZGluZyByZXN0 cmljdGlvbnMgZm9yIGFueWRhdGEgaW4gdGhlIHNlbnNlIHRoYXQgdGhlDQo+IGNvbnRlbnQgY2Fu ICpwb3RlbnRpYWxseSogYmUgbW9kZWxsZWQgaW4gWUFORy4NCg0KWWVzLCBJIHRoaW5rIHdlIHdh bnQgdG8gYWxsb3cgZm9yIHRoZSBjYXNlIHdoZXJlIGEgY29uc3VtZXIvcHJvZHVjZXINCm9mICdh bnlkYXRhJyBkb2VzIG5vdCBrbm93IHRoZSBZQU5HIGRhdGEgbW9kZWwgKGdlbmVyaWMgbG9nZ2Vy LCBzb21lDQpwcm94eSwgZXRjKS4gIFNvICJwb3RlbnRpYWxseSIgbW9kZWxsZWQgaW4gWUFORyBz aG91bGQgYmUgZmluZS4NCg0KVGhlIGlzc3VlIEkgc2VlIGNhbiBiZSBpbGx1c3RyYXRlZCBsaWtl IHRoaXM6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KICBpbnB1dCB3LyBh bnlkYXRhIC0tPiB8IHNlcnZlciB8IC0tIG91dHB1dCAtLT4NCiAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tKw0KDQpJLmUuLCBzb21lIGltcGxlbWVudGF0aW9uIGdldHMgZGF0YSB3LyBh bnlkYXRhIGluIGl0LCBhbmQgaXMgc3VwcG9zZWQNCnRvIHNlbmQgdGhpcyB0byBzb21lIGNsaWVu dCB0aGF0IG5lZWRzIHRvIGJlIGFibGUgdG8gaW50ZXJwcmV0IHRoaXMNCmRhdGEuDQoNCkxldCdz IGFzc3VtZSB0aGUgZGF0YSBpcyB0aGlzOg0KDQogIG5hbWVzcGFjZSB1cm46eDsNCiAgIC4uLg0K ICBjb250YWluZXIgeCB7DQogICAgYW55ZGF0YSB5Ow0KICB9DQoNCmFuZCBvbmUgZXhhbXBsZSBv ZiBzb21ldGhpbmcgd2UgY2FuIHB1dCBpbnRvIHRoaXMgYW55ZGF0YSBpczoNCg0KICBuYW1lc3Bh Y2UgdXJuOmZvbzsNCiAgLi4uDQogIGNvbnRhaW5lciBmb28gew0KICAgIGxlYWYgYmFyIHsNCiAg ICAgIHR5cGUgaW50MzI7DQogICAgfQ0KICAgIGxlYWYgaWYtdHlwZSB7DQogICAgICB0eXBlIGlk ZW50aXR5cmVmIHsNCiAgICAgICAgYmFzZSBpZjppbnRlcmZhY2UtdHlwZTsNCiAgICAgIH0NCiAg ICB9DQogIH0NCiAgICANCiAgbW9kdWxlIGV4LWV0aGVybmV0IHsNCiAgICBuYW1lc3BhY2UgdXJu OmV4ZXRoOw0KICAgIC4uLg0KICAgIGlkZW50aXR5IGV0aGVybmV0IHsgLi4uIH0NCiAgfQ0KICAg ICANCg0KDQpTbyB0aGUgaW5wdXQgY291bGQgYmU6DQoNCiAgKEEpDQogIDx4IHhtbG5zPSJ1cm46 eCI+DQogICAgPHk+DQogICAgICA8Zm9vIHhtbG5zPSJ1cm46Zm9vIiB4bWxuczpwMD0idXJuOmV4 ZXRoIj4NCiAgICAgICAgPGJhcj40MjwvYmFyPg0KICAgICAgICA8aWYtdHlwZT5wMDpldGhlcm5l dDwvaWYtdHlwZT4NCiAgICAgIDwvZm9vPg0KICAgIDwveT4NCiAgPC94Pg0KDQoNClRoZXJlIGFy ZSBmb3VyIGNhc2VzOg0KDQoxLiAgaW5wdXQgeG1sLCBvdXRwdXQgeG1sDQoNCiAgVGhlIHByb2Js ZW0gaGVyZSBoYXMgdG8gZG8gd2l0aCBuYW1lc3BhY2UgcHJlZml4ZXMuDQoNCiAgU3VwcG9zZSB0 aGUgaW5wdXQgd2FzIHJlY2VpdmVkIGFzOg0KDQogIChCKQ0KICA8eCB4bWxucz0idXJuOngiIHht bG5zOnAxPSJ1cm46ZXhldGgiPg0KICAgIDx5Pg0KICAgICAgPGZvbyB4bWxucz0idXJuOmZvbyI+ DQogICAgICAgIDxiYXI+NDI8L2Jhcj4NCiAgICAgICAgPGlmLXR5cGU+cDE6ZXRoZXJuZXQ8L2lm LXR5cGU+DQogICAgICA8L2Zvbz4NCiAgICA8L3k+DQogIDwveD4NCg0KICBUaGUgc2VydmVyIGRv ZXNuJ3Qga25vdyB0aGF0IGlmLXR5cGUgaXMgb2YgdHlwZSBpZGVudGl0eXJlZiwgc28gaXQNCiAg ZG9lc24ndCBrbm93IHRoYXQgImV0aDoiIGlzIGEgcHJlZml4LiAgSXQganVzdCBzdG9yZXMgZXZl cnl0aGluZyBhcw0KICBzdHJpbmdzLiAgQnV0IHdoZW4gaXQgcmV0dXJucyB0aGlzIG5vZGUgdG8g YSBjbGllbnQsIGl0IG11c3QgbWFrZQ0KICBzdXJlIHRoZSBwcmVmaXggaXMgZGVjbGFyZWQgcHJv cGVybHkuDQoNCiAgV2UgY2FuIHNvbHZlIHRoaXMgZm9yIGFueWRhdGEgYnkgc2F5aW5nIHRoYXQg DQogIHRoZSBhbnlkYXRhIG5vZGUgbXVzdCBoYXZlIGFsbCBuYW1lc3BhY2UgZGVjbGFyYXRpb25z IGluIHRoZSBhbnlkYXRhDQogIHN1YnRyZWUgaW4gdGhlIFhNTCBlbmNvZGluZy4gIFRodXMgdGhl IGlucHV0IChCKSB3b3VsZCBiZSBpbGxlZ2FsLA0KICBidXQgKEEpIGxlZ2FsLg0KDQoNCjIuICBp bnB1dCBqc29uLCBvdXRwdXQganNvbg0KDQogIEluIGpzb24sIHRoZXJlIGFyZSBubyBuYW1lc3Bh Y2UgcHJlZml4ZXMsIHNvIHRoYXQgaXMgbm90IGFuIGlzc3VlLg0KICBBbHNvLCBpZiBib3RoIGlu cHV0IGFuZCBvdXRwdXQgaXMganNvbiwgdGhlIGltcGxlbWVudGF0aW9uIGNhbiBzdG9yZQ0KICB0 aGUgZGF0YSBhcyByZWNlaXZlZCwgYW5kIHJldHVybiBpdCBpbiB0aGUgc2FtZSB3YXkuDQoNCg0K My4gIGlucHV0IHhtbCwgb3V0cHV0IGpzb24NCg0KICBUaGlzIGlzIHRyaWNreSwgc2luY2UgaW4g b3JkZXIgdG8gcHJvZHVjZSBjb3JyZWN0IGpzb24gYm90aCBmb3IgbGVhZg0KICAnYmFyJyBhbmQg bGVhZiAnaWYtdHlwZScsIHRoZSBzZXJ2ZXIgbmVlZHMgc2NoZW1hIGtub3dsZWRnZTsgJ2JhcicN CiAgbXVzdCBiZSBlbmNvZGVkIGFzIDQyIHJhdGhlciB0aGFuICI0MiIsIGFuZCAnaWYtdHlwZScg bXVzdCBiZQ0KICBlbmNvZGVkIGFzICJleC1ldGhlcm5ldDpldGhlcm5ldCIgcmF0aGVyIHRoYW4g InAwOmV0aGVybmV0Ii4NCg0KDQo0LiAgaW5wdXQganNvbiwgb3V0cHV0IHhtbA0KDQogIFNpbWls YXIgcHJvYmxlbXMgYXMgaW4gMy4NCg0KDQoNCg0KDQovbWFydGluDQo= From nobody Wed Jan 28 01:51:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74691A0271 for ; Wed, 28 Jan 2015 01:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjIaT0De7rgt for ; Wed, 28 Jan 2015 01:51:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E723B1A026A for ; Wed, 28 Jan 2015 01:51:33 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d] (unknown [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d]) by mail.nic.cz (Postfix) with ESMTPSA id D41E013F9AF; Wed, 28 Jan 2015 10:51:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422438691; bh=4I+2n8WGk/yRwQtiAbNkEU1ER6jiavq7MY4hKVA/Sq8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CeDLcNIAaK+dwj5XiqjuxJeF8KnXzM+NtiZsO2Qm6CzyB9kUHcr6H6px9LivcSNKX wsfby/GRAV5njl9nuUX4Vo6P+czhXrjMbvMTQxfJnSScODPkT/aYvKxE++m4qLuBXQ xceBAlj9tqOetR5e1ycourdshmYmOaPphj9HvPyQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150128.100646.753961661897533382.mbj@tail-f.com> Date: Wed, 28 Jan 2015 10:51:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06E2712F-AFAF-4652-BFED-1AEC0C98457A@nic.cz> References: <20150127170907.GB89308@elstar.local> <20150128.091057.1523590536703844716.mbj@tail-f.com> <20150128.100646.753961661897533382.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 09:51:37 -0000 > On 28 Jan 2015, at 10:06, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 28 Jan 2015, at 09:10, Martin Bjorklund wrote: >>>=20 >>> Juergen Schoenwaelder wrote: >>>> I do not think we make progress this way and we probably need to = find >>>> a way to do a mailing list hum to figure out where the _WG_ stands = on >>>> this issue and not just the two of us. >>>=20 >>> At this point, I think it would be useful if you could take a step >>> back and formulate the problem. I must I admit I got lost in the >>> discussion. I *think* the issue now has to do with the json = encoding >>> of anydata and anyxml, if we decide to introduce anydata? >>=20 >> Yes, the discussion sometimes wandered into areas that are unrelated >> to anyxml/anydata. >>=20 >> As for anydata, I=E2=80=99d be happy with just renaming anyxml to = anydata, >=20 > I don't think works. It is not backwards compatible, and it would > break the definition in 6241. Well, yes, I mean keeping anyxml as a (deprecated) synonym. Which 6241 = definition do you mean? The advantage of this solution is that existing data formats (RDF comes = to my mind) that have nothing in common with YANG can be potentially = piggybacked in anydata. Andy will say such a use case doesn=E2=80=99t = exist yet but I think this *might* be potentially useful. Assuming that = YANG will become the universal schema language for network protocols is = not realistic. >=20 > My preference would be Y34-02 (keep anyxml, add anydata), with the > clarifications suggested by Juergen (discourage the usage of anyxml). >=20 >> I understand that Andy wants to exclude XML mixed content, so I can >> also agree with adding restrictions for anydata in the sense that the >> content can *potentially* be modelled in YANG. >=20 > Yes, I think we want to allow for the case where a consumer/producer > of 'anydata' does not know the YANG data model (generic logger, some > proxy, etc). So "potentially" modelled in YANG should be fine. >=20 > The issue I see can be illustrated like this: >=20 > +--------+ > input w/ anydata --> | server | -- output --> > +--------+ >=20 > I.e., some implementation gets data w/ anydata in it, and is supposed > to send this to some client that needs to be able to interpret this > data. >=20 > Let's assume the data is this: >=20 > namespace urn:x; > ... > container x { > anydata y; > } >=20 > and one example of something we can put into this anydata is: >=20 > namespace urn:foo; > ... > container foo { > leaf bar { > type int32; > } > leaf if-type { > type identityref { > base if:interface-type; > } > } > } >=20 > module ex-ethernet { > namespace urn:exeth; > ... > identity ethernet { ... } > } >=20 >=20 >=20 > So the input could be: >=20 > (A) > > > > 42 > p0:ethernet > > > >=20 >=20 > There are four cases: >=20 > 1. input xml, output xml >=20 > The problem here has to do with namespace prefixes. >=20 > Suppose the input was received as: >=20 > (B) > > > > 42 > p1:ethernet > > > >=20 > The server doesn't know that if-type is of type identityref, so it > doesn't know that "eth:" is a prefix. It just stores everything as You probably mean =E2=80=9Cp1:=E2=80=9D here. But if the server has the = data model, it should know this is an identityref and =E2=80=9Cp1:=E2=80=9D= is a prefix, right? > strings. But when it returns this node to a client, it must make > sure the prefix is declared properly. >=20 > We can solve this for anydata by saying that=20 > the anydata node must have all namespace declarations in the anydata > subtree in the XML encoding. Thus the input (B) would be illegal, > but (A) legal. >=20 >=20 > 2. input json, output json >=20 > In json, there are no namespace prefixes, so that is not an issue. > Also, if both input and output is json, the implementation can store > the data as received, and return it in the same way. >=20 >=20 > 3. input xml, output json >=20 > This is tricky, since in order to produce correct json both for leaf > 'bar' and leaf 'if-type', the server needs schema knowledge; 'bar' > must be encoded as 42 rather than "42", and 'if-type' must be > encoded as "ex-ethernet:ethernet" rather than "p0:ethernet=E2=80=9D. It doesn=E2=80=99t make much sense to me that the server act as a = transparent relay. I think one can assume that for every anydata node = the server has a schema, although it needn=E2=80=99t be expressed in = YANG. If there really was a use case for a schema-agnostic server, we could = define a default (and lossy) XML->JSON translation. Lada >=20 >=20 > 4. input json, output xml >=20 > Similar problems as in 3. >=20 >=20 >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 28 02:08:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D249B1A00B1 for ; Wed, 28 Jan 2015 02:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKgUC_9erlBt for ; Wed, 28 Jan 2015 02:08:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3EC1A02BE for ; Wed, 28 Jan 2015 02:08:21 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 61EDE1280453; Wed, 28 Jan 2015 11:08:20 +0100 (CET) Date: Wed, 28 Jan 2015 11:10:52 +0100 (CET) Message-Id: <20150128.111052.1569834530678944655.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <06E2712F-AFAF-4652-BFED-1AEC0C98457A@nic.cz> References: <20150128.100646.753961661897533382.mbj@tail-f.com> <06E2712F-AFAF-4652-BFED-1AEC0C98457A@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 10:08:24 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjggSmFu IDIwMTUsIGF0IDEwOjA2LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+PiBPbiAyOCBKYW4gMjAxNSwgYXQgMDk6MTAsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0 YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4+IEkgZG8g bm90IHRoaW5rIHdlIG1ha2UgcHJvZ3Jlc3MgdGhpcyB3YXkgYW5kIHdlIHByb2JhYmx5IG5lZWQg dG8gZmluZA0KPiA+Pj4+IGEgd2F5IHRvIGRvIGEgbWFpbGluZyBsaXN0IGh1bSB0byBmaWd1cmUg b3V0IHdoZXJlIHRoZSBfV0dfIHN0YW5kcyBvbg0KPiA+Pj4+IHRoaXMgaXNzdWUgYW5kIG5vdCBq dXN0IHRoZSB0d28gb2YgdXMuDQo+ID4+PiANCj4gPj4+IEF0IHRoaXMgcG9pbnQsIEkgdGhpbmsg aXQgd291bGQgYmUgdXNlZnVsIGlmIHlvdSBjb3VsZCB0YWtlIGEgc3RlcA0KPiA+Pj4gYmFjayBh bmQgZm9ybXVsYXRlIHRoZSBwcm9ibGVtLiAgSSBtdXN0IEkgYWRtaXQgSSBnb3QgbG9zdCBpbiB0 aGUNCj4gPj4+IGRpc2N1c3Npb24uICBJICp0aGluayogdGhlIGlzc3VlIG5vdyBoYXMgdG8gZG8g d2l0aCB0aGUganNvbiBlbmNvZGluZw0KPiA+Pj4gb2YgYW55ZGF0YSBhbmQgYW55eG1sLCBpZiB3 ZSBkZWNpZGUgdG8gaW50cm9kdWNlIGFueWRhdGE/DQo+ID4+IA0KPiA+PiBZZXMsIHRoZSBkaXNj dXNzaW9uIHNvbWV0aW1lcyB3YW5kZXJlZCBpbnRvIGFyZWFzIHRoYXQgYXJlIHVucmVsYXRlZA0K PiA+PiB0byBhbnl4bWwvYW55ZGF0YS4NCj4gPj4gDQo+ID4+IEFzIGZvciBhbnlkYXRhLCBJ4oCZ ZCBiZSBoYXBweSB3aXRoIGp1c3QgcmVuYW1pbmcgYW55eG1sIHRvIGFueWRhdGEsDQo+ID4gDQo+ ID4gSSBkb24ndCB0aGluayB3b3Jrcy4gIEl0IGlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZSwg YW5kIGl0IHdvdWxkDQo+ID4gYnJlYWsgdGhlIGRlZmluaXRpb24gaW4gNjI0MS4NCj4gDQo+IFdl bGwsIHllcywgSSBtZWFuIGtlZXBpbmcgYW55eG1sIGFzIGEgKGRlcHJlY2F0ZWQpIHN5bm9ueW0u DQoNCk5vdCBzeW5vbnltLCBzaW5jZSAnYW55eG1sJyB0cnVseSBpcyBhbnkgeG1sLCB3aGljaCAn YW55ZGF0YScgaXMgbm90Lg0KQW5kIHByb2JhYmx5IG5vdCBkZXByZWNhdGVkLCBidXQgcmF0aGVy ICJ0aGluayB0d2ljZSBiZWZvcmUgdXNpbmciLg0KDQo+IFdoaWNoIDYyNDENCj4gZGVmaW5pdGlv biBkbyB5b3UgbWVhbj8NCg0KcnBjIGVkaXQtY29uZmlnIGV0Yy4gIFNlYXJjaCBmb3IgYW55eG1s Lg0KDQo+IFRoZSBhZHZhbnRhZ2Ugb2YgdGhpcyBzb2x1dGlvbiBpcyB0aGF0IGV4aXN0aW5nIGRh dGEgZm9ybWF0cyAoUkRGDQo+IGNvbWVzIHRvIG15IG1pbmQpIHRoYXQgaGF2ZSBub3RoaW5nIGlu IGNvbW1vbiB3aXRoIFlBTkcgY2FuIGJlDQo+IHBvdGVudGlhbGx5IHBpZ2d5YmFja2VkIGluIGFu eWRhdGEuIEFuZHkgd2lsbCBzYXkgc3VjaCBhIHVzZSBjYXNlDQo+IGRvZXNu4oCZdCBleGlzdCB5 ZXQgYnV0IEkgdGhpbmsgdGhpcyAqbWlnaHQqIGJlIHBvdGVudGlhbGx5DQo+IHVzZWZ1bC4gQXNz dW1pbmcgdGhhdCBZQU5HIHdpbGwgYmVjb21lIHRoZSB1bml2ZXJzYWwgc2NoZW1hIGxhbmd1YWdl DQo+IGZvciBuZXR3b3JrIHByb3RvY29scyBpcyBub3QgcmVhbGlzdGljLg0KPiANCj4gPiANCj4g PiBNeSBwcmVmZXJlbmNlIHdvdWxkIGJlIFkzNC0wMiAoa2VlcCBhbnl4bWwsIGFkZCBhbnlkYXRh KSwgd2l0aCB0aGUNCj4gPiBjbGFyaWZpY2F0aW9ucyBzdWdnZXN0ZWQgYnkgSnVlcmdlbiAoZGlz Y291cmFnZSB0aGUgdXNhZ2Ugb2YgYW55eG1sKS4NCj4gPiANCj4gPj4gSSB1bmRlcnN0YW5kIHRo YXQgQW5keSB3YW50cyB0byBleGNsdWRlIFhNTCBtaXhlZCBjb250ZW50LCBzbyBJIGNhbg0KPiA+ PiBhbHNvIGFncmVlIHdpdGggYWRkaW5nIHJlc3RyaWN0aW9ucyBmb3IgYW55ZGF0YSBpbiB0aGUg c2Vuc2UgdGhhdCB0aGUNCj4gPj4gY29udGVudCBjYW4gKnBvdGVudGlhbGx5KiBiZSBtb2RlbGxl ZCBpbiBZQU5HLg0KPiA+IA0KPiA+IFllcywgSSB0aGluayB3ZSB3YW50IHRvIGFsbG93IGZvciB0 aGUgY2FzZSB3aGVyZSBhIGNvbnN1bWVyL3Byb2R1Y2VyDQo+ID4gb2YgJ2FueWRhdGEnIGRvZXMg bm90IGtub3cgdGhlIFlBTkcgZGF0YSBtb2RlbCAoZ2VuZXJpYyBsb2dnZXIsIHNvbWUNCj4gPiBw cm94eSwgZXRjKS4gIFNvICJwb3RlbnRpYWxseSIgbW9kZWxsZWQgaW4gWUFORyBzaG91bGQgYmUg ZmluZS4NCj4gPiANCj4gPiBUaGUgaXNzdWUgSSBzZWUgY2FuIGJlIGlsbHVzdHJhdGVkIGxpa2Ug dGhpczoNCj4gPiANCj4gPiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KPiA+ICBp bnB1dCB3LyBhbnlkYXRhIC0tPiB8IHNlcnZlciB8IC0tIG91dHB1dCAtLT4NCj4gPiAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KPiA+IA0KPiA+IEkuZS4sIHNvbWUgaW1wbGVtZW50 YXRpb24gZ2V0cyBkYXRhIHcvIGFueWRhdGEgaW4gaXQsIGFuZCBpcyBzdXBwb3NlZA0KPiA+IHRv IHNlbmQgdGhpcyB0byBzb21lIGNsaWVudCB0aGF0IG5lZWRzIHRvIGJlIGFibGUgdG8gaW50ZXJw cmV0IHRoaXMNCj4gPiBkYXRhLg0KPiA+IA0KPiA+IExldCdzIGFzc3VtZSB0aGUgZGF0YSBpcyB0 aGlzOg0KPiA+IA0KPiA+ICBuYW1lc3BhY2UgdXJuOng7DQo+ID4gICAuLi4NCj4gPiAgY29udGFp bmVyIHggew0KPiA+ICAgIGFueWRhdGEgeTsNCj4gPiAgfQ0KPiA+IA0KPiA+IGFuZCBvbmUgZXhh bXBsZSBvZiBzb21ldGhpbmcgd2UgY2FuIHB1dCBpbnRvIHRoaXMgYW55ZGF0YSBpczoNCj4gPiAN Cj4gPiAgbmFtZXNwYWNlIHVybjpmb287DQo+ID4gIC4uLg0KPiA+ICBjb250YWluZXIgZm9vIHsN Cj4gPiAgICBsZWFmIGJhciB7DQo+ID4gICAgICB0eXBlIGludDMyOw0KPiA+ICAgIH0NCj4gPiAg ICBsZWFmIGlmLXR5cGUgew0KPiA+ICAgICAgdHlwZSBpZGVudGl0eXJlZiB7DQo+ID4gICAgICAg IGJhc2UgaWY6aW50ZXJmYWNlLXR5cGU7DQo+ID4gICAgICB9DQo+ID4gICAgfQ0KPiA+ICB9DQo+ ID4gDQo+ID4gIG1vZHVsZSBleC1ldGhlcm5ldCB7DQo+ID4gICAgbmFtZXNwYWNlIHVybjpleGV0 aDsNCj4gPiAgICAuLi4NCj4gPiAgICBpZGVudGl0eSBldGhlcm5ldCB7IC4uLiB9DQo+ID4gIH0N Cj4gPiANCj4gPiANCj4gPiANCj4gPiBTbyB0aGUgaW5wdXQgY291bGQgYmU6DQo+ID4gDQo+ID4g IChBKQ0KPiA+ICA8eCB4bWxucz0idXJuOngiPg0KPiA+ICAgIDx5Pg0KPiA+ICAgICAgPGZvbyB4 bWxucz0idXJuOmZvbyIgeG1sbnM6cDA9InVybjpleGV0aCI+DQo+ID4gICAgICAgIDxiYXI+NDI8 L2Jhcj4NCj4gPiAgICAgICAgPGlmLXR5cGU+cDA6ZXRoZXJuZXQ8L2lmLXR5cGU+DQo+ID4gICAg ICA8L2Zvbz4NCj4gPiAgICA8L3k+DQo+ID4gIDwveD4NCj4gPiANCj4gPiANCj4gPiBUaGVyZSBh cmUgZm91ciBjYXNlczoNCj4gPiANCj4gPiAxLiAgaW5wdXQgeG1sLCBvdXRwdXQgeG1sDQo+ID4g DQo+ID4gIFRoZSBwcm9ibGVtIGhlcmUgaGFzIHRvIGRvIHdpdGggbmFtZXNwYWNlIHByZWZpeGVz Lg0KPiA+IA0KPiA+ICBTdXBwb3NlIHRoZSBpbnB1dCB3YXMgcmVjZWl2ZWQgYXM6DQo+ID4gDQo+ ID4gIChCKQ0KPiA+ICA8eCB4bWxucz0idXJuOngiIHhtbG5zOnAxPSJ1cm46ZXhldGgiPg0KPiA+ ICAgIDx5Pg0KPiA+ICAgICAgPGZvbyB4bWxucz0idXJuOmZvbyI+DQo+ID4gICAgICAgIDxiYXI+ NDI8L2Jhcj4NCj4gPiAgICAgICAgPGlmLXR5cGU+cDE6ZXRoZXJuZXQ8L2lmLXR5cGU+DQo+ID4g ICAgICA8L2Zvbz4NCj4gPiAgICA8L3k+DQo+ID4gIDwveD4NCj4gPiANCj4gPiAgVGhlIHNlcnZl ciBkb2Vzbid0IGtub3cgdGhhdCBpZi10eXBlIGlzIG9mIHR5cGUgaWRlbnRpdHlyZWYsIHNvIGl0 DQo+ID4gIGRvZXNuJ3Qga25vdyB0aGF0ICJldGg6IiBpcyBhIHByZWZpeC4gIEl0IGp1c3Qgc3Rv cmVzIGV2ZXJ5dGhpbmcgYXMNCj4gDQo+IFlvdSBwcm9iYWJseSBtZWFuIOKAnHAxOuKAnSBoZXJl Lg0KDQpZZXMuDQoNCj4gQnV0IGlmIHRoZSBzZXJ2ZXIgaGFzIHRoZSBkYXRhIG1vZGVsLCBpdA0K PiBzaG91bGQga25vdyB0aGlzIGlzIGFuIGlkZW50aXR5cmVmIGFuZCDigJxwMTrigJ0gaXMgYSBw cmVmaXgsIHJpZ2h0Pw0KDQpTdXJlLiAgVGhlIHVzZSBjYXNlIGlzIGFib3V0IHNlcnZlcnMgdGhh dCBkbyBub3Qga25vdyBhYm91dCB0aGUgZGF0YQ0KbW9kZWwuDQoNCj4gPiAgc3RyaW5ncy4gIEJ1 dCB3aGVuIGl0IHJldHVybnMgdGhpcyBub2RlIHRvIGEgY2xpZW50LCBpdCBtdXN0IG1ha2UNCj4g PiAgc3VyZSB0aGUgcHJlZml4IGlzIGRlY2xhcmVkIHByb3Blcmx5Lg0KPiA+IA0KPiA+ICBXZSBj YW4gc29sdmUgdGhpcyBmb3IgYW55ZGF0YSBieSBzYXlpbmcgdGhhdCANCj4gPiAgdGhlIGFueWRh dGEgbm9kZSBtdXN0IGhhdmUgYWxsIG5hbWVzcGFjZSBkZWNsYXJhdGlvbnMgaW4gdGhlIGFueWRh dGENCj4gPiAgc3VidHJlZSBpbiB0aGUgWE1MIGVuY29kaW5nLiAgVGh1cyB0aGUgaW5wdXQgKEIp IHdvdWxkIGJlIGlsbGVnYWwsDQo+ID4gIGJ1dCAoQSkgbGVnYWwuDQo+ID4gDQo+ID4gDQo+ID4g Mi4gIGlucHV0IGpzb24sIG91dHB1dCBqc29uDQo+ID4gDQo+ID4gIEluIGpzb24sIHRoZXJlIGFy ZSBubyBuYW1lc3BhY2UgcHJlZml4ZXMsIHNvIHRoYXQgaXMgbm90IGFuIGlzc3VlLg0KPiA+ICBB bHNvLCBpZiBib3RoIGlucHV0IGFuZCBvdXRwdXQgaXMganNvbiwgdGhlIGltcGxlbWVudGF0aW9u IGNhbiBzdG9yZQ0KPiA+ICB0aGUgZGF0YSBhcyByZWNlaXZlZCwgYW5kIHJldHVybiBpdCBpbiB0 aGUgc2FtZSB3YXkuDQo+ID4gDQo+ID4gDQo+ID4gMy4gIGlucHV0IHhtbCwgb3V0cHV0IGpzb24N Cj4gPiANCj4gPiAgVGhpcyBpcyB0cmlja3ksIHNpbmNlIGluIG9yZGVyIHRvIHByb2R1Y2UgY29y cmVjdCBqc29uIGJvdGggZm9yIGxlYWYNCj4gPiAgJ2JhcicgYW5kIGxlYWYgJ2lmLXR5cGUnLCB0 aGUgc2VydmVyIG5lZWRzIHNjaGVtYSBrbm93bGVkZ2U7ICdiYXInDQo+ID4gIG11c3QgYmUgZW5j b2RlZCBhcyA0MiByYXRoZXIgdGhhbiAiNDIiLCBhbmQgJ2lmLXR5cGUnIG11c3QgYmUNCj4gPiAg ZW5jb2RlZCBhcyAiZXgtZXRoZXJuZXQ6ZXRoZXJuZXQiIHJhdGhlciB0aGFuICJwMDpldGhlcm5l dOKAnS4NCj4gDQo+IEl0IGRvZXNu4oCZdCBtYWtlIG11Y2ggc2Vuc2UgdG8gbWUgdGhhdCB0aGUg c2VydmVyIGFjdCBhcyBhIHRyYW5zcGFyZW50DQo+IHJlbGF5LiBJIHRoaW5rIG9uZSBjYW4gYXNz dW1lIHRoYXQgZm9yIGV2ZXJ5IGFueWRhdGEgbm9kZSB0aGUgc2VydmVyDQo+IGhhcyBhIHNjaGVt YSwgYWx0aG91Z2ggaXQgbmVlZG7igJl0IGJlIGV4cHJlc3NlZCBpbiBZQU5HLg0KDQpJIHdvdWxk IHN0YXkgb3V0IG9mICJuZWVkbid0IGJlIGV4cHJlc3NlZCBpbiBZQU5HIi4gIExldCdzIGp1c3Qg c2F5DQp0aGF0IHRoZSBzZXJ2ZXIga25vd3MgdGhlIHNjaGVtYS4NCg0KDQo+IElmIHRoZXJlIHJl YWxseSB3YXMgYSB1c2UgY2FzZSBmb3IgYSBzY2hlbWEtYWdub3N0aWMgc2VydmVyLCB3ZSBjb3Vs ZA0KPiBkZWZpbmUgYSBkZWZhdWx0IChhbmQgbG9zc3kpIFhNTC0+SlNPTiB0cmFuc2xhdGlvbi4N Cg0KDQoNCi9tYXJ0aW4NCg== From nobody Wed Jan 28 02:26:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938291A0399 for ; Wed, 28 Jan 2015 02:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbhIKv6iwlw1 for ; Wed, 28 Jan 2015 02:25:55 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321BA1A0397 for ; Wed, 28 Jan 2015 02:25:54 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 4A8EB13F697; Wed, 28 Jan 2015 11:25:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422440752; bh=BpI7XO717/RN8VxYzgl4DeX2vkvGavXRmqkImBJmDLI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=J1hUZFrUWybpCZCCc3nb4Vhkg9/Spm+9vPrWBqqOYSwjTU0/G17GP2HWWKdRoHsGH h6TS5IdGm9FreBooTLZPmXt3qmcUKGwsLcxeR5xRQDB+ixGY+3CBLcozJ38NBGQvD0 s6pjJzSKTtM/3nIxlf0jv/G2jm8fh2AakJi/n2rM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150128.111052.1569834530678944655.mbj@tail-f.com> Date: Wed, 28 Jan 2015 11:25:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150128.100646.753961661897533382.mbj@tail-f.com> <06E2712F-AFAF-4652-BFED-1AEC0C98457A@nic.cz> <20150128.111052.1569834530678944655.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 10:25:57 -0000 > On 28 Jan 2015, at 11:10, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 28 Jan 2015, at 10:06, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 28 Jan 2015, at 09:10, Martin Bjorklund wrote: >>>>>=20 >>>>> Juergen Schoenwaelder = wrote: >>>>>> I do not think we make progress this way and we probably need to = find >>>>>> a way to do a mailing list hum to figure out where the _WG_ = stands on >>>>>> this issue and not just the two of us. >>>>>=20 >>>>> At this point, I think it would be useful if you could take a step >>>>> back and formulate the problem. I must I admit I got lost in the >>>>> discussion. I *think* the issue now has to do with the json = encoding >>>>> of anydata and anyxml, if we decide to introduce anydata? >>>>=20 >>>> Yes, the discussion sometimes wandered into areas that are = unrelated >>>> to anyxml/anydata. >>>>=20 >>>> As for anydata, I=E2=80=99d be happy with just renaming anyxml to = anydata, >>>=20 >>> I don't think works. It is not backwards compatible, and it would >>> break the definition in 6241. >>=20 >> Well, yes, I mean keeping anyxml as a (deprecated) synonym. >=20 > Not synonym, since 'anyxml' truly is any xml, which 'anydata' is not. > And probably not deprecated, but rather "think twice before using=E2=80=9D= . Do you mean that for modules containing anyxml no JSON encoding will be = defined? I=E2=80=99d prefer to keep the current definition in the yang-json draft = even though anyxml is a misnomer. There are other formulations in 6020 = that are XML- and NETCONF-specific. >=20 >> Which 6241 >> definition do you mean? >=20 > rpc edit-config etc. Search for anyxml. Sure, but it=E2=80=99s OK if anyxml continues to exist. Lada >=20 >> The advantage of this solution is that existing data formats (RDF >> comes to my mind) that have nothing in common with YANG can be >> potentially piggybacked in anydata. Andy will say such a use case >> doesn=E2=80=99t exist yet but I think this *might* be potentially >> useful. Assuming that YANG will become the universal schema language >> for network protocols is not realistic. >>=20 >>>=20 >>> My preference would be Y34-02 (keep anyxml, add anydata), with the >>> clarifications suggested by Juergen (discourage the usage of = anyxml). >>>=20 >>>> I understand that Andy wants to exclude XML mixed content, so I can >>>> also agree with adding restrictions for anydata in the sense that = the >>>> content can *potentially* be modelled in YANG. >>>=20 >>> Yes, I think we want to allow for the case where a consumer/producer >>> of 'anydata' does not know the YANG data model (generic logger, some >>> proxy, etc). So "potentially" modelled in YANG should be fine. >>>=20 >>> The issue I see can be illustrated like this: >>>=20 >>> +--------+ >>> input w/ anydata --> | server | -- output --> >>> +--------+ >>>=20 >>> I.e., some implementation gets data w/ anydata in it, and is = supposed >>> to send this to some client that needs to be able to interpret this >>> data. >>>=20 >>> Let's assume the data is this: >>>=20 >>> namespace urn:x; >>> ... >>> container x { >>> anydata y; >>> } >>>=20 >>> and one example of something we can put into this anydata is: >>>=20 >>> namespace urn:foo; >>> ... >>> container foo { >>> leaf bar { >>> type int32; >>> } >>> leaf if-type { >>> type identityref { >>> base if:interface-type; >>> } >>> } >>> } >>>=20 >>> module ex-ethernet { >>> namespace urn:exeth; >>> ... >>> identity ethernet { ... } >>> } >>>=20 >>>=20 >>>=20 >>> So the input could be: >>>=20 >>> (A) >>> >>> >>> >>> 42 >>> p0:ethernet >>> >>> >>> >>>=20 >>>=20 >>> There are four cases: >>>=20 >>> 1. input xml, output xml >>>=20 >>> The problem here has to do with namespace prefixes. >>>=20 >>> Suppose the input was received as: >>>=20 >>> (B) >>> >>> >>> >>> 42 >>> p1:ethernet >>> >>> >>> >>>=20 >>> The server doesn't know that if-type is of type identityref, so it >>> doesn't know that "eth:" is a prefix. It just stores everything as >>=20 >> You probably mean =E2=80=9Cp1:=E2=80=9D here. >=20 > Yes. >=20 >> But if the server has the data model, it >> should know this is an identityref and =E2=80=9Cp1:=E2=80=9D is a = prefix, right? >=20 > Sure. The use case is about servers that do not know about the data > model. >=20 >>> strings. But when it returns this node to a client, it must make >>> sure the prefix is declared properly. >>>=20 >>> We can solve this for anydata by saying that=20 >>> the anydata node must have all namespace declarations in the anydata >>> subtree in the XML encoding. Thus the input (B) would be illegal, >>> but (A) legal. >>>=20 >>>=20 >>> 2. input json, output json >>>=20 >>> In json, there are no namespace prefixes, so that is not an issue. >>> Also, if both input and output is json, the implementation can store >>> the data as received, and return it in the same way. >>>=20 >>>=20 >>> 3. input xml, output json >>>=20 >>> This is tricky, since in order to produce correct json both for leaf >>> 'bar' and leaf 'if-type', the server needs schema knowledge; 'bar' >>> must be encoded as 42 rather than "42", and 'if-type' must be >>> encoded as "ex-ethernet:ethernet" rather than "p0:ethernet=E2=80=9D. >>=20 >> It doesn=E2=80=99t make much sense to me that the server act as a = transparent >> relay. I think one can assume that for every anydata node the server >> has a schema, although it needn=E2=80=99t be expressed in YANG. >=20 > I would stay out of "needn't be expressed in YANG". Let's just say > that the server knows the schema. >=20 >=20 >> If there really was a use case for a schema-agnostic server, we could >> define a default (and lossy) XML->JSON translation. >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 28 02:29:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8D41A044D for ; Wed, 28 Jan 2015 02:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd0VaONedaNp for ; Wed, 28 Jan 2015 02:29:09 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BC91A039F for ; Wed, 28 Jan 2015 02:29:08 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so18109982lab.6 for ; Wed, 28 Jan 2015 02:29:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NoHean1UZ9Qa6zsf1OATOI8DvQbZvVfqSDox7BnbU60=; b=EVHu6J3MO6EAPCNfjqtjG+k7bhTkFJ0Tc3oSZd8RjW0xXT+d4/2KH1iz0TGO6YCKyV /34+BxePjrN3QsvakbZSWEjOlLTovzh444D+0XvTTAQGTUL/GIvrIAwllkDGzLq1vZt6 +VPDr5s6jv/deE503XIX0qJ0IdBLjkNEIfftj/TiSRae43cxbktHt3t6XVRN86Xsh0vz hqRpZR+QSRDlqj7IAjQgMrOe4Wo5NWhJ4u+Z/lM0r1/jBPwm0VcnRs0Bl/qJOeZ4enjL 9JkNfLg7u2DHhyN1IUEd4sCyDe4OGXF/ctTGc+94ywnAX7HWplOmHqcfWuX2/rYmyxg+ +Gmw== X-Gm-Message-State: ALoCoQlFCtzgQ3KzgzaYOXtNWGhx8l8S8YDCQMvdaEawAn8TZG5OqCufMD2/XdCzR2pCqmuWQTBK MIME-Version: 1.0 X-Received: by 10.152.42.164 with SMTP id p4mr6933594lal.45.1422440947334; Wed, 28 Jan 2015 02:29:07 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 28 Jan 2015 02:29:07 -0800 (PST) In-Reply-To: <20150128.091057.1523590536703844716.mbj@tail-f.com> References: <20150127151202.GA89027@elstar.local> <20150127170907.GB89308@elstar.local> <20150128.091057.1523590536703844716.mbj@tail-f.com> Date: Wed, 28 Jan 2015 02:29:07 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 10:29:11 -0000 On Wed, Jan 28, 2015 at 12:10 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> I do not think we make progress this way and we probably need to find >> a way to do a mailing list hum to figure out where the _WG_ stands on >> this issue and not just the two of us. > > At this point, I think it would be useful if you could take a step > back and formulate the problem. I must I admit I got lost in the > discussion. I *think* the issue now has to do with the json encoding > of anydata and anyxml, if we decide to introduce anydata? > > I strongly agree with Juergen on the problem and the solution. The problem is that the sender MAY choose a JSON encoding format which is has some JSON type, even though the JSON data type is meaningless within anyxml/anydata. The solution is that the receiver MUST convert from the provided JSON type to some YANG type. If the sender does not know the YANG schema, a safe encoding must be picked (i.e., string). A receiver that understands the YANG schema MUST convert to the expected YANG type if possible. (e.g., Sending "purple" for a YANG boolean or number will fail at the final receiver). If the final YANG node is a boolean, then what difference does it make if the input from the sender is 42 or "42"? There is no benefit in "remembering" that a number was sent vs. a string. The JSON type is totally irrelevant to the transfer of anydata. > > /martin Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jan 28 03:05:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE9C1A1A2F for ; Wed, 28 Jan 2015 03:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OVzIsKELRNO for ; Wed, 28 Jan 2015 03:05:23 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0469E1A1A2D for ; Wed, 28 Jan 2015 03:05:22 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d] (unknown [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d]) by mail.nic.cz (Postfix) with ESMTPSA id 9D72F13F755; Wed, 28 Jan 2015 12:05:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422443121; bh=OG4ZIrPEknihCCH4v+ExEBEbHSuyroHSG5bSQ0+l3GM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lQthOOGWR15bhuYeqfhvPT8mPK6dXIi2Ep8tr4tyam3SPD4k6i1xvKLe5i225AnPo wcRSuxh9VGLM4tUc/cGX9t6cYwOv0y8uSOYU3vi7CbtQat44+gzIUkyz3GPrsU7CEE cV8Qgjw4jSeUi7VA6z3tgUe38N08ZGxXot+2z1kA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 28 Jan 2015 12:05:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150127151202.GA89027@elstar.local> <20150127170907.GB89308@elstar.local> <20150128.091057.1523590536703844716.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:05:25 -0000 > On 28 Jan 2015, at 11:29, Andy Bierman wrote: >=20 > On Wed, Jan 28, 2015 at 12:10 AM, Martin Bjorklund = wrote: >> Juergen Schoenwaelder wrote: >>> I do not think we make progress this way and we probably need to = find >>> a way to do a mailing list hum to figure out where the _WG_ stands = on >>> this issue and not just the two of us. >>=20 >> At this point, I think it would be useful if you could take a step >> back and formulate the problem. I must I admit I got lost in the >> discussion. I *think* the issue now has to do with the json encoding >> of anydata and anyxml, if we decide to introduce anydata? >>=20 >>=20 >=20 > I strongly agree with Juergen on the problem and the solution. >=20 > The problem is that the sender MAY choose a JSON encoding > format which is has some JSON type, even though the JSON > data type is meaningless within anyxml/anydata. >=20 > The solution is that the receiver MUST convert from the > provided JSON type to some YANG type. If the sender > does not know the YANG schema, a safe encoding must > be picked (i.e., string). A receiver that understands the Why is string the only safe encoding? The data usually don=E2=80=99t = appear out of nowhere - and inside an application they have some type. = Why should be a sender forced to translating a number to a string = instead of passing it simply to a JSON encoder? Lada > YANG schema MUST convert to the expected YANG type > if possible. (e.g., Sending "purple" for a YANG boolean or > number will fail at the final receiver). >=20 > If the final YANG node is a boolean, then what difference > does it make if the input from the sender is 42 or "42"? > There is no benefit in "remembering" that a number was > sent vs. a string. The JSON type is totally irrelevant to > the transfer of anydata. >=20 >=20 >>=20 >> /martin >=20 > Andy >=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 28 03:19:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522FE1A1A3C for ; Wed, 28 Jan 2015 03:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slluw-L2Q2MX for ; Wed, 28 Jan 2015 03:19:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id A3E971A039F for ; Wed, 28 Jan 2015 03:19:31 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B44012801A6; Wed, 28 Jan 2015 12:19:30 +0100 (CET) Date: Wed, 28 Jan 2015 12:22:03 +0100 (CET) Message-Id: <20150128.122203.1679178904226428559.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <06E2712F-AFAF-4652-BFED-1AEC0C98457A@nic.cz> <20150128.111052.1569834530678944655.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:19:34 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjggSmFu IDIwMTUsIGF0IDExOjEwLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+PiBPbiAyOCBKYW4gMjAxNSwgYXQgMTA6MDYsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0 YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FA bmljLmN6PiB3cm90ZToNCj4gPj4+PiANCj4gPj4+Pj4gT24gMjggSmFuIDIwMTUsIGF0IDA5OjEw LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+ID4+Pj4+IA0KPiA+ Pj4+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZT4gd3JvdGU6DQo+ID4+Pj4+PiBJIGRvIG5vdCB0aGluayB3ZSBtYWtlIHByb2dyZXNz IHRoaXMgd2F5IGFuZCB3ZSBwcm9iYWJseSBuZWVkIHRvIGZpbmQNCj4gPj4+Pj4+IGEgd2F5IHRv IGRvIGEgbWFpbGluZyBsaXN0IGh1bSB0byBmaWd1cmUgb3V0IHdoZXJlIHRoZSBfV0dfIHN0YW5k cyBvbg0KPiA+Pj4+Pj4gdGhpcyBpc3N1ZSBhbmQgbm90IGp1c3QgdGhlIHR3byBvZiB1cy4NCj4g Pj4+Pj4gDQo+ID4+Pj4+IEF0IHRoaXMgcG9pbnQsIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVs IGlmIHlvdSBjb3VsZCB0YWtlIGEgc3RlcA0KPiA+Pj4+PiBiYWNrIGFuZCBmb3JtdWxhdGUgdGhl IHByb2JsZW0uICBJIG11c3QgSSBhZG1pdCBJIGdvdCBsb3N0IGluIHRoZQ0KPiA+Pj4+PiBkaXNj dXNzaW9uLiAgSSAqdGhpbmsqIHRoZSBpc3N1ZSBub3cgaGFzIHRvIGRvIHdpdGggdGhlIGpzb24g ZW5jb2RpbmcNCj4gPj4+Pj4gb2YgYW55ZGF0YSBhbmQgYW55eG1sLCBpZiB3ZSBkZWNpZGUgdG8g aW50cm9kdWNlIGFueWRhdGE/DQo+ID4+Pj4gDQo+ID4+Pj4gWWVzLCB0aGUgZGlzY3Vzc2lvbiBz b21ldGltZXMgd2FuZGVyZWQgaW50byBhcmVhcyB0aGF0IGFyZSB1bnJlbGF0ZWQNCj4gPj4+PiB0 byBhbnl4bWwvYW55ZGF0YS4NCj4gPj4+PiANCj4gPj4+PiBBcyBmb3IgYW55ZGF0YSwgSeKAmWQg YmUgaGFwcHkgd2l0aCBqdXN0IHJlbmFtaW5nIGFueXhtbCB0byBhbnlkYXRhLA0KPiA+Pj4gDQo+ ID4+PiBJIGRvbid0IHRoaW5rIHdvcmtzLiAgSXQgaXMgbm90IGJhY2t3YXJkcyBjb21wYXRpYmxl LCBhbmQgaXQgd291bGQNCj4gPj4+IGJyZWFrIHRoZSBkZWZpbml0aW9uIGluIDYyNDEuDQo+ID4+ IA0KPiA+PiBXZWxsLCB5ZXMsIEkgbWVhbiBrZWVwaW5nIGFueXhtbCBhcyBhIChkZXByZWNhdGVk KSBzeW5vbnltLg0KPiA+IA0KPiA+IE5vdCBzeW5vbnltLCBzaW5jZSAnYW55eG1sJyB0cnVseSBp cyBhbnkgeG1sLCB3aGljaCAnYW55ZGF0YScgaXMgbm90Lg0KPiA+IEFuZCBwcm9iYWJseSBub3Qg ZGVwcmVjYXRlZCwgYnV0IHJhdGhlciAidGhpbmsgdHdpY2UgYmVmb3JlIHVzaW5n4oCdLg0KPiAN Cj4gRG8geW91IG1lYW4gdGhhdCBmb3IgbW9kdWxlcyBjb250YWluaW5nIGFueXhtbCBubyBKU09O IGVuY29kaW5nIHdpbGwNCj4gYmUgZGVmaW5lZD8NCg0KVGhlIGpzb24gZG9jIGhhcyB0byBzYXkg KnNvbWV0aGluZyosIGFuZCBtYXliZSB0aGUgY3VycmVudCB0ZXh0IGlzDQpmaW5lLiAgSXQgc2hv dWxkIGJlIHBvaW50ZWQgb3V0IHRoYXQgdGhlIGFueXhtbCBtYXBwaW5nIGlzDQppbXBsZW1lbnRh dGlvbiBkZXBlbmRlbnQuDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gSeKAmWQgcHJlZmVyIHRv IGtlZXAgdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBpbiB0aGUgeWFuZy1qc29uIGRyYWZ0IGV2ZW4g dGhvdWdoIGFueXhtbCBpcyBhIG1pc25vbWVyLiBUaGVyZSBhcmUgb3RoZXIgZm9ybXVsYXRpb25z IGluIDYwMjAgdGhhdCBhcmUgWE1MLSBhbmQgTkVUQ09ORi1zcGVjaWZpYy4NCj4gDQo+ID4gDQo+ ID4+IFdoaWNoIDYyNDENCj4gPj4gZGVmaW5pdGlvbiBkbyB5b3UgbWVhbj8NCj4gPiANCj4gPiBy cGMgZWRpdC1jb25maWcgZXRjLiAgU2VhcmNoIGZvciBhbnl4bWwuDQo+IA0KPiBTdXJlLCBidXQg aXTigJlzIE9LIGlmIGFueXhtbCBjb250aW51ZXMgdG8gZXhpc3QuDQo+IA0KPiBMYWRhDQo+IA0K PiA+IA0KPiA+PiBUaGUgYWR2YW50YWdlIG9mIHRoaXMgc29sdXRpb24gaXMgdGhhdCBleGlzdGlu ZyBkYXRhIGZvcm1hdHMgKFJERg0KPiA+PiBjb21lcyB0byBteSBtaW5kKSB0aGF0IGhhdmUgbm90 aGluZyBpbiBjb21tb24gd2l0aCBZQU5HIGNhbiBiZQ0KPiA+PiBwb3RlbnRpYWxseSBwaWdneWJh Y2tlZCBpbiBhbnlkYXRhLiBBbmR5IHdpbGwgc2F5IHN1Y2ggYSB1c2UgY2FzZQ0KPiA+PiBkb2Vz buKAmXQgZXhpc3QgeWV0IGJ1dCBJIHRoaW5rIHRoaXMgKm1pZ2h0KiBiZSBwb3RlbnRpYWxseQ0K PiA+PiB1c2VmdWwuIEFzc3VtaW5nIHRoYXQgWUFORyB3aWxsIGJlY29tZSB0aGUgdW5pdmVyc2Fs IHNjaGVtYSBsYW5ndWFnZQ0KPiA+PiBmb3IgbmV0d29yayBwcm90b2NvbHMgaXMgbm90IHJlYWxp c3RpYy4NCj4gPj4gDQo+ID4+PiANCj4gPj4+IE15IHByZWZlcmVuY2Ugd291bGQgYmUgWTM0LTAy IChrZWVwIGFueXhtbCwgYWRkIGFueWRhdGEpLCB3aXRoIHRoZQ0KPiA+Pj4gY2xhcmlmaWNhdGlv bnMgc3VnZ2VzdGVkIGJ5IEp1ZXJnZW4gKGRpc2NvdXJhZ2UgdGhlIHVzYWdlIG9mIGFueXhtbCku DQo+ID4+PiANCj4gPj4+PiBJIHVuZGVyc3RhbmQgdGhhdCBBbmR5IHdhbnRzIHRvIGV4Y2x1ZGUg WE1MIG1peGVkIGNvbnRlbnQsIHNvIEkgY2FuDQo+ID4+Pj4gYWxzbyBhZ3JlZSB3aXRoIGFkZGlu ZyByZXN0cmljdGlvbnMgZm9yIGFueWRhdGEgaW4gdGhlIHNlbnNlIHRoYXQgdGhlDQo+ID4+Pj4g Y29udGVudCBjYW4gKnBvdGVudGlhbGx5KiBiZSBtb2RlbGxlZCBpbiBZQU5HLg0KPiA+Pj4gDQo+ ID4+PiBZZXMsIEkgdGhpbmsgd2Ugd2FudCB0byBhbGxvdyBmb3IgdGhlIGNhc2Ugd2hlcmUgYSBj b25zdW1lci9wcm9kdWNlcg0KPiA+Pj4gb2YgJ2FueWRhdGEnIGRvZXMgbm90IGtub3cgdGhlIFlB TkcgZGF0YSBtb2RlbCAoZ2VuZXJpYyBsb2dnZXIsIHNvbWUNCj4gPj4+IHByb3h5LCBldGMpLiAg U28gInBvdGVudGlhbGx5IiBtb2RlbGxlZCBpbiBZQU5HIHNob3VsZCBiZSBmaW5lLg0KPiA+Pj4g DQo+ID4+PiBUaGUgaXNzdWUgSSBzZWUgY2FuIGJlIGlsbHVzdHJhdGVkIGxpa2UgdGhpczoNCj4g Pj4+IA0KPiA+Pj4gICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KPiA+Pj4gaW5wdXQg dy8gYW55ZGF0YSAtLT4gfCBzZXJ2ZXIgfCAtLSBvdXRwdXQgLS0+DQo+ID4+PiAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0rDQo+ID4+PiANCj4gPj4+IEkuZS4sIHNvbWUgaW1wbGVtZW50 YXRpb24gZ2V0cyBkYXRhIHcvIGFueWRhdGEgaW4gaXQsIGFuZCBpcyBzdXBwb3NlZA0KPiA+Pj4g dG8gc2VuZCB0aGlzIHRvIHNvbWUgY2xpZW50IHRoYXQgbmVlZHMgdG8gYmUgYWJsZSB0byBpbnRl cnByZXQgdGhpcw0KPiA+Pj4gZGF0YS4NCj4gPj4+IA0KPiA+Pj4gTGV0J3MgYXNzdW1lIHRoZSBk YXRhIGlzIHRoaXM6DQo+ID4+PiANCj4gPj4+IG5hbWVzcGFjZSB1cm46eDsNCj4gPj4+ICAuLi4N Cj4gPj4+IGNvbnRhaW5lciB4IHsNCj4gPj4+ICAgYW55ZGF0YSB5Ow0KPiA+Pj4gfQ0KPiA+Pj4g DQo+ID4+PiBhbmQgb25lIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHdlIGNhbiBwdXQgaW50byB0aGlz IGFueWRhdGEgaXM6DQo+ID4+PiANCj4gPj4+IG5hbWVzcGFjZSB1cm46Zm9vOw0KPiA+Pj4gLi4u DQo+ID4+PiBjb250YWluZXIgZm9vIHsNCj4gPj4+ICAgbGVhZiBiYXIgew0KPiA+Pj4gICAgIHR5 cGUgaW50MzI7DQo+ID4+PiAgIH0NCj4gPj4+ICAgbGVhZiBpZi10eXBlIHsNCj4gPj4+ICAgICB0 eXBlIGlkZW50aXR5cmVmIHsNCj4gPj4+ICAgICAgIGJhc2UgaWY6aW50ZXJmYWNlLXR5cGU7DQo+ ID4+PiAgICAgfQ0KPiA+Pj4gICB9DQo+ID4+PiB9DQo+ID4+PiANCj4gPj4+IG1vZHVsZSBleC1l dGhlcm5ldCB7DQo+ID4+PiAgIG5hbWVzcGFjZSB1cm46ZXhldGg7DQo+ID4+PiAgIC4uLg0KPiA+ Pj4gICBpZGVudGl0eSBldGhlcm5ldCB7IC4uLiB9DQo+ID4+PiB9DQo+ID4+PiANCj4gPj4+IA0K PiA+Pj4gDQo+ID4+PiBTbyB0aGUgaW5wdXQgY291bGQgYmU6DQo+ID4+PiANCj4gPj4+IChBKQ0K PiA+Pj4gPHggeG1sbnM9InVybjp4Ij4NCj4gPj4+ICAgPHk+DQo+ID4+PiAgICAgPGZvbyB4bWxu cz0idXJuOmZvbyIgeG1sbnM6cDA9InVybjpleGV0aCI+DQo+ID4+PiAgICAgICA8YmFyPjQyPC9i YXI+DQo+ID4+PiAgICAgICA8aWYtdHlwZT5wMDpldGhlcm5ldDwvaWYtdHlwZT4NCj4gPj4+ICAg ICA8L2Zvbz4NCj4gPj4+ICAgPC95Pg0KPiA+Pj4gPC94Pg0KPiA+Pj4gDQo+ID4+PiANCj4gPj4+ IFRoZXJlIGFyZSBmb3VyIGNhc2VzOg0KPiA+Pj4gDQo+ID4+PiAxLiAgaW5wdXQgeG1sLCBvdXRw dXQgeG1sDQo+ID4+PiANCj4gPj4+IFRoZSBwcm9ibGVtIGhlcmUgaGFzIHRvIGRvIHdpdGggbmFt ZXNwYWNlIHByZWZpeGVzLg0KPiA+Pj4gDQo+ID4+PiBTdXBwb3NlIHRoZSBpbnB1dCB3YXMgcmVj ZWl2ZWQgYXM6DQo+ID4+PiANCj4gPj4+IChCKQ0KPiA+Pj4gPHggeG1sbnM9InVybjp4IiB4bWxu czpwMT0idXJuOmV4ZXRoIj4NCj4gPj4+ICAgPHk+DQo+ID4+PiAgICAgPGZvbyB4bWxucz0idXJu OmZvbyI+DQo+ID4+PiAgICAgICA8YmFyPjQyPC9iYXI+DQo+ID4+PiAgICAgICA8aWYtdHlwZT5w MTpldGhlcm5ldDwvaWYtdHlwZT4NCj4gPj4+ICAgICA8L2Zvbz4NCj4gPj4+ICAgPC95Pg0KPiA+ Pj4gPC94Pg0KPiA+Pj4gDQo+ID4+PiBUaGUgc2VydmVyIGRvZXNuJ3Qga25vdyB0aGF0IGlmLXR5 cGUgaXMgb2YgdHlwZSBpZGVudGl0eXJlZiwgc28gaXQNCj4gPj4+IGRvZXNuJ3Qga25vdyB0aGF0 ICJldGg6IiBpcyBhIHByZWZpeC4gIEl0IGp1c3Qgc3RvcmVzIGV2ZXJ5dGhpbmcgYXMNCj4gPj4g DQo+ID4+IFlvdSBwcm9iYWJseSBtZWFuIOKAnHAxOuKAnSBoZXJlLg0KPiA+IA0KPiA+IFllcy4N Cj4gPiANCj4gPj4gQnV0IGlmIHRoZSBzZXJ2ZXIgaGFzIHRoZSBkYXRhIG1vZGVsLCBpdA0KPiA+ PiBzaG91bGQga25vdyB0aGlzIGlzIGFuIGlkZW50aXR5cmVmIGFuZCDigJxwMTrigJ0gaXMgYSBw cmVmaXgsIHJpZ2h0Pw0KPiA+IA0KPiA+IFN1cmUuICBUaGUgdXNlIGNhc2UgaXMgYWJvdXQgc2Vy dmVycyB0aGF0IGRvIG5vdCBrbm93IGFib3V0IHRoZSBkYXRhDQo+ID4gbW9kZWwuDQo+ID4gDQo+ ID4+PiBzdHJpbmdzLiAgQnV0IHdoZW4gaXQgcmV0dXJucyB0aGlzIG5vZGUgdG8gYSBjbGllbnQs IGl0IG11c3QgbWFrZQ0KPiA+Pj4gc3VyZSB0aGUgcHJlZml4IGlzIGRlY2xhcmVkIHByb3Blcmx5 Lg0KPiA+Pj4gDQo+ID4+PiBXZSBjYW4gc29sdmUgdGhpcyBmb3IgYW55ZGF0YSBieSBzYXlpbmcg dGhhdCANCj4gPj4+IHRoZSBhbnlkYXRhIG5vZGUgbXVzdCBoYXZlIGFsbCBuYW1lc3BhY2UgZGVj bGFyYXRpb25zIGluIHRoZSBhbnlkYXRhDQo+ID4+PiBzdWJ0cmVlIGluIHRoZSBYTUwgZW5jb2Rp bmcuICBUaHVzIHRoZSBpbnB1dCAoQikgd291bGQgYmUgaWxsZWdhbCwNCj4gPj4+IGJ1dCAoQSkg bGVnYWwuDQo+ID4+PiANCj4gPj4+IA0KPiA+Pj4gMi4gIGlucHV0IGpzb24sIG91dHB1dCBqc29u DQo+ID4+PiANCj4gPj4+IEluIGpzb24sIHRoZXJlIGFyZSBubyBuYW1lc3BhY2UgcHJlZml4ZXMs IHNvIHRoYXQgaXMgbm90IGFuIGlzc3VlLg0KPiA+Pj4gQWxzbywgaWYgYm90aCBpbnB1dCBhbmQg b3V0cHV0IGlzIGpzb24sIHRoZSBpbXBsZW1lbnRhdGlvbiBjYW4gc3RvcmUNCj4gPj4+IHRoZSBk YXRhIGFzIHJlY2VpdmVkLCBhbmQgcmV0dXJuIGl0IGluIHRoZSBzYW1lIHdheS4NCj4gPj4+IA0K PiA+Pj4gDQo+ID4+PiAzLiAgaW5wdXQgeG1sLCBvdXRwdXQganNvbg0KPiA+Pj4gDQo+ID4+PiBU aGlzIGlzIHRyaWNreSwgc2luY2UgaW4gb3JkZXIgdG8gcHJvZHVjZSBjb3JyZWN0IGpzb24gYm90 aCBmb3IgbGVhZg0KPiA+Pj4gJ2JhcicgYW5kIGxlYWYgJ2lmLXR5cGUnLCB0aGUgc2VydmVyIG5l ZWRzIHNjaGVtYSBrbm93bGVkZ2U7ICdiYXInDQo+ID4+PiBtdXN0IGJlIGVuY29kZWQgYXMgNDIg cmF0aGVyIHRoYW4gIjQyIiwgYW5kICdpZi10eXBlJyBtdXN0IGJlDQo+ID4+PiBlbmNvZGVkIGFz ICJleC1ldGhlcm5ldDpldGhlcm5ldCIgcmF0aGVyIHRoYW4gInAwOmV0aGVybmV04oCdLg0KPiA+ PiANCj4gPj4gSXQgZG9lc27igJl0IG1ha2UgbXVjaCBzZW5zZSB0byBtZSB0aGF0IHRoZSBzZXJ2 ZXIgYWN0IGFzIGEgdHJhbnNwYXJlbnQNCj4gPj4gcmVsYXkuIEkgdGhpbmsgb25lIGNhbiBhc3N1 bWUgdGhhdCBmb3IgZXZlcnkgYW55ZGF0YSBub2RlIHRoZSBzZXJ2ZXINCj4gPj4gaGFzIGEgc2No ZW1hLCBhbHRob3VnaCBpdCBuZWVkbuKAmXQgYmUgZXhwcmVzc2VkIGluIFlBTkcuDQo+ID4gDQo+ ID4gSSB3b3VsZCBzdGF5IG91dCBvZiAibmVlZG4ndCBiZSBleHByZXNzZWQgaW4gWUFORyIuICBM ZXQncyBqdXN0IHNheQ0KPiA+IHRoYXQgdGhlIHNlcnZlciBrbm93cyB0aGUgc2NoZW1hLg0KPiA+ IA0KPiA+IA0KPiA+PiBJZiB0aGVyZSByZWFsbHkgd2FzIGEgdXNlIGNhc2UgZm9yIGEgc2NoZW1h LWFnbm9zdGljIHNlcnZlciwgd2UgY291bGQNCj4gPj4gZGVmaW5lIGEgZGVmYXVsdCAoYW5kIGxv c3N5KSBYTUwtPkpTT04gdHJhbnNsYXRpb24uDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gL21hcnRp bg0KPiANCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElE OiBFNzRFOEMwQw0KPiANCj4gDQo+IA0KPiANCg== From nobody Wed Jan 28 03:56:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433C31A1A8E for ; Wed, 28 Jan 2015 03:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G9jMnAIEOTG for ; Wed, 28 Jan 2015 03:56:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEE31A1A77 for ; Wed, 28 Jan 2015 03:56:15 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d] (unknown [IPv6:2001:718:1a02:1:e19c:d35d:bfd5:ab2d]) by mail.nic.cz (Postfix) with ESMTPSA id A5EA213F9AF; Wed, 28 Jan 2015 12:56:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422446173; bh=hZYQV7pd3ly7Gd3TVSZaY5udqlm2pUtvdo6gnx7Zk4w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iy+v0gUyAPgtNea1dy1gFEihE0ENIY8mXvWW65xKuDmJSjtY+SrLp4aiKHrGHrwo2 9rLLyhOzc7WpOMn7a2bK0bsxq6XOwHqaEXSBrXOQGmNKz/sw+7zf4D0klYN1o6X8qF L3LcilKNmbRsCuo3LZ8XDjAPpgXL+V9acw+prAik= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150128.122203.1679178904226428559.mbj@tail-f.com> Date: Wed, 28 Jan 2015 12:56:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <328B1F0F-61AB-4A97-94DB-A7F90329C585@nic.cz> References: <06E2712F-AFAF-4652-BFED-1AEC0C98457A@nic.cz> <20150128.111052.1569834530678944655.mbj@tail-f.com> <20150128.122203.1679178904226428559.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:56:18 -0000 > On 28 Jan 2015, at 12:22, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 28 Jan 2015, at 11:10, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 28 Jan 2015, at 10:06, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 28 Jan 2015, at 09:10, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Juergen Schoenwaelder = wrote: >>>>>>>> I do not think we make progress this way and we probably need = to find >>>>>>>> a way to do a mailing list hum to figure out where the _WG_ = stands on >>>>>>>> this issue and not just the two of us. >>>>>>>=20 >>>>>>> At this point, I think it would be useful if you could take a = step >>>>>>> back and formulate the problem. I must I admit I got lost in = the >>>>>>> discussion. I *think* the issue now has to do with the json = encoding >>>>>>> of anydata and anyxml, if we decide to introduce anydata? >>>>>>=20 >>>>>> Yes, the discussion sometimes wandered into areas that are = unrelated >>>>>> to anyxml/anydata. >>>>>>=20 >>>>>> As for anydata, I=E2=80=99d be happy with just renaming anyxml to = anydata, >>>>>=20 >>>>> I don't think works. It is not backwards compatible, and it would >>>>> break the definition in 6241. >>>>=20 >>>> Well, yes, I mean keeping anyxml as a (deprecated) synonym. >>>=20 >>> Not synonym, since 'anyxml' truly is any xml, which 'anydata' is = not. >>> And probably not deprecated, but rather "think twice before = using=E2=80=9D. >>=20 >> Do you mean that for modules containing anyxml no JSON encoding will >> be defined? >=20 > The json doc has to say *something*, and maybe the current text is > fine. It should be pointed out that the anyxml mapping is > implementation dependent. The current text is: =E2=80=9CThis document defines no mapping between the contents of = JSON- and XML-encoded anyxml instances.=E2=80=9D Isn=E2=80=99t it sufficient? The -00 revision had a formulation that=E2=80=99s closer to what you = suggest: =E2=80=9C=E2=80=A6, translation of anyxml contents is necessarily = application-specific and outside the scope of this document.=E2=80=9D However, Juergen didn=E2=80=99t like it so I tried to reformulate it in = a more neutral way. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> I=E2=80=99d prefer to keep the current definition in the yang-json = draft even though anyxml is a misnomer. There are other formulations in = 6020 that are XML- and NETCONF-specific. >>=20 >>>=20 >>>> Which 6241 >>>> definition do you mean? >>>=20 >>> rpc edit-config etc. Search for anyxml. >>=20 >> Sure, but it=E2=80=99s OK if anyxml continues to exist. >>=20 >> Lada >>=20 >>>=20 >>>> The advantage of this solution is that existing data formats (RDF >>>> comes to my mind) that have nothing in common with YANG can be >>>> potentially piggybacked in anydata. Andy will say such a use case >>>> doesn=E2=80=99t exist yet but I think this *might* be potentially >>>> useful. Assuming that YANG will become the universal schema = language >>>> for network protocols is not realistic. >>>>=20 >>>>>=20 >>>>> My preference would be Y34-02 (keep anyxml, add anydata), with the >>>>> clarifications suggested by Juergen (discourage the usage of = anyxml). >>>>>=20 >>>>>> I understand that Andy wants to exclude XML mixed content, so I = can >>>>>> also agree with adding restrictions for anydata in the sense that = the >>>>>> content can *potentially* be modelled in YANG. >>>>>=20 >>>>> Yes, I think we want to allow for the case where a = consumer/producer >>>>> of 'anydata' does not know the YANG data model (generic logger, = some >>>>> proxy, etc). So "potentially" modelled in YANG should be fine. >>>>>=20 >>>>> The issue I see can be illustrated like this: >>>>>=20 >>>>> +--------+ >>>>> input w/ anydata --> | server | -- output --> >>>>> +--------+ >>>>>=20 >>>>> I.e., some implementation gets data w/ anydata in it, and is = supposed >>>>> to send this to some client that needs to be able to interpret = this >>>>> data. >>>>>=20 >>>>> Let's assume the data is this: >>>>>=20 >>>>> namespace urn:x; >>>>> ... >>>>> container x { >>>>> anydata y; >>>>> } >>>>>=20 >>>>> and one example of something we can put into this anydata is: >>>>>=20 >>>>> namespace urn:foo; >>>>> ... >>>>> container foo { >>>>> leaf bar { >>>>> type int32; >>>>> } >>>>> leaf if-type { >>>>> type identityref { >>>>> base if:interface-type; >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> module ex-ethernet { >>>>> namespace urn:exeth; >>>>> ... >>>>> identity ethernet { ... } >>>>> } >>>>>=20 >>>>>=20 >>>>>=20 >>>>> So the input could be: >>>>>=20 >>>>> (A) >>>>> >>>>> >>>>> >>>>> 42 >>>>> p0:ethernet >>>>> >>>>> >>>>> >>>>>=20 >>>>>=20 >>>>> There are four cases: >>>>>=20 >>>>> 1. input xml, output xml >>>>>=20 >>>>> The problem here has to do with namespace prefixes. >>>>>=20 >>>>> Suppose the input was received as: >>>>>=20 >>>>> (B) >>>>> >>>>> >>>>> >>>>> 42 >>>>> p1:ethernet >>>>> >>>>> >>>>> >>>>>=20 >>>>> The server doesn't know that if-type is of type identityref, so it >>>>> doesn't know that "eth:" is a prefix. It just stores everything = as >>>>=20 >>>> You probably mean =E2=80=9Cp1:=E2=80=9D here. >>>=20 >>> Yes. >>>=20 >>>> But if the server has the data model, it >>>> should know this is an identityref and =E2=80=9Cp1:=E2=80=9D is a = prefix, right? >>>=20 >>> Sure. The use case is about servers that do not know about the data >>> model. >>>=20 >>>>> strings. But when it returns this node to a client, it must make >>>>> sure the prefix is declared properly. >>>>>=20 >>>>> We can solve this for anydata by saying that=20 >>>>> the anydata node must have all namespace declarations in the = anydata >>>>> subtree in the XML encoding. Thus the input (B) would be illegal, >>>>> but (A) legal. >>>>>=20 >>>>>=20 >>>>> 2. input json, output json >>>>>=20 >>>>> In json, there are no namespace prefixes, so that is not an issue. >>>>> Also, if both input and output is json, the implementation can = store >>>>> the data as received, and return it in the same way. >>>>>=20 >>>>>=20 >>>>> 3. input xml, output json >>>>>=20 >>>>> This is tricky, since in order to produce correct json both for = leaf >>>>> 'bar' and leaf 'if-type', the server needs schema knowledge; 'bar' >>>>> must be encoded as 42 rather than "42", and 'if-type' must be >>>>> encoded as "ex-ethernet:ethernet" rather than "p0:ethernet=E2=80=9D.= >>>>=20 >>>> It doesn=E2=80=99t make much sense to me that the server act as a = transparent >>>> relay. I think one can assume that for every anydata node the = server >>>> has a schema, although it needn=E2=80=99t be expressed in YANG. >>>=20 >>> I would stay out of "needn't be expressed in YANG". Let's just say >>> that the server knows the schema. >>>=20 >>>=20 >>>> If there really was a use case for a schema-agnostic server, we = could >>>> define a default (and lossy) XML->JSON translation. >>>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 28 07:28:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAC91A0105 for ; Wed, 28 Jan 2015 07:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl_O4CZC85Aq for ; Wed, 28 Jan 2015 07:28:16 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C523B1A049C for ; Wed, 28 Jan 2015 07:28:14 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so19348383lbv.3 for ; Wed, 28 Jan 2015 07:28:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=siJhGZx18ou8LvISkmFY9KFIxPpcGucRah5ghr3BXXk=; b=BzQTc5/wSeRAzb4zVW7Fd1JxjqehNezcya+QINsYGl6Ze93leXdIyoUn6FdP23Zulc s88iNLCP+QouYG2Ev+kU99Cj3AfKGfU7rVNT4FXeQe5t+c2VA7xgFnTEQarKgMCEchyY wguvhOq5Gm2lFI1zt0fpk1pZpJn9gO07eJnkSIleWwk2YWx7uoyS8yUSgz//UQEoeUl3 aBQ6UgV6jHAdDKSqDY1wdeoOy0pElIw+T0hGaxSHNJeNB60EU8gePP1HClU7iTaiGl7z fV/VvzdLI8HBfRK/nWviYD6MBzpBlQSwSFp3ijVYS14RQ0IyfVsu30sQahk1KOHnYnVb wX2Q== X-Gm-Message-State: ALoCoQmHIg9sXuEluQP8sIfPRPnipinCW9tQUx1tQvLk4M6OyRu8MaMLbKob1TXqaj0Dn2Z+A91Z MIME-Version: 1.0 X-Received: by 10.112.156.132 with SMTP id we4mr8734771lbb.59.1422458893205; Wed, 28 Jan 2015 07:28:13 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 28 Jan 2015 07:28:13 -0800 (PST) In-Reply-To: References: <20150127151202.GA89027@elstar.local> <20150127170907.GB89308@elstar.local> <20150128.091057.1523590536703844716.mbj@tail-f.com> Date: Wed, 28 Jan 2015 07:28:13 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 15:28:18 -0000 On Wed, Jan 28, 2015 at 3:05 AM, Ladislav Lhotka wrote: > >> On 28 Jan 2015, at 11:29, Andy Bierman wrote: >> >> On Wed, Jan 28, 2015 at 12:10 AM, Martin Bjorklund wrot= e: >>> Juergen Schoenwaelder wrote: >>>> I do not think we make progress this way and we probably need to find >>>> a way to do a mailing list hum to figure out where the _WG_ stands on >>>> this issue and not just the two of us. >>> >>> At this point, I think it would be useful if you could take a step >>> back and formulate the problem. I must I admit I got lost in the >>> discussion. I *think* the issue now has to do with the json encoding >>> of anydata and anyxml, if we decide to introduce anydata? >>> >>> >> >> I strongly agree with Juergen on the problem and the solution. >> >> The problem is that the sender MAY choose a JSON encoding >> format which is has some JSON type, even though the JSON >> data type is meaningless within anyxml/anydata. >> >> The solution is that the receiver MUST convert from the >> provided JSON type to some YANG type. If the sender >> does not know the YANG schema, a safe encoding must >> be picked (i.e., string). A receiver that understands the > > Why is string the only safe encoding? The data usually don=E2=80=99t appe= ar out of nowhere - and inside an application they have some type. Why shou= ld be a sender forced to translating a number to a string instead of passi= ng it simply to a JSON encoder? > The sender MAY pick a JSON type if that makes the programmer happy. It actually saves 2 bytes on the wire to send 42 instead of "42". If the programmer designing the receiver thinks it is a good idea to reject 42 because the "real" YANG is a string, not a number, then that is their decision. I would suggest designing code that is not so brittle. > Lada Andy > >> YANG schema MUST convert to the expected YANG type >> if possible. (e.g., Sending "purple" for a YANG boolean or >> number will fail at the final receiver). >> >> If the final YANG node is a boolean, then what difference >> does it make if the input from the sender is 42 or "42"? >> There is no benefit in "remembering" that a number was >> sent vs. a string. The JSON type is totally irrelevant to >> the transfer of anydata. >> >> >>> >>> /martin >> >> Andy >> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Wed Jan 28 08:20:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDC11A870B for ; Wed, 28 Jan 2015 08:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_ITqFqAJf9t for ; Wed, 28 Jan 2015 08:20:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0A01A00D1 for ; Wed, 28 Jan 2015 08:20:47 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 786C813F9DC; Wed, 28 Jan 2015 17:20:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422462046; bh=ZeQyey8IAqikNJVZ0Xb4ctVDXFtIFN7Tsx4GaEnZZ3w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iCnphYdFQUTbUqB/6Mt8jsp6p2vVQIHlbvd+8n7mHOn8rpXynP5XVDD5zrD9IwWFE YymxD/O/Gbvn5lZNI7ogdF/zJ6b0PE9MgyrMdOoYoUJjzOMaF13mq3Kfz+vK2VKHgB Rmkh4MbGvPIEP0rzghmFRlXbw73Hvxf+26Rajjxk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 28 Jan 2015 17:20:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150127151202.GA89027@elstar.local> <20150127170907.GB89308@elstar.local> <20150128.091057.1523590536703844716.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 16:20:50 -0000 > On 28 Jan 2015, at 16:28, Andy Bierman wrote: >=20 > On Wed, Jan 28, 2015 at 3:05 AM, Ladislav Lhotka = wrote: >>=20 >>> On 28 Jan 2015, at 11:29, Andy Bierman wrote: >>>=20 >>> On Wed, Jan 28, 2015 at 12:10 AM, Martin Bjorklund = wrote: >>>> Juergen Schoenwaelder wrote: >>>>> I do not think we make progress this way and we probably need to = find >>>>> a way to do a mailing list hum to figure out where the _WG_ stands = on >>>>> this issue and not just the two of us. >>>>=20 >>>> At this point, I think it would be useful if you could take a step >>>> back and formulate the problem. I must I admit I got lost in the >>>> discussion. I *think* the issue now has to do with the json = encoding >>>> of anydata and anyxml, if we decide to introduce anydata? >>>>=20 >>>>=20 >>>=20 >>> I strongly agree with Juergen on the problem and the solution. >>>=20 >>> The problem is that the sender MAY choose a JSON encoding >>> format which is has some JSON type, even though the JSON >>> data type is meaningless within anyxml/anydata. >>>=20 >>> The solution is that the receiver MUST convert from the >>> provided JSON type to some YANG type. If the sender >>> does not know the YANG schema, a safe encoding must >>> be picked (i.e., string). A receiver that understands the >>=20 >> Why is string the only safe encoding? The data usually don=E2=80=99t = appear out of nowhere - and inside an application they have some type. = Why should be a sender forced to translating a number to a string = instead of passing it simply to a JSON encoder? >>=20 >=20 > The sender MAY pick a JSON type if that makes the programmer happy. > It actually saves 2 bytes on the wire to send 42 instead of "42=E2=80=9D= . It=E2=80=99s not about saving a few bytes on the wire but rather about = keeping the interface between JSON encoding/decoding and an application = simple and straightforward. If a leaf=E2=80=99s type is int32, then its = value should also eventually end up in an integer variable, so all the = processing can be just integer variable -> JSON encoder -> transmission -> JSON parser -> = integer variable I guess this simplicity is the main reason why programmers prefer JSON = to XML - no DOMs or things like that are needed in the middle.=20 Lada >=20 > If the programmer designing the receiver thinks it is a good idea > to reject 42 because the "real" YANG is a string, not a number, > then that is their decision. I would suggest designing code that > is not so brittle. >=20 >> Lada >=20 >=20 > Andy >=20 >>=20 >>> YANG schema MUST convert to the expected YANG type >>> if possible. (e.g., Sending "purple" for a YANG boolean or >>> number will fail at the final receiver). >>>=20 >>> If the final YANG node is a boolean, then what difference >>> does it make if the input from the sender is 42 or "42"? >>> There is no benefit in "remembering" that a number was >>> sent vs. a string. The JSON type is totally irrelevant to >>> the transfer of anydata. >>>=20 >>>=20 >>>>=20 >>>> /martin >>>=20 >>> Andy >>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 29 08:09:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D369B1A1B42 for ; Thu, 29 Jan 2015 08:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQsJrKo2myY3 for ; Thu, 29 Jan 2015 08:09:15 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31A1A049C for ; Thu, 29 Jan 2015 08:09:14 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BD40F1CC03BB for ; Thu, 29 Jan 2015 17:09:19 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 29 Jan 2015 17:09:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 16:09:22 -0000 Hi, $SUBJ is already several months late, so I think we should proceed towards delivering it. I checked my mail archive since the -02 revision, and it seems two issues need to be resolved: 1. Andy objected to making redundant namespace prefixes illegal. I propose the following change to 4th paragraph in sec.=C2=A04 (SHOULD NOT instead of MUST NOT): OLD Names with namespace identifiers in the form shown in Figure 1 MUST be used for all top-level YANG data nodes, and also for all nodes whose parent node belongs to a different namespace. Otherwise, names with namespace identifiers MUST NOT be used. NEW Names with namespace identifiers in the form shown in Figure 1 MUST be used for all top-level YANG data nodes, and also for all nodes whose parent node belongs to a different namespace. Otherwise, names with namespace identifiers SHOULD NOT be used. 2. anyxml encoding: although it is a misnomer, I propose to keep the current definition (sec. 5.5), i.e. allow any valid JSON value in JSON-encoded anyxml instances. I also think the text makes it sufficiently clear that no standard mapping between XML- and JSON-encoded instances is defined. Objections, comments, other issues? Thanks, Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 29 10:46:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0151A1BD2 for ; Thu, 29 Jan 2015 10:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKKwbjjZrwXY for ; Thu, 29 Jan 2015 10:46:46 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048EB1A1BCC for ; Thu, 29 Jan 2015 10:46:46 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so31408126lbj.0 for ; Thu, 29 Jan 2015 10:46:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hFgc48WRERolOYQWm3yGXGp7VY6Ub5/co4O3tL1nnvc=; b=h/NP1FSswPEXN09jiVDP924I9PxNVUxyrVvDOZ6SkPOO0OmuivjjX0kTBGCoY8EU+S gnySab21Kz8mkgzZkFrC3T7nrkXqKrfX5g1tJPCGWlW8PjCQ7vnwNQ3cAaWg8rbWaXYK LcR2tRzGFER3tUYdmCmRfY9Bnn8hFK7aAMvIAjMpg42XPr6d6wqoTPTPaGxHBoUHj0K3 SUB2pb4rEl2vnZbsqYKc0gS6LtkLlkI+IN7zZcAl0U/Sabrx87Qh94wRFaXgIdXx5NX4 laNH9Y6bTH3xTwjzrhfzUQ881vCTqSDga1VYYKFPN/1iE7ypYbNN5r1gX4uWjE1KyZXm GC4Q== X-Gm-Message-State: ALoCoQlsv8a0ojsFFOI4CsaBlOxMJDVS6dzLsKzjCx9l3LCHDAgD+hByNBqd3ITKu4uYWK9i6/Eh MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr2695412laf.82.1422557204433; Thu, 29 Jan 2015 10:46:44 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 29 Jan 2015 10:46:44 -0800 (PST) In-Reply-To: References: Date: Thu, 29 Jan 2015 10:46:44 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:46:49 -0000 On Thu, Jan 29, 2015 at 8:09 AM, Ladislav Lhotka wrote: > Hi, > > $SUBJ is already several months late, so I think we should proceed > towards delivering it. I checked my mail archive since the -02 revision, > and it seems two issues need to be resolved: > > 1. Andy objected to making redundant namespace prefixes illegal. I > propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > instead of MUST NOT): > > OLD > > Names with namespace identifiers in the form shown in Figure 1 MUST > be used for all top-level YANG data nodes, and also for all nodes > whose parent node belongs to a different namespace. Otherwise, names > with namespace identifiers MUST NOT be used. > > NEW > > Names with namespace identifiers in the form shown in Figure 1 MUST > be used for all top-level YANG data nodes, and also for all nodes > whose parent node belongs to a different namespace. Otherwise, names > with namespace identifiers SHOULD NOT be used. > This is more appropriate usage of RFC 2119 terms. > 2. anyxml encoding: although it is a misnomer, I propose to keep the > current definition (sec. 5.5), i.e. allow any valid JSON value in > JSON-encoded anyxml instances. I also think the text makes it > sufficiently clear that no standard mapping between XML- and > JSON-encoded instances is defined. > > Objections, comments, other issues? This is fine. I do not think this draft should be coupled to YANG 1.1 anydata. The YANG 1.0 anyxml definition cannot really be constrained. > > Thanks, Lada Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jan 30 02:14:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7AC1A8A92 for ; Fri, 30 Jan 2015 02:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bb1wuJBhKQd for ; Fri, 30 Jan 2015 02:14:10 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1351A8A9D for ; Fri, 30 Jan 2015 02:14:09 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:506b:9882:bc3c:875a] (unknown [IPv6:2001:1488:fffe:6:506b:9882:bc3c:875a]) by mail.nic.cz (Postfix) with ESMTPSA id 4D8F1140C79; Fri, 30 Jan 2015 11:14:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1422612847; bh=1DI/pRZYnxp2fANh+0MAvruGPpswqUrsnndD4LwgzRI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kbEPnjdJk5apjEVQWfWHQIm1FF1AZPsae7DIM2CAl7DE7ywyPWUdiAOuOYdbltv0J gd76/Y3ha0fFPhtQALyQxbnlsb8hlNOMmQoUFWSUxBGkGCi1cyGtXiR1anRc0w+R8s 6p+APH1xzACwCnjrbw49P4iKgHyi0qV6jP6uThD0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 30 Jan 2015 11:14:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 10:14:12 -0000 > On 29 Jan 2015, at 19:46, Andy Bierman wrote: >=20 > On Thu, Jan 29, 2015 at 8:09 AM, Ladislav Lhotka = wrote: >> Hi, >>=20 >> $SUBJ is already several months late, so I think we should proceed >> towards delivering it. I checked my mail archive since the -02 = revision, >> and it seems two issues need to be resolved: >>=20 >> 1. Andy objected to making redundant namespace prefixes illegal. I >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> instead of MUST NOT): >>=20 >> OLD >>=20 >> Names with namespace identifiers in the form shown in Figure 1 MUST >> be used for all top-level YANG data nodes, and also for all nodes >> whose parent node belongs to a different namespace. Otherwise, = names >> with namespace identifiers MUST NOT be used. >>=20 >> NEW >>=20 >> Names with namespace identifiers in the form shown in Figure 1 MUST >> be used for all top-level YANG data nodes, and also for all nodes >> whose parent node belongs to a different namespace. Otherwise, = names >> with namespace identifiers SHOULD NOT be used. >>=20 >=20 > This is more appropriate usage of RFC 2119 terms. >=20 >> 2. anyxml encoding: although it is a misnomer, I propose to keep the >> current definition (sec. 5.5), i.e. allow any valid JSON value in >> JSON-encoded anyxml instances. I also think the text makes it >> sufficiently clear that no standard mapping between XML- and >> JSON-encoded instances is defined. >>=20 >> Objections, comments, other issues? >=20 > This is fine. I do not think this draft should be coupled to YANG 1.1 = anydata. > The YANG 1.0 anyxml definition cannot really be constrained. Agreed. Lada >=20 >=20 >>=20 >> Thanks, Lada >=20 > Andy >=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C